Making Enemies

Posted on by

There are three fundamental questions at the heart of designing enemies for an action game.  The first is:

1.  How will this enemy force the player to react?

Any enemy can be tuned to be deadly.  In fact, overly lethal enemies are often a symptom of a poorly balanced game; nobody enjoys being flattened by an unstoppable steamroller.  And any enemy can be crippled until it is merely a target in a shooting gallery.  When a designer has run out of ideas for making an enemy fun, the fallback position is usually “bullet sponge”.  The key to designing an enjoyable opponent for the player is finding a way to split the difference — forcing the player to react to an enemy without resorting to killing them.

To achieve this, it is important for the enemies to take the initiative and make the first move.  Players will tend to repeat the same tactics over and over if they continue to work.  By preempting their default strategy the enemy will challenge them to improvise, to think more strategically, or to experiment with new tactics.

  • Disarm the player, or prevent them from using their primary attack
  • Invade the player’s space, requiring them to start a fight before they are ready
  • Use a special non-lethal attack that stuns or knocks the player around, preventing them from fighting back until they can counter it

Another good way to force the player to react beyond taking and dealing damage, especially in shooters, is to force them to move.  By making the player aware of their environment — the connectivity of the space and their physical relationship to their surroundings — a well-designed enemy can greatly increase the strategic depth of combat.

  • Attack from a range that is outside or inside the player’s optimal range
  • Deny the player use of an area (as with a long-fused grenade) forcing them to move to a different area
  • Take cover behind an object, requiring the player to switch positions and flank them
  • Charge to melee range, so the player must retreat or change weapons

Another way the player can be made to react is by changing something significant about the fight so they have to re-prioritize their targets or switch tactics.  This change doesn’t have to be immediately dangerous, it just needs to tilt the battlefield in a new direction.

  • Begin a devastating attack with a long wind-up that can be interrupted
  • Perform an attack that ends in a temporary vulnerability that the player will want to exploit
  • Allow the player’s current target to quickly withdraw or become invulnerable, removing themselves from the fight temporarily

Another tool for causing a reaction that is often overlooked is dialog or dramatic behaviors that don’t serve a combat function, but can still influence the player and cause a reaction.

  • Taunt or mock the player to incite anger
  • Announce an upcoming action (like reloading) to draw the player’s attention
  • Threaten or attack one of the player’s allies, giving them a chance to be a hero

Far from being a secondary concern to be considered after an enemy can already fight well, these non-lethal interactions with the player should be designed first and receive the most attention.  Once the player is engaging an enemy with their mind — and not just their fingers and their weapons — they will be having fun.  At that point it is easy to make them more or less lethal as the balance requires.

GDC 2010: Design in Detail XVIII

Posted on by


Here’s what we didn’t do. We didn’t touch the Strength Knobs. In most cases, they aren’t the problem anyway. When a weapon is being used as intended, it should feel overpowered. So most imbalances come from using a weapon outside its role, in which case changing the strength knobs won’t fix anything, it will just make the weapon worse.

We also didn’t try to add a weaknesses. It often feels like the only option, but find something else! That sort of “a little hot, a little cold” design never ends. You’ll just chase your tail until you run out of time.

Your strategy should be to find where the element is being used outside of its designated role, and change the mechanics to constrain it better.


But if you can’t touch the Strength Knobs, you have to touch the Flow Knobs. (Remember, there isn’t anything else, because we removed all the extraneous mechanics!) The tricky part is to fine tune those Flow Knobs without losing the flow state you worked so hard to capture. Revisit them in light of what you now know about the game and don’t change them so far that you break flow.

Of the components of flow, cadence is the most flexible, so many problems can be fixed by adjusting cadence. Hopefully not so far that you lose the rhythm.

Most importantly, at this point you must not rely on your gut, it will steer you wrong! You need a very clear chain of cause and effect, so you can make as small a change as possible to fix the problem.


So what are the possible flow knobs we can tweak? What will achieve the balance objective with the least amount of ripple effect?

We could have changed the number of shots in a clip. That would have changed the cadence to cause the player to reload more often. But it would also have meant a sniper couldn’t kill two enemies without reloading unless he got a headshot. That would have ratcheted up the pressure quite a bit, and moved the Sniper Rifle out of the skill range of most players.

We could have increased the length of the reload. But dying because you can’t fire back is frustrating. To be honest, this change was a contender, but it felt too much like adding a weakness.


We could have changed the time to it took the Sniper Rifle to reach full zoom. We actually tried this as a solution (and found some bugs in the camera code, too!) But in the end, it encouraged players to fire without zooming, which broke the role worse than the original issue. In fact, it exasperated the problem of players using the Sniper Rifle at close range.

We also could have prevented the Sniper Rifle from doing headshots when unzoomed. Unfortunately, this removes a uniquely cool moment, which even average players can experience if they get lucky.


We could have changed the maximum total ammo. The problem is, this would have limited the overall effectiveness of the Sniper Rifle without changing the experience of any individual combat encounter. (For more on the perils of this technique, read Against Statistical Design.)

Finally, we could have changed the time between shots. We didn’t choose this option immediately; we tried, tested and reverted almost every value on this list. In the end, increasing the time between shots was the only one that fixed the balance problem with a minimum of side-effects.

It was inevitable; I have no marketable skills

Idle Hands

Posted on by

It has been exactly six months and one day since I abruptly and inexplicably retired from game design after thirteen years at Bungie Studios (creators of Halo, Halo 2, Halo 3, Halo: ODST and Halo: Reach.)  And now, after precisely six months of spending time with my family, traveling the globe and watching daytime television… it’s time for me to get back to making games!

It was inevitable; I have no marketable skills

I missed the excitement

At some point I’ll talk about my new gig, but first I want to thank all of you readers for your engagement and encouragement over the last half-year.  Writing about game design for publication has been something I have always wanted to try, and I’ve enjoyed it immensely.  I do intend to keep posting — I have explicit permission from my new employer to do so — but it will probably not be with the same frequency and regularity.  Especially not at first, since I have a lot to learn and I’m already quite busy.  Again, thanks so much for reading — it’s great to be a professional game designer again!

-Jaime

PS  I’ll probably be using @tipofthesphere more frequently and I’ll be sure to mention new posts in the feed.

Treating Iterationitis

Posted on by

Iteration is the key to good game design.  Everyone knows this, not just designers.  Artists, programmers, even the producers in charge of the schedule acknowledge that iteration is a necessary evil — a gullet of unknown appetite that must be sated.  However, this abstract understanding breaks down almost immediately when faced with this inflexible reality:  If our plan is to iterate on the design until the game is fun, it will not be fun when we begin, and will not be fun at any point in the iteration process until literally the moment before we are done.  Successful designers have accepted this reality to some extent — they have to.  But non-designers, deprived of both visibility into the iterative process and ultimate responsibility for how it turns out, have not been forced to come to terms with this uncomfortable truth, and so they get nervous.

It is in the designer’s best interest to minimize the impact of their own uncertainty on the rest of the development team.  Some of them do this through bravado — how dare you question my ability to produce results?!  Others present design as a black art, with arcane secrets known only to themselves — an illusion which a perceptive non-designer can dispel with a few well-considered questions.  Many use this uncertainty as camouflage, avoiding direct conflict by constantly iterating without revealing their ultimate goals.  The problem with all of these techniques is that they can be used not only to reduce the team’s discomfort with iteration, but to conceal a lack of design discipline or creative horsepower.  It becomes impossible to discern the difference between a good designer protecting the team from the difficulties of iteration and a bad designer hoping to stall long enough to get lucky.  What is required are methods to iterate quickly while minimizing the team-wide anxiety.

Not how iteration works

Continuity of Iteration

If a designer stops iterating on an element or system for more than a week, other team members will assume that they are done with it.  They will evaluate it as if it was finished and assume that the designer is satisfied, even though it is clearly not fun.  Left unchecked, this chain of assumptions will lead them to distrust the designer’s abilities and judgement.  This happens almost entirely subconsciously, so communication to the contrary is rarely effective.  The only real solution is to keep iterating, even when the correct next step is unclear.  Just change something so that bystanders will postpone their evaluations.  This also avoids the problem of inertia, where developers — even designers, sometimes — grow accustomed to an element’s broken state and no longer notice that it isn’t fun.

Tools and Systems for Iteration

Any non-designer that is an integral part of the iteration loop will be exposed to the chill of uncertainty on a daily basis.  So the simplest way to reduce their unease is to make sure the tools for iterating don’t require their constant support.  With the proper tools, a designer should be able to experiment entirely on their own, without external resources.  If these tools are unavailable, it may require the designer to broaden their skill-set until they can hack together what they need.  That’s why most experienced designers have a working knowledge of so many tools — 3D modeling software, source code editors, Photoshop, etc. — not because they can produce shippable content or code, but so they can try off-the-wall ideas without needing help from outside the design team.

Private... not on TV

Private Iteration

Another benefit of tools that designers can use on their own is that they allow for private experimentation.  Sometimes the iteration process is random and goes through an enormous number of bad ideas before discovering a good one.  Again, since most non-designers are not confronted by the constant, unmitigated stream of failures required by the iterative process, watching the ones responsible for the ultimate quality of the game appear to be blindingly incompetent for months on end can be… unsettling.  It takes an emotional toll that can be avoided when a designer does most of their failing in private, witnessed only by other sympathetic designers.

Herald Milestones

Of course, chronically working in private has one major disadvantage — nobody sees your successes, either.  Since a lack of perceptible progress can be as damaging to team morale as public regression, it is crucial to announce any concrete improvements as soon as they happen.  No need to wait for an element to be complete, so long as a decision is reasonably certain and isn’t going to change immediately, let people know!  “The speed of the tank has been decided!”  “Jump is definitely going to be on the ‘A’ button!”  Pointing out these small, but measurable, signs of certainty will give the team a sense that there is light at the end of the iteration tunnel.

We'll get there... eventually

Even permanent failures can result in more certainty.  “We have given up on the hovercraft!” “We are no longer working on the Shadow Beast!”  The objective is not to demonstrate the perfection of the design team, but to show an inexorable drive toward closure.  The team must understand — not just intellectually but in their bones — that if the iteration process continues as it is, at some point in the future, the game will be done.

GDC 2010: Design in Detail XVII

Posted on by


This is the point in development where we finally changed the Sniper Rifle. Now I will try to describe how all the work from previous passes informed this decision…


The Sniper Rifle was overpowered — that’s what we intended, remember – but it made the other aspects of the game feel weaker.  We couldn’t make the rest of the arsenal strong enough to keep the Sniper Rifle in line.  One way we could tell was because the players we had picked out as Optimizers were using it exclusively.  Role Players, on the other hand, were still not using it, but suffering for it.


Worse, the Sniper Rifle was being used at close quarters, which is clearly outside of its role.  And nothing the targeted player could do would allow them to avoid being sniped.


When something impacts you emotionally we say we were “moved”.  Emotions are what compel you to act — not graphs and data.  Use your Sense of Balance to feel when something is wrong and trust those instincts.

Nerf Herders?

Against Statistical Design

Posted on by

Statistical Design

I suggested that a good way of improving one’s design sense is by staring at Rorschach Tests, and here is a practical example of the importance of practicing pattern-avoidance.

To me it looks like a designer's brain in a vice

Stop seeing patterns!

This image is a heatmap showing where people most often die on Assembly, a Halo multiplayer map.  These heatmaps were first used by the Halo design team to analyze maps during testing, but were so interesting looking they became part of the bungie.net statistics pages.  This data is so rich — so detailed and specific — it must be useful to a designer in some way, right?  The problem-loving brain of the game designer latches on to this as The Solution and immediately starts searching for The Problem.  It is tempting, given a powerful tool like statistical analysis, to incorporate it into the design process somehow — especially since design is often stranded in a world of abstraction and uncertainty.  Having concrete numbers is a rare treat.

However, what does this data mean?  Are red areas bad?  Should dark areas be eliminated?  Does a well-designed multiplayer map have a symmetrical shape?  What percentage of a map should be yellow?  Something about high-contrast feels unbalanced, so perhaps the map should be revised so that the gradient from safe to dangerous is more continuous.  And areas where nobody dies seem wasteful, maybe they should be removed.  And obviously the red areas will be frustrating, so they should be made safer by limiting line-of-sight and adding cover.  Pretty soon we have a completely yellow multiplayer map, that we have tricked ourselves into believing is balanced because our data looks pretty.  We have fallen victim to statistical design.

Players Aren’t Statistical

Statistics are powerful tools because they aggregate a large number of unique instances into a manageable form so it can be analyzed.  It would be impossible to watch every death of every player across thousands of games and have any cohesive understanding of how often players were dying in a given area.  Given enough examples, we would develop an emotional feeling of dread or security associated with certain spots, but the brain uses a very unscientific method to determine these attachments.  Exciting experiences are weighted much too heavily, which is why the impartiality of statistics is useful in discovering imbalances.  Using statistics to find problems is fine; designers go wrong when they use statistics to evaluate solutions.

Players don’t engage with the game statistically — they experience it personally.  It doesn’t matter if more players are killed standing in a specific spot than anywhere else on the map, what matters is the unique experience of a player killed in that spot.  If they realize that they shouldn’t have crested the hill with no cover that is right below where the Sniper Rifle spawns, vow not to do that again and move on, there is nothing wrong with the map.  Even if they do it over and over, growing more and more frustrated at their repeated mistake and creating a bright red dot on the heatmap, the map is not unbalanced.  However, if players are forced to expose themselves at a single chokepoint, or get sniped through a hidden line-of-sight in an otherwise safe area, it doesn’t matter if it is a rare experience and there is no red, the map ought to be fixed.  Neither of these situations can be found through statistical analysis, and neither of them are fixed by a solution that merely addresses the probability of being killed in a given area.

Avoiding Statistical Design

Some systems can only be balanced statistically.  If there are three factions in the game, and one faction wins 43% of the time, the factions are not balanced.  If a map is intended to be used for two-flag CTF, but the bases aren’t mirror images of one another, then the two sides had better be perfectly fair.  The necessity of reverting to statistical methods is inherent in the design of the system itself.  The designer will be forced to make changes that do not change the unique player experience — or may even harm it– in order to fix a statistical imbalance.  Worse still, players are skilled at detecting when a system must be balanced statistically, but since they do not have access to hard numbers their personal experience will tell them that it isn’t balanced — even when the data says that it is!

Nerf Herders?

Nerf Paladin?

Well-designed systems do not need to be balanced through data-manipulation.  If there are 10 weapons in the game, and one weapon is responsible for 20% of the kills, there is probably not a problem.  If the unique player experience isn’t negatively impacted, the statistical difference isn’t a balance issue.  So, the easiest way to avoid the trap of statistical design is to avoid systems that must be balanced mathematically in favor of those that can be balanced behaviorally.  If a system requires a large amount of instrumentation and is extremely sensitive to tiny value changes, instead of obsessing over statistical patterns, try revisiting the system’s design and making it less brittle.

GDC 2010: Design in Detail XVI

Posted on by


Sometimes you have to let your head drive.

I’ve claimed in this talk that your rational brain is a feeble instrument and cannot handle the volume of input associated with balancing a multiplayer game. This is true, but that is not an excuse for presenting your design decisions as inexplicable black magic guided solely by intuition and guesswork. You need to have solid design values that you can point to as a general explanation for how you make decisions, and then provide specific reasons and supporting data when necessary to convince the team. Just because you don’t have time to carefully examine every detail doesn’t mean you can’t logically examine any decision. Other designers and developers have instincts, too; if they clash with yours take it as a sign that you need to look closer.


Here are some good design values to use when balancing a complicated game system. First, fix imbalance with physics when you can, and only revert to math when required. The player cannot directly experience the math behind the system, so tweaking elements by changing mathematical formulas is difficult to perceive, tough to evaluate and even if it does fix the problem in the long-term, it may not feel fixed. Of course, at their most basic level all video games software are math, so it may be impossible to address a problem without making changes to numbers and equations, but don’t resort to that immediately. I think a lot of designers got their start with board games and pen-and-paper RPGs, where the math is explicit, but modern games are simulations and respond more readily to behavioral changes than to statistical ones.


Hey look, a totally fair game… A totally boring, pointless, frustrating, fair game.


You cannot make a Sniper Rifle fair. The person being sniped cannot counter-attack, faces near-instant death, and usually doesn’t even know they are in a fight until it is too late! If you make fairness your goal you will end up removing all the interesting asymmetry from the game. Instead, focus on longevity. Create a Sniper Rifle that doesn’t make the person that was sniped want to quit, and you will succeed.

Give me a hug!

Design Sense – Perception

Posted on by

Rorschach Tests

Look at this picture.  What do you see?

Give me a hug!

The answer is obviously Goro

Hermann Rorschach devised the technique of using random ink blots to probe the subconscious mind, based on the idea that patients would be prone to seeing images that were more important or relevant to their mental state.  They would project their internal preoccupations onto the otherwise abstract shapes, revealing clues that could be deciphered by their psychiatrist.

The reason ink blot tests work is because humans are naturally adept at seeing images and patterns.  Our brains are composed of an enormous collection of highly specialized neural circuits, custom-built for finding, storing and matching patterns.  Parts of our brains are devoted to sensing contrasts, finding parallel lines, extrapolating three-dimensional depth, recognizing faces, anticipating motion — the list goes on and on.  In fact, so much of our cognitive potential is tied up in neural pathways that are optimized for matching specific patterns, it is actually very difficult to avoid seeing them everywhere.  In video game terms, you are almost all GPU with very little CPU.  It is difficult for us to simply perceive information without our specialized capabilities biasing our interpretation of it.

Why are you so morbid?

Completely abstract shapes

This is great for surviving in the jungle, not so great for designing games.  The problem is that we begin processing before we have all the information; we draw conclusions based on patterns that may not actually exist.  Did that element dominate an encounter because of a fluke, or does it represent a trend?  Is this feature a little out of tune, or does it hopelessly conflict with the rest of the game?  It’s impossible to tell from a single example, but that doesn’t prevent us from making judgements based on one experience.  And once we have a pattern in our head, Confirmation Bias kicks in and our brain optimizes further and starts rejecting data that doesn’t support our initial conclusion, making it even harder for us to be objective.

Confirmation Bias is especially potent for game designers, because we know what is supposed to happen.  We wrote the paper design, we know how a mechanic was intended to constrain the gameplay, so we play our games as if the mechanics work properly — even when they don’t!  We know the picture behind the ink blot, so we are incapable of seeing with unbiased eyes.  Which is why we are so often shocked during playtests; what is obvious to us proves unintuitive and confusing without the pattern already in mind.

Unfiltered Perception

So train yourself to see the ink, not the pattern.  Stubbornly stare until you don’t see an image, but only what is truly there.  Then, when you play your game, divest yourself of preconceived notions of what the game ought to be and strive to experience the game as it truly is.  This will allow you to see through the eyes of a new player.

Another method is to find Gestalt images, pictures that abruptly change meaning based on how you look at them, and practice switching between the competing interpretations.  This will allow you to hold multiple explanations of the same game experience in your mind at the same time, so you can evaluate them all fairly.

Old woman, young woman, old woman, young woman...

It may sound ridiculous to spend time deconstructing smudges and turning old women into young women, but it will help reclaim some of those specialized circuits and increase your ability to process unfiltered reality.  Which will make you a more effective game designer.

He's about to have an experience he won't forget!

Put to the Question

Posted on by

If you want to learn something, read about it.  If you want to understand something, write about it.  If you want to master something, teach it.

– Yogi Bhajan

Successful designers are those that have the discipline to edit their work.  Generating gameplay ideas is exciting and easy; discerning those with potential and removing the rest takes resolve and vision.  But you’ll never get where you are going if you walk down every road — you must cut!

Removing game elements is usually straightforward.  They are almost always part of a collection of similar elements, so they can be compared on an apples-to-apples basis.  They are often specific instances of a general system — the Assault Rifle is an instance of the Weapon system, the Goblin is an instance of the enemy AI systems — which means that most of the work that goes into them can be applied to other elements and isn’t wasted.  An element is associated with a certain amount of work that must be scheduled for the models, textures, effects, sounds and animations, so it is easy to measure its impact on the overall scope.  And finally, since an element is by definition discrete, it can usually be removed with virtually no impact on the rest of the game.

This guy's name is Needler

Some elements just don't fit in

“Is this mechanic going to be fun?” is a good question, but impossible to answer.  Prototyping can help, but it still takes discernment to recognize the potential in a prototype.  It also represents an investment of resources, which can bias the team toward keeping a prototyped mechanic that ought to be cut.  “Can we implement this mechanic?” is also a good question, but “can” is not “should” and “implemented” is not “tuned”.  “Has a mechanic appeared in another game?” is a useful question, but isn’t necessarily relevant to the current game.  “Does everyone agree this mechanic is good?” is a seductive, but destructive, question; it replaces a designer’s instinct with general consensus and will lead to “downhill design” where the only possible solutions are the easiest ones.  The single best question for determining the potential of a mechanic is “Can the player be taught to enjoy this mechanic?”

He's about to have an experience he won't forget!

Not everything is teachable

Answered honestly, this question has far-reaching implications.  If a player never uses a mechanic, it might as well not exist in the first place.  If a player fails to realize that a mechanic exists, it is too subtle or the game is overly complicated.  If a player refuses to learn a mechanic, it probably doesn’t fulfill a fundamental aspiration for them — they will never be interested.  If a player is unable to learn a mechanic, it is probably unintuitive or it clashes with other aspects of the game.  If the designer cannot distill a mechanic down to teach it, they likely don’t understand the mechanic themselves.  If a mechanic can only be learned through explicit tutorial, it probably has an awkward or obscure control scheme.  Any of these problems are fundamental enough to warrant removal.

On the other hand, if a mechanic can be taught effortlessly — or better yet, players discover it on their own — or if mere awareness that an experience is possible is enough to motivate them to learn how to access it, this is a sign that a mechanic is reaching them on a subconscious level.  This kind of mechanic can be integrated into their thought process and lead to a fluid flow experience.

GDC 2010: Design in Detail XV

Posted on by


Without anyone getting kicked in the face…


You always need to listen when people don’t like something. You are too close to the game; You probably already fixed all the things you didn’t like, so you should value a fresh perspective. Keep in mind that you can always trust someone’s emotional reactions, they are always authentic and valuable, but never just blindly take their advice. The designer’s job is to separate emotional feedback from thoughtful suggestions and treat the appropriately.


Before you can interpret someone’s feedback, you need to understand the source. Feedback means “the game in my head is different” and often times your response to feedback should be to probe about what kind of game they are imagining. You don’t necessarily need to agree on the game you are making to benefit from their feedback; they probably represent some portion of your audience.

You see Development Bias a lot with the public when the development process is very open. Playtesters know the game isn’t finished, they know you expect them to provide constructive criticism, so they become a lot more sensitive and more likely to complain. Once the game is on the shelves, those small problems fade into the background and players rarely notice them.


You also need to understand the source of feedback; If you can categorize someone’s play style, it will help you understand how to react to their feedback. You can weight their comments appropriately.
Here are some examples:
(The names have been changed to protect the guilty)


I used to balance “Easy” by playing with my nose (true story) but Steve still couldn’t beat it. I miss that guy, he was incredibly useful for balancing.


Even more important than categorizing other players, you need to understand your own playstyle. For instance, I’m a “role-player”, so I tend to ignore small balance problems if the results are still dramatic. I have to recruit “pros” that are more sensitive to useless or underpowered elements.

Definition: Role

Posted on by

Role

The features, mechanics, situation and purpose which define an element’s function in a game

According to Aristotle, we can claim to have knowledge of something only when we have understood its causes.  These causes come in four types: the material cause – the matter of which the thing is made, the formal cause – the pattern or idea which that matter takes, the efficient cause – the motivation which formed the matter, and the final cause – the purpose for which it is used.  Once we understand all four causes, we know an object fully.  In game design terms, once we can explain all four causes, we know an element’s role.

The Material Cause

Video games are not physical objects, so technically they don’t require a material cause.  However, they do have underlying components that make their existence in the game possible, like models, textures, effects and sounds.  They also require other engine features like physics, particles, etc.  Some elements even require completely unique features, and explicitly specifying these features is important to defining the role.

The Formal Cause

This aspect of a game element is what we traditionally think of as “design.”  The form of an element is the pattern that it follows and the systems in which it operates – the game mechanics that constrain it.  Aristotle is referring to the Platonic idea of an object, but in-game design this is the Paper Design.  Just as in Plato’s theory, real life cannot match the perfection of the world of ideas; the in-game experience will never realize the paper design exactly, but it does provide an objective standard.  Much like a craftsman making a chair is attempting to create a material version of the ultimate idea of “chairhood”, the designer tunes an experience to get as close as possible to the original game design.

The Efficient Cause

Often called the “moving cause” because it provides the motivating force for an object, the efficient cause is closest to our modern concept of “cause and effect.”  In game design, the efficient cause is always the player and their desires.  A game element that does not have a corresponding player desire will never be used (at least not without coercion) so it is crucial to identify and meet those needs.

The Final Cause

The most important cause, at least to Aristotle, is the purpose for which an object exists.  In a game, this is especially true because games are fundamentally about using tools to solve problems, and game elements are usually classified by the types of problems they solve.  This is why it is so important to limit an element’s power so it is only effective for its designated role; if an element is an effective solution for multiple types of problem it becomes difficult to tell what its purpose is intended to be.  This is also why a problem should be presented before or at the same time as the solution, or else the player will not have a way to categorize the solving element.  This purpose is communicated to the player through affordance and reinforced by rewarding feedback.

Taken together, these four causes define an element’s role.  The features that allow it to exist.  The mechanics that give it a form and constrain its use.  The situation that creates the player’s need for it.  The purpose for which the player will use it.  Once a designer understands all four causes for an element, they understand an element well enough to implement it successfully.

GDC 2010: Design in Detail XIV

Posted on by


If you were disciplined in writing your paper design, and stayed firm while doing setting up the rough balance, this stage should be very rewarding and exciting.  If not, it is going to be disappointing and frustrating.


The timing for this stage is tricky.  If you start too early, your balance changes will be swallowed up by the churn of new features coming online.  If you wait too long, the rough balance will become entrenched and the team will object to changes.  Generally, this coincides with a “First Playable” build where everything is at least in the game and functioning.

It’s crucially important to communicate this new phase to the rest of the team, so they know what to expect and understand that now is the time for them to give the feedback they have been patiently waiting to deliver. One way to do that is to implement a controlled opportunity for them to play the latest build and provide their feedback in a structured format.  Make sure you tell them what you are currently working on, so their responses will be relevant, but don’t tell them exactly what has changed or you may bias their opinions.


So how do you balance a Sniper Rifle? It is not by adding weaknesses!  Don’t undo the work you did in making it powerful!  Balance it by narrowing its role through limitations.


The best way to detect which elements need to be limited is by watching for the game to become predictable.  If the same strategy is being used in a variety of different situations, to the point where players are no longer required to think about which strategy to choose, it means an element is too useful outside of its designated role.  If the Sniper Rifle is not only the best weapon at long range, but players are carrying it indoors and using it against vehicles, it needs to be constrained.  Give it some time first, because the playtesters might just not have figured out the new balance yet, but if it is consistent for a few tests, start looking for ways to limit the dominant element.

On the other hand, if the game is completely unpredictable, it is a sign that the elements are not effective enough at their roles.  A truly random strategy should never be as good as intentionally selecting an element that is strong in the desired role.  It may also be a symptom of a role going unfulfilled.  If there is no Sniper Rifle, the Shotgun and the SMG are equally terrible at long range combat, so it doesn’t matter which one you choose.

Up, Up and Away!

Against Eschatological Design

Posted on by

The last few months of a game’s development is a magical time.  Ideally, everything is coming together, the team is firing on all cylinders, and the experience is getting better by the hour.  Bugs are getting fixed, the build is more stable and performs better, the art is looking polished, and playtest results begin to climb to their highest levels right as the game is locked down.  The difference between those last precious moments of post-production, where everything is happening too fast to follow, and the months (often years) of glacially slow progress at the beginning of a project are so stark, they create the perception that a switch has been thrown, that the game has suddenly become fun.  The designer’s new-found power to affect change, and the positive feedback from the rest of the team, leads to a feeling of vindication and exhilaration.  Finally, all the hard work has paid off and the game has crossed the Fun Barrier.

It is tempting, after the flush of this experience, to look back on a game’s development as a power curve.  To retroactively smooth out the experience so it fits a nice mathematical progression, making the outcome of a fun game inevitable from the start.  To pretend as if the only unknown was if the game would cross the Fun Barrier before the project ran out of time or funding.  To ensure success on the next project by figuring out how to increase the exponent on the power curve, to work harder and add features faster, to run more playtests and balance earlier, so the game has time to reach the steep end of its exponential curve.

Up, Up and Away!

Fun = (Iterations * Time) ^Talent ?

The problem is that fun doesn’t really work that way.  A player experiences fun as a binary switch, either they are having fun at a given moment or they aren’t, like a square wave.  There’s no such thing as almost fun; an experience doesn’t gradually go from 90% enjoyable to 100% fun in a continuous curve.  A game gets better because it sustains a fun experience for longer stretches at a time, with less unfun gaps in between.

Worst Line Rider level ever

Fun = Fun * Polish ?

An experienced game designer is sensitive to very short, almost subliminal moments where a mechanic is actually fun.  Even in an early prototype phase, they can detect these snippets and predict with confidence which mechanics have potential and which ones don’t.  So, instead of finding ways to be more effective at polishing hopelessly dull gameplay, they can quickly abandon mechanics that never display those glimpses of greatness and focus exclusively on eliminating or minimizing the unfun gaps in those mechanics are already fun in spurts.  This is why exceptional designers tend to produce simpler, more reliably enjoyable games with fewer mechanics that feel almost effortless to play.  And why the vast majority of average games are released with an abundance of features, but subject players to hours of tedium or frustration as they labor to find fleeting moments of fun on their own.

GDC 2010: Design in Detail XIII

Posted on by


Certain things about the Sniper Rifle make it strong. (Here are a few of them, for reference.) Just like with the Fun Knobs, you want to know what makes something strong, so you can avoid backtracking. Once you move on to the polish stage, resist changing the strength of an element. (At least without admitting that you are doing it, and reflecting in the schedule.)


Don’t do half measures, if you find something that works, CRANK IT! This is especially true of power. Make everything overpowered without fear! To paraphrase The Incredibles… If everything is overpowered, nothing is.

This is the most important slide in the entire talk! It’s so easy to understand, and so difficult to stick to without wavering.


So at this point, the Flow Knobs are set, The Power Knobs are set… It’s time to flatten the rest! Eliminate the chaos and noise, put your design through the cleansing fire and get rid of all the extraneous detail. This stage takes discipline, it is the point at which you must stop adding new ideas, and start closing out the design. Luckily, if you set a determined course, you will find yourself with plenty of time at the end to add all the fine detail and polish that you want.


Assuming you are working on a game that has both single and multiplayer, you should balance for multiplayer first. Multiplayer balance is very unforgiving, live opponents will exploit any loopholes. The AI in singleplayer are a lot more flexible and malleable, so the balance doesn’t need to be as precise.

Against Iterative Design

Posted on by

“We practice iterative design”  You hear it in virtually every studio profile, every GDC design lecture, and it’s a buzzword game journalists equate with exceptional game design and a high level of polish.  Apparently there is a magic formula for making good games, and it goes something like this.

  1. Start with a fun game
  2. Make a tiny change (usually after exhaustive debate)
  3. Playtest extensively to see if those changes made the game better
  4. If they did, keep them; if not, change them back
  5. Repeat until your publisher makes you ship

It’s a pretty straightforward process, anyone can understand it and imagine executing on it.  Acceptance of this model leads to some pretty obvious ways to improve your design skills, too.  Make smarter changes.  Iterate faster.  Find better test metrics.  Take more time.  And now we know why Valve and Blizzard make better games than anyone else, right?  They take more time discussing changes, they have better tools for iteration, they playtest more than anyone, and of course, they ship when they are ready.  And it’s true, to some extent; a game that went through several rounds of polish will be better than one that didn’t.  But if you adopt iterative design as your primary design philosophy you will be doomed to making mediocre clones of better games…

First, let’s examine iterative design applied to other creative forms.  Want to write the next great novel?  Start with a book you really enjoy, like “The Count of Monte Cristo” and start iterating!  Pick a random chapter, change a crucial detail, and then read the whole book again and see if it is better.  Clowns are funny – let’s make Dantès a traveling circus performer instead of a sailor.  Over the course of 1400 pages, assessing that change is virtually impossible, except that the occasional clown-lover might comment on it.  Although no one change will be measurably worse, by the time enough alterations are made to create a substantively different novel, it will be an incomprehensible mess.

What a Dumas!

Pourquoi cet air si sérieux?

Let’s take a look at a concrete example of how iterative design can fail, specifically in determining the number of weapons the player can carry in a shooter.  In Wolfenstein 3d, the player could carry 6 weapons.  In order to improve this, an iterative designer would try playing through with 5 weapons and with 7 weapons.  Clearly, 7 weapons is better than 5 because the player has more choices.  So then the designer would try 8 weapons, which would also test better because “more” always tests better.  At some point, the designer would probably decide the gains from adding an additional weapon no longer justified the expense, and the game would ship with the player carrying 25 weapons at all times.  The iterative designer would never arrive at the solution introduced in Halo and adopted by virtually every shooter since, of reducing the number of weapons the player can carry, because the benefits of that system are not apparent until you reach 2-3.  In mathematics, this technique is known as hill climbing and it can only be used to find a local maximum because it cannot cross gaps to reliably find the global maximum.  Every designer knows that a game is never fun at first, so it is likely that even a good change is going to feel like a bad one for a short period of time, and an iterative process will reverse course too early.

Finally, a use for a math degree!

You can't get there from here...

The main reason that the iterative process is a siren song is implicit in Step One, “Start with a fun game.”  How can anything dramatically new be created if you are only allowed to start with something that is already successful?  If you something is already fun, stop iterating on it and work on the parts that aren’t fun.  And if something isn’t fun, the iterative process won’t get you there.  In the end, iteration is a polishing technique, not a generative one.