Evaluating Game Mechanics For Depth (2024)

[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.]

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.

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.

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 my experience, in order for a game mechanic to be deep it needs two very important things:

When a player enters a challenge, he must have a good idea of what his objectives are. Another good way to put this is to say that he must be able to clearly visualize the completion state of the challenge.

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

This sounds like a small distinction, but is in fact very important. Making this shift in how you think about designing game mechanics allows you to see depth-related problems that you otherwise would not.

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

I added bombs that you could drag around to blow up doors and little energy slingshots you could use to fling the bombs around at targets.

I decided blocks would be able to get in the way of laser beams so you could get past them.

I added special blocks with explosive rockets inside that would blow up certain doors.

Finally, I made it so that some of the blocks slid around inside a groove on the floor. The player had to figure out how to arrange the blocks into a specific order, but the blocks all got into each others way, since they shared a groove.

By the end of all that adding, not only was I permanently on several programmers' hate lists, but the tractor beam game mechanic was quickly getting too bloated. It was way too complicated for players to handle. Playtests were generating feedback that players were routinely confused. We had to devote about half the time spent with the tractor beam purely to training, so that our players could understand the basic gist of what they needed to do.

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.

I'll go into this a little more below, but I bring it up now because it illustrates how meaningful skills contribute much more to a feeling of depth than objectives do.

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.

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.

An Activity Statement is a simple sentence that describes a challenge by stating both the objective of a challenge and the meaningful skills that the player must use to obtain his objective.

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.

Here is what Activity Statements would have looked like for some of the tractor beam challenges past-me designed:

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.

With the other two challenges past-me designed, it looks like I was onto something a little 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:

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

By altering the Activity Statement during the design phase to more explicitly encompass the meaningful skill (and thereby altering the underlying mechanic), your whole design will get deeper and more satisfying.

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.

2. Identify and list all your meaningful skills.

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.

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.