|
[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."
-
Buzzwords to watch for: The game is "a
one-trick pony," "repetitive," "or needs more
variety."
-
Feedback that can be fixed with these kind of
content expansions tends to describe the game as a whole. Players feel they
don't have enough different things to do on a global level.
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.
-
Buzzwords to watch for: A given game mechanic is
"boring," "repetitive," or "just not fun."
-
Feedback that can be fixed with theatrics
improvements usually describes a single game mechanic, but is vague and
"touchy-feely."
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.
-
Buzzwords to watch for: A given game mechanic is
"too shallow," "too easy," or "flat." Often
players will say the mechanic started out fun, but that it quickly got
repetitive or boring.
-
It's a good idea to pump up the theatrics when
you get feedback like this, but while it might help players tolerate a mechanic
for longer, it will only go so far. When theatrics fail, it's time to knuckle
down, roll up your sleeves, and get to work on making your game mechanic
deeper.
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 my experience, in order
for a game mechanic to be deep it needs two very important things:
-
It needs clear objectives, so the player knows
what he has to do to succeed. Confusion and obfuscation tend to make players
feel like a mechanic is LESS deep once they find themselves needing to
experiment randomly to win.
-
It needs a variety of Meaningful Skills that
you, as a game designer, can use to create good challenges for the player and
that the player in turn can use to achieve mastery over the game.
Objectives
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.
|
Mastery of goal-oriented skills (mechanics) is central not only to games, but even more centrally to simulators.
Flight mechanics are obviously the central theme to a flight simulator. Designers could do worse than make a deep study of simulation mechanics and try to bring as much of this as possible into their efforts, kind of like a yardstick.
If players feel they are learning skills (mechanics) that might actually be transferable, they might become more engaged, which any business guy will tell you is big value add.
An example of this might be Standard Orbit from Standard3D.com. It is a space flight simulator dropped into a star catalog (Yale Bright Star). The mechanical skills acquired allows gamers to develop knowledge of astronomy in a very compelling way.
Add in 3D real-time stereoscopic texture-mapped graphics, sound and multi-player, throw in warp-speed and a photon cannon, Standard Orbit is a browser game with very interesting mechanics, indeed.
It was interesting to see you mention "Narrative Game Mechanics" - I wrote a Gamasutra post on that subject a while back, here's the link in case anyone is interested
http://www.gamasutra.com/blogs/FranciscoSouki/20090625/2130/Game_Mechanics_That_
Tell_Stories.php
Veterans and newbies would benefit from reading this informative read.
Cheers.
Rudy
@John Courtwright: you need to re-read page 3, paragraph 3. The general form is "Have player [use skill(s)] to [accomplish objective]."
I might suggest further breaking down the Activity Statements in outline form like this:
Use skill X to
- complete objective 1.
- complete objective 2.
...
Using Mike's tractor beam examples it might look like:
Move object from start point to end point to
- push a button.
- destroy a door.
- block a beam.
- push a button and destroy a door.
Based on this form, I think more abstract descriptions might help, because it makes duplicates more obvious. In the example outline above, detecting that the last objective is just a combination of the first and second is a lot easier than if I used more specific descriptions. Note that abstract is not the same as vague.
The second set of "deeper" tractor beam actions would look like this:
Move object from starting point into device, aim device, and release device to propel object to
- destroy targets.
Move sized objects from starting points in shared channel to specific end points in channel, in a specific order to
- destroy a door.
Both objectives destroy something, but they clearly require different skill sets.
To explore deepening ways of accomplishing the same objective using different player skills, this outline list could be inverted to:
To accomplish specific objective X
use skill set 1,
OR use skill set 2,
...
My favorite examples of such "deep objectives" are in Deus Ex.
You might have to start with Mike's more descriptive Action Statements before you can abstract them down to this point, but the abstract outline form might help to separate the truly different skills and objectives, from the decorative flourishes that give the false appearance of diversity. This gets into issues over the consistency of abstraction levels, and object or verb classification. Those issues seem too subjective and game-dependent to be resolved here.
@Jared Hardy - Thanks Jared, I think you put it very nicely. Breaking them down that way would definitely make identifying the objectives and skills easier.
@Matthew Woodward - If I'm understanding you right, I think you were suggesting the same format Jared did, in which case yeah, I think that would be a very helpful way to structure the Activity Statements. As Jared mentioned, it sorts the important bits nicely, and helps you identify them easily.
@John Courtwright - So if I understand your question, here's how I'd classify the difference between skills and objectives: An objective is essentially the completion state of a mechanic. Think of the Zelda boss door. Your objective is to put the key in that door. The meaningful skills are everything that happens in between the point where the player recognizes his objective and when he completes it. In the case of that boss door example, the player might need to kill all the enemies in the room to get the key, so the meaningful skill there combat (which in turn could be broken down into an activity statement of its own, but that would make this example super-complicated).
Jared's activity statement for the example you brought up is much better than the one I gave. I glossed over the particulars of that particular statement to try to make a different point, but I think in doing so I made it a tad confusing. I suppose I should have heeded my own advice about vague activity statements. ;)
Once again, thanks to everyone for the great comments! It's awesome to see people like the article.
~Mike
(Talking about a toy during a meeting)
JOSH
It turns from a building into a robot, right?
PAUL
Precisely.
JOSH
Well, what's fun about that?
PAUL
Well, if you had read your industry breakdown, you would see that our
success in the action figure area has climbed from 27 percent to 45
percent in the last two years. There, that might help.
JOSH
Oh.
PAUL
Yes?
JOSH
I still don't get it.
Point is... there's a tendency, in any industry, to take fundamentally bad ideas or concepts and rationalize them with over-analysis. But as the saying goes "you got to know when to hold 'em, know when to fold 'em". If the core concept or design is flawed or bad, an activity statement will only polish or focus it. For many, that becomes an excuse for turning a blind eye to obvious problems.
So keep in mind an activity statement is not a Philosopher's stone. Meaning... it will not turn lead into gold. You still need to be smart and honest enough to know when to cut your losses and start from scratch instead.
For example, imagine a game, there is a door that is basically made of thin planks that you ion real life might have issues breaking by hand but...In the game you need a key (or rather activate a trigger through dialog with skill check or through dialog tied to a previous quest).
But if you had not done that particular quest, or you do not have enough speech skill to talk your way through... You are basically stuck. But ironically enough you carry some insanely powerful explosives that could easily kill you, blow a crater and wipe out stuff in a rather large radius around it.
Logic dictates that the flimsy door would be turned into toothpicks in an instant, only several explosions later you find there is not a single scratch.
In that case it's obvious that another alternative should have been added (blowing it to pieces), aka. redundant solutions to the problem. (In case anyone is wondering, I'm referring to Fallout 3 and trying to enter Little Lamplight).
Other similar issues are doors that can not be opened, later after doing "stuff" you return and it's magically open.
Here it would make sense to either see someone exiting/entering it (thus opening it) or you yourself finding the key, or trying it again a cinematic of you blowing it to pieces (because you found some explosives previously).
Too many games fail in this regard sadly.
I agree with your point completely. In the case of the flimsy boards example in Fallout 3, that's a great example of a confusing objective. The player sees the boards, realizes he has to get past them, and does not know what he needs to accomplish to do so. It's especially bad since in Fallout 3 they often have you blow obstacles out of doorways to proceed (mattresses, crates, boards, etc...) and so it's completely right for the player to expect to be able to do so here.
I only go into it a little bit in the article, but coming up with clear objectives is a huge part of being able to have depth in a mechanic. As you point out, as soon as the objective gets muddy or unclear the challenge fails from that.
I don't think there's a simple formula to decide whether or not an objective will be clear enough, but fortunately it's an easy thing to figure out by play testing. If a player sees his objective and doesn't know what he needs to do to fulfill it, then the objective is too vague or confusing and it should be simplified.
In the case of the Fallout door, if the door had been made of reinforced steel set into concrete (like one of the Vault doors) with a small peephole built into it the player wouldn't think explosives were an option. That leaves the quest line and talking your way through as ways to get in. If you fail to talk your way through, the speaker could say "The only way we're gonna let you in is if..." and then essentially point you to the start of the quest line. You could even get a quest in your quest log to take you to the start of the quest line.
See what I mean?
@David
I agree with you about the dangers of over-analysis. Everyone in the industry has run into the "polishing a turd" problem. The tractor beam examples I gave are a great example of this.
When I worked on those mechanics I kept trying to add trappings onto them, hoping they would get better. I was polishing the turd. What I should have done is strip the whole down and start over. That is, in fact, what I'm suggesting to my past-self at the end of the article.
The problem is when past-me tried to do that he didn't have enough experience or any solid principles to end up with something better (other than perhaps by random chance). Not only were past-me's instincts not good enough at that point in his career to solve the problem that way, he didn't have enough knowledge of the craft to try and come up with a better answer.
If past-me knew then what I know now, he could have used a structure like this to help get the right answer and not wasted time polishing the turd.
So when I suggest for my past self to focus on the basic elements of his mechanic design (starting with the activity statements) before trying to improve things, I'm essentially telling him to scrap everything and start over, except that I'm giving him a plan of attack for doing so. He could then attempt to start over with some kind of method instead of just trying new features until he got it right.
In the case of the example from "Big", I'm asking the people not to rationalize why they're making a robot that turns into a building, but to examine the robot and the building down to their core, and to figure out why the combination of the two is not satisfactory.
That's essentially what Tom Hanks ends up doing in that scene, but he does it intuitively -- "Well, couldn't it be like a robot that turns into something like a bug or something? ... Like a big prehistoric insect with maybe like giant claws that could pick up a car and crush it!"
~ Mike
> [W]hen I suggest for my past self to focus on the basic elements of his mechanic design ... before trying to improve things, I'm essentially telling him to scrap everything and start over.
This is actually another crucial lesson that an experienced systems designer learns. One of the best ways I ever heard it phrased was in the book _Systemantics_ by John Gall:
"If a problem seems intractable, consider that you may have a meta-problem."
In other words, if you're banging your head against a problem and nothing seems to work, then that's a sign that what you're fighting is more likely just a symptom of a larger design problem. In such cases the most effective thing you can do is to stop, take a step back, and think about the larger environment in which your "problem" exists. Instead of continuing to bull your way down one bramble-choked side path, poke your head up and look to see if maybe there's a superhighway going in the right direction.
Some problems do just have to be bulled through. But with some experience and a little creative effort, this process of detecting meta-problems can wind up yielding a much better solution to a particularly resistant problem (and often other sub-problems you didn't even know you had!) than any amount of gritted-teeth effort.
One gameplay mechanic that perfectly serves your high-level design goals can be better than a whole collection of merely adequate mechanics. :)
Absolutely. I haven't read _Systemantics_, but those are great words to describe that problem.
Sometimes you can't solve a problem from the branches. You have to go back and check the roots.
Thanks for the insight Mike!
To me, a mechanic is something the player can do in a game, and how it functions. It isn't something so specifically aimed at certain situations... I guess that disconnect attributes to some of my confusing with the whole article.
Overall though, thanks for your insights! I'm going to try and reread it a few times, but even so far I definitely can see some things that I can take from this and apply towards how I design levels.
The alternate approach is to create the mechanic as a "toy", play with it to discover what's fun to do with this toy, and then design goals which accentuate the intrinsically discovered joy of play.
Personally I find this more organic than retrofitting mechanics to meet goals, but there are many paths, and none of them are "wrong". Certainly for the bottom up approach, you need more time to iterate and prototype, as you're essentially letting the game design itself... reaching for the indivisible truth of the sculpture hiding inside the woodblock.
So, thanks for writing this article! I'm not ashamed to admit that I will be using some of the techniques discussed here in my future endeavors.