Evaluating Game Mechanics For Depth

By Mike Stout

[Former Insomniac designer Mike Stout takes shares a useful rubric for judging the depth of play mechanics, including checks for redundant ones, in this in-depth design article, which contains examples from the Ratchet & Clank series.]

The Problem

Often, in game development, a design that looks great on paper doesn't turn out as well in practice as you'd hoped. It comes across as "shallow" or "flat." Perhaps play-testers, publishers, or peers describe it as "needing more variety" or as "feeling repetitive."

Every game designer has heard these complaints at one time or another. I've bumped up against problems like this on every game I've ever worked on and there are three ways I like to approach solving them.

If the players felt the game overall didn't have enough variety you can add more game mechanics to the game. Think of this as increasing the game's "breadth."

If players feel that an individual game mechanic is flat and unrewarding you can refine that mechanic's "theatrics" by giving the player better feedback, more rewards, better effects, cooler sounds, more personality, a cooler camera, or other bells and whistles. After theatrics refinements, players will often -- with no changes to the underlying gameplay -- tell you the problem is fixed.

If players feel that an individual game mechanic "isn't giving them a good enough challenge," or feel that "the mechanic is fun at first but gets old quickly," you need to add depth to your mechanics.

While each of these could be the focus of its own article, this article will focus on perhaps the trickiest of the three: depth. By the time you're done reading this article, I hope to describe for you the tools I use to find out why a game mechanic doesn't feel deep enough. Even better, I hope to impart a few techniques that I've found help a lot when it comes time to fix a shallow game mechanic.

First: A Few Definitions

Before diving into a discussion on depth, I wanted to define a couple of terms that I'll be using a lot in this article:

Game Mechanic: When I say "game mechanic" I'm referring to any major chunk of gameplay in a video game. Using the classic The Legend of Zelda: A Link to the Past as an example, here are a batch of game mechanics: sword combat, block pushing, boomerang throwing, swimming, button-based puzzles, hazard-avoidance, use of specific weapons, etc...

Challenge: A challenge is any in-game scenario that tests the player's skill at a specific game mechanic. An example of this would be an individual room in a Zelda dungeon, a grindrail segment in Ratchet & Clank, or a combat encounter in Halo.

So What Does "Deep" Mean, Anyway?

Dictionary.com defines depth as: "The amount of knowledge, intelligence, wisdom, insight, feeling... evident either in some product of the mind, as a learned paper, argument, work of art, etc." As is evident from the scope of this definition, depth can be an incredibly personal term, and can mean a lot of different things to a lot of different people.

To me, it describes a sweet spot -- that point during a game where the player can repeatedly display his mastery of a game mechanic. Challenges never stay the same long enough to be boring and yet they also don't change so fast that the player can't enjoy his mastery over the game.

Clearly this "depth" is something we want to achieve in many of our mechanics, but it's often less clear how to obtain it.




In The Legend of Zelda: A Link to the Past, when players see a door that looks like this, they know they must find a special "Boss Key" to go through. These doors are a good, though simple, example of an objective. Once he sees the door, the player knows he needs to find the key and bring it back.

Clear objectives are a must if you want to create depth in your game mechanic. As I mentioned before, if the player doesn't know what the completion state of the challenge should be, he's reduced to floundering about and trying things randomly instead of demonstrating his mastery of the game's mechanics.

Meaningful Skills

Meaningful Skills are all the "things" the player must do to take a challenge from its beginning state to its completion state. In other words, once the player has recognized a challenge's objective, the work has only begun.

It can't be stressed enough that I'm referring to meaningful skills. "Meaningful" is an incredibly important part of this equation. If a skill is too basic, it will not help make your mechanic feel deeper. At that point, it becomes a simple task the player must complete, like checking items off a shopping list.

A classic example of a too-basic skill can be found in the statement "move from point A to point B." That kind of fundamental movement challenge is essentially the same as saying "hold a button on the controller to win." It's foundational, but it's too simple. It's not deep.

Further, when you really think about it, when you say "move from point A to point B," you're actually talking more about the objective of a challenge and not the skill required to achieve the objective.


Meaningful Skills: A Morality Tale

When I was a junior designer on Ratchet & Clank 2, I was given the task of coming up with all the "Tractor Beam" puzzles for the two levels of the game that used them. The tractor beam was a game mechanic that allowed Ratchet to freely move large objects marked with a special tractor beam symbol. Essentially this is a theatrical "paint-over" of classic block-pushing challenges from games like The Legend of Zelda.

Coming up with the training setups was easy. The player simply had to move blocks from point A to point B so that he could jump up on them and get out of a pit. My problems began, however, when I tried to come up with more advanced challenges. I quickly came to an impasse. Moving blocks from one place to another, I saw, was too basic a skill. Beyond the training example, there wasn't much more I could do to "ramp it up" and provide varied, escalating challenges.

At this time in my career, I didn't yet understand the important distinction between meaningful skills and too-basic skills. I didn't know how important clearly identifiable objectives were. And so, lacking experience, I decided to just start adding features until the mechanic was deep enough. If you're groaning at this, then I congratulate you. I'm groaning, myself, as I write this.

Besides moving blocks around, I decided it would be great if the player could grab and drag around a wacky robot (if you're reading this and thinking "oh, you improved the theatrics," you get a cookie). The player could then drop the robot on buttons to open doors. This didn't help as much as I wanted it to -- it just still seemed way to shallow.

So I forged ahead and kept adding features (groan).






Looking back, it's clear to me why the mechanic never felt deep enough: I kept adding new objectives, but failed to add many meaningful skills.


Experiences like the one I had with the tractor beam taught me a valuable lesson: most game mechanics that don't feel deep enough feel that way because they have too many objectives and not enough meaningful skills.

While players found the Inspector Bot wacky and funny, adding him did not succeed at the goal of making the Tractor Beam game mechanic deeper.

Making a Statement

So if I could go back in time, how would I help myself make the tractor beam challenge deeper? Well the first thing I'd suggest is that my past-self come up with an "Activity Statement" for each challenge in the segment.


For example, a simple platforming challenge could be described in an Activity Statement as: "I want the player to jump up to that platform." In this case "jump up" is the meaningful skill and "that platform" is the objective.

A more complex platforming Activity Statement might be "I want the player to double jump straight up and then glide down to that platform" or "I want the player to time his jump to avoid the fire spouts and land on that platform."

The Activity Statements listed above all contain a mixture of objectives and meaningful skills. But what happens if you exclude one of those ingredients? We've established that challenges without a clear objective are not deep, but it's also true that game mechanics that feel shallow tend to include many objectives, but few meaningful skills.


You'll notice that the above statements all clearly outline objectives, but no meaningful skills. In fact, when you examine them closely, all of them outline the same objective, and it's not even a particularly interesting objective!

Each statement is basically saying "Move from point A to point B," which we already know describes a skill so basic that it doesn't make our game mechanic any deeper.


Both of these Activity Statements, "use the energy slingshot to blow up a target" and "arrange the blocks in a specific order" describe skills that are much more meaningful than the others.

Knowing this, I would advise my past-self to:

  1. Cut most of the too-basic skills / objectives described above. They all boil down to "take an object near a door to open the door" and could be accomplished with either the bomb or the rocket-block. Nuke redundancy and simplify things for your players, past-me! Do it now!
  3. Prototype the new challenges in-game.
  4. Play-test the new challenges.
  5. If the whole thing is still too shallow, add another Meaningful Skill to the list (make sure it's not an objective!) and repeat from step 1.

The objective of this tractor beam challenge is very clear; get the three blocks into the alcoves that best fit them. Further, the Meaningful Skill (organize the blocks despite them getting in each others' way) is much deeper than in any of the other Tractor Beam challenges.

Note: All of my examples thus far have been about puzzle-like gameplay, but this article isn't just about puzzles. All types game mechanics can benefit from this way of thinking.

For example, lets say you have a gun combat mechanic that is feeling shallow. Perhaps this is because "use your gun to kill an enemy" doesn't say anything about the meaningful skill. It is purely a statement of objective. In Ratchet & Clank, our gun combat's Activity Statement was more like "Choose the correct weapon or combination of weapons to kill a group of enemies as efficiently as possible."


Avoid Vague Activity Statements

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.


"I want the player to use the portal gun to get this block on top of that button."




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.


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.


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."


Exercise to Improve Depth

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:


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.

Something to Consider


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.

A Final Note

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.

Return to the full version of this article
Copyright © UBM Tech, All rights reserved