My technique is no technique

Making Enemies II

The second fundamental question crucial to designing enemies for an action game is:

2.  How will this enemy counter the player’s first-tier tactics?

Action games give the player a hammer.  It looks like a broadsword or an assault rifle, but it’s still a hammer.  And when you have a hammer, every enemy looks like a nail.  A nail doesn’t have to do anything complicated to look smart; all it has to do is avoid getting hammered right away!  If an enemy forces the player to reach into their toolbox for a second option, they’ll show that they are clever, and the player will feel clever, too.

My technique is no technique

Good AI

The obvious way to counter the player’s basic tactics is through simple invulnerability.  “That armor is too strong for blasters.”  It’s crucial that this invulnerability is communicated clearly, through the look of the enemy, how they respond to the player’s attack, and any supporting effects or dialog.  If the player doesn’t realize they are not being effective — or is misled into thinking they have done damage when they haven’t — the enemy will just seem poorly tuned.

  • Carries a shield that blocks bullets, but any other kind of attack causes them to drop their shield and expose themselves to fire
  • Cannot be killed with melee attacks and must be thrown into an environmental hazard
  • Bullets bounce off the vehicle, but you can snipe the driver out

A more subtle way to foil the player’s main method of attacking is to preemptively take action to prevent it or require another action be taken before the attack to make it a two-step process.  These enemies appear intelligent, but they still allow the player to user their (hopefully) satisfying primary attack.

  • Takes cover behind an object, requiring the player to flank or drive them out of cover
  • Wears a full-body energy shield that must be taken down before they can be damaged by normal bullets
  • Blocks every sword swing, but is stunned if their own swing is blocked

It is also possible for an enemy to behave in such a way that it is more difficult for the player to execute on their first-tier attack.  This can be difficult to tune for multiple difficulty levels, but if the counter-strategy only works on the their main attack, then players of any skill level should be able to cope by changing their tactical choices instead of having to execute beyond their skill level.

  • Flees out of melee range faster than the player can pursue, but has no defense against ranged attacks
  • Keeps up a constant barrage of fire, forcing the player to hide, but unable to get away from a grenade thrown from behind cover

Again, the idea is not to make an enemy that is difficult or frustrating, or even especially sophisticated, but that has a clear counter for the player’s primary attack.  This will require the player to stretch, tactically, and figure out their alternatives, but any amount of experimentation should be rewarded by a quick victory.

Advertisements

Making Enemies

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


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

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

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


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

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.