Gamasutra: The Art & Business of Making Gamesspacer
Evaluating Game Mechanics For Depth

Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 17, 2014
arrowPress Releases
April 17, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Evaluating Game Mechanics For Depth

July 21, 2010 Article Start Page 1 of 4 Next
 

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


Article Start Page 1 of 4 Next

Related Jobs

Nexon America, Inc.
Nexon America, Inc. — El Segundo , California, United States
[04.17.14]

Web Designer - Temporary - 3 month
Darkside Game Studios
Darkside Game Studios — Sunrise, Florida, United States
[04.17.14]

Mid-Senior Graphics Programmer
Digital Extremes
Digital Extremes — LONDON, Ontario, Canada
[04.17.14]

UI ARTIST/DESIGNER
Digital Extremes
Digital Extremes — LONDON, Ontario, Canada
[04.17.14]

UI ARTIST/DESIGNER






Comments


Shawn Morrison
profile image
This was a really insightful, helpful article. Thank you so much for writing it. I liked the idea of writing activity statements for each game mechanic or smaller objective.

Eric Carr
profile image
Good article. I had never considered breaking down mechanics into activity statements before. I'm thinking that I'll add that to the toolbox moving forward.

dominic cerisano
profile image
You touch on a salient point here that I would like to develop a litter further.



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.

Joe Cooper
profile image
Excellent article. Very useful. I like how you think. Favorited.

Francisco Souki
profile image
Great article! Super practical and to the point.



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

Adam Bishop
profile image
The Ratchet games have usually felt like they had great level design and a fun variety of objectives and activities, so it's super interesting to be able to peer into the mind of one of the people responsible for that. Thanks for the great article!

Rudy Pollorena Jr
profile image
This is good shit Mike.



Veterans and newbies would benefit from reading this informative read.



Cheers.



Rudy

Matthew Woodward
profile image
WRT generating activity statements, would it be a useful approach to think of them as instructions for a competent but completely unimaginative player? "Using the skills you've already learned, do x, y and z to advance" sort of thing. This probably leaves you short on the objectives side, but in terms of getting granularity right for the way skills are employed it seems like it might be a useful template.

John Courtwright
profile image
How do you describe skills differently than you do objectives? In the article, each skill is described as the successful execution of some task: "use the energy slingshot to blow up a target," for example, sounds like a purpose toward which a player should apply his skills. What does a good skill description have that an objective description lacks?

John Chan
profile image
Insightful! I can already think of ways this would help me in designing game mechanics.

Jared Hardy
profile image
Great insights here Mike! You got my wheels turning in a rare and fun way. This kind of introspection and the results always made you a pleasure to work with. You make the rest of us [ex-]Insomniacs proud. :)



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

Mike Stout
profile image
Thanks for all the kind words, everyone. :)



@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

Brandon Davis
profile image
Thanks Mike! I started reading the article looking for some insight into developing some objectives for our beta testing sites. I found a lot more!

Shekhar Gyanwali
profile image
like this, very useful

Peter Kjaer
profile image
Great article, thanks for sharing! :)

Joseph Mauke
profile image
Very informative for sure

Rafael Vazquez
profile image
Excelent tips! They will surely come in handy in the near future

David Serrano
profile image
I think this is incredibly useful from a practical point of view. But at what point does it cross over into over analysis? It just makes me think about a scene from the movie Big:



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

Roger Haagensen
profile image
David, I agree.



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.

Mike Stout
profile image
@Roger:



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

Bart Stewart
profile image
The "how-to" of the original article has gotten a lot of justified praise, but I wanted to give a little attention to this recent comment:



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

Mike Stout
profile image
@Bart



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.

Travis Demyan
profile image
this was a very insightful article. thanks for making the distinctions that you did.

Rafael Posnik
profile image
Very nice article, you certainly helped me organize my thoughts on this subject, before I just writed down some shallow stuff like "our game needs to have double jump and 3 weapons" and the objectives were very pitful...



Thanks for the insight Mike!

Charles Stuard
profile image
I had a bit trouble following this article, maybe it's from the terminology used, maybe its from my low amount of experience. This entire article seemed like it was more about what I'd personally consider "level design", rather than what I'd consider "mechanic design". Or maybe your methodology is just more focused on level design driven mechanics?



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.

Aubrey Hesselgren
profile image
It certainly seems like a top down approach to mechanic design: starting with an outcome and figuring out what fills the needs.



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.

Matt Zeilinger
profile image
This was a very informative and eye-opening read. I actually felt something click in a small way in the designer part of my brain. Some of the hurdles in my latest game design suddenly made more sense, and past mistakes became glaringly simple. It's one of those things I think I always knew on some level, I just now have a better understanding of it. =)



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.

Jorge Diaz
profile image
Good read.

Kevin Manthe
profile image
Thank you for this informative article.


none
 
Comment: