Evaluating Game Mechanics For Depth

By Mike Stout


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.



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

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.

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.



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.

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.

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:

  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!
  2. Examine the two deeper mechanics and try to create more challenges for each of them. Past-me would begin designing these new challenges by writing an Activity Statement for each one.
  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."

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.

Avoid Vague Activity Statements













Exercise to Improve Depth


First take stock:

1. Identify and list your objectives.


2. Identify and list all your meaningful skills.






2. Go through all your challenges and improve your Activity Statements

3. Prototype the new content.



Something to Consider



A Final Note





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