Activity Statements are an immensely useful tool, but it's possible for them to get you into trouble. The easiest way to get in this kind of trouble is to create a vague Activity Statement.
For example, here is a simple Activity Statement that could apply to most of the challenges in Portal:
"I want the player to use the portal gun to get this block on top of that button."
While the indicated skill (use the portal gun) in this simple Activity Statement happens to be a Meaningful Skill, this kind of vague statement can get you into trouble if you're not lucky.
The Clank gameplay in the Ratchet & Clank games is a good example of this.
The Clank challenges always bugged many of the designers I knew at Insomniac, myself included. When we designed them, they seemed like they should be deep activities, but they never turned out that way.
We were able to patch them up by giving them a lot of personality and by keeping them fairly simple (theatrics, baby!) but it took many sequels to add enough depth to them to satisfy us. Players seemed to like them, but we thought we could do better.
In the first two Ratchet & Clank games, Clank needed to give commands to his Gadgebots (cute little robots that followed him around) to get past blockades. There were a few different types of blockades, but in the end they all ended up feeling the same. We patched it up with effects and cute animations, but in general they were quite shallow.
The Activity Statement: "I want the player to command his array of Gadgebots to get him past blockades," in the end, is too vague. It doesn't give enough information to tell whether or not the mechanic will deep enough.
Flash forward to Ratchet & Clank Future: A Crack in Time. Clank now has the ability to record his actions at certain points in the level and then have a hologram play those actions back.
This gave way to challenges with very complex Activity Statements like "I want the player to record himself going to that button, which opens a door. Then I want him to play back the recording and, once the hologram hits the button and the door opens, I want him to go through the door." You'll notice clear objectives "go to the button to open the door" and "go through the door" as well as good meaningful skills "record himself" and "play back the recording."
This is a much deeper mechanic, with a much less vague set of Activity Statements.
So you've got your design and it had what seems like a killer Activity Statement. But now you've prototyped it (or gone even further) and somehow the mechanic still ends up feeling flat. What can you do now?
First take stock:
1. Identify and list your objectives.
a. For each, ask yourself: "Is this objective functionally a duplicate of any of the other objectives in my list?" If it is, ask yourself if you really need it. Do you really want to spend the time on teaching your players how to interact with it? If the answer is no, cross it out.
2. Identify and list all your meaningful skills.
a. For each ask yourself: "Is this really a meaningful skill? Not too basic? Not an objective?"
b. Ask yourself: "Is this skill functionally a duplicate of any of the other meaningful skills in my list?" If it is, cross it out. You're tricking yourself into thinking you have more skills than you actually do.
Having taken stock, do you now find you have too many objectives? Not enough meaningful skills? At this point, I'll bet you've discovered that, yes, somehow that's happened. At this point, just do the same exercise I suggested above to help my past-self get over his tractor beam problems:
1. Add one or more new meaningful skills to the list.
a. As you add them, ask yourself the same questions as above. "Is this skill really meaningful? Is it too basic? Is it really an objective?"
2. Go through all your challenges and improve your Activity Statements
3. Prototype the new content.
4. Play-test. Is your problem solved? If so, then you're done!
5. If your problem isn't solved, go back to step 1 and try again.
As I mentioned at the beginning of this article, making a mechanic deeper might not always be something you want to do. Before you go ahead and do a ton of work making a mechanic deeper, ask yourself these questions.
So once you've thought it through and decided that depth is what you want, you need to make sure your game mechanics each have clear objectives and a good set of meaningful skills. By using the exercises described above, and remembering the distinction between too-basic skills and meaningful skills, you'll have a better chance of evaluating, troubleshooting, and adding depth to your game mechanics.
In this article I advocate a specific way of breaking down game mechanics. I pointed out the importance of focusing on Meaningful Skills over objectives and "too-basic" skills.
Though I believe this is a very useful way to break things down, I don't mean to imply that this way of breaking things down is somehow "more correct" than any other way. This is one of many very valid ways a game can be broken down.
In his book Science and Method the French Mathemetician Henri Poincaré said "Geometry is not true, it is advantageous."
The same is true with models for thinking about game design. None of them are true -- they are only convenient. The model I suggest above has, time and again, proven quite convenient for me to use evaluating, predicting, and troubleshooting depth in game mechanics. Use it for that purpose, and it'll be your best friend.