Elephants, on the other hand, NEVER forget

Design by Numbers: Cooldowns

Maximum Cooldown Time: 6-12 seconds

Purple hippos. Green puppies. Red monkeys. Short term memory is an interesting thing. Yellow birds. Blue horses. It can only hold around seven items (give or take a few, depending on your level of concentration.) Which means for some of you “Orange lizards” is going to drive the first animal right out of your working memory. This is why most game controllers have around seven buttons — White spiders, Pink fish — and most successful action games don’t even use that many. Player’s simply can’t hold all those options in their heads at the same time.

Elephants, on the other hand, NEVER forget

Orange elephants.

But the most important aspect of short term memory isn’t how many options player’s can remember, but how long it takes for them to fade. Or how short. Neurological research indicates that we start to forget details as few as 6 seconds after being introduced to them. After 300 seconds we are only half as likely to remember a concept, and after 10 long minutes… forget about it. (Sorry.) So that means, depending on your reading speed, you’ve almost certainly forgot the first animal by now.

This has a direct application in determining the length of cooldowns for abilities in action games. (In this context, a “cooldown” is the amount of time that must elapse after an ability is used before it can be used again.) The player stores the fact that an ability was used in their short term memory, and if the cooldown doesn’t expire before they forget about it, they may never use it again! It sounds preposterous, but how many times have you seen someone go through a tutorial on how to use an ability, use it successfully once or twice and appear to understand how it works, and then get utterly baffled when required to use it again just a few minutes later? How many times has that happened to you when playing an unfamiliar game? I know it has happened to me more times than I can remember. (Sorry again.)

So, if a cooldown prevents a player from using an ability for more than 6 seconds, there is a risk that they will stop using it entirely. An onscreen indicator that a cooldown has expired helps, but habituation and change blindness limit how effective an indicator can be, especially when it changes very rarely. Repetition helps, because it transfers knowledge of the ability into more permanent memory, but even this is tricky because with a long cooldown what the player will be committing to memory is the fact that the ability is unavailable, making them even less likely to use it. The options, then, are to use very short cooldowns — between 6 and 12 seconds — or rely on a very noticeable reminder when ability is available again.

You missed a spot.

Indicators have their own problems

For an action game, where onscreen indicators are not desirable, long cooldowns lead to mechanics that are often ignored and quickly forgotten. Maroon walrus.

Simon says "Come up with a better idea"

Making Enemies III

The final fundamental question that needs to be answered when designing enemies for an action game is:

3.  How will the enemy overreact and expose their fatal weakness?

Every enemy needs a flaw, a chink in their armor that can be exploited by the player. A massive enemy with an equally massive health bar that virtually ignores you as you whittle away isn’t very satisfying. Their defeat is too gradual; the moment of their defeat nearly imperceptible. The true glory of victory isn’t the explosion or the death rattle, it’s before that, when the outcome is guaranteed, but not yet realized. That requires a fatal flaw.

  • A melee charge that travels a bit too far, letting the player get behind them
  • Running out of ammo at just the wrong time, leaving them defenseless at a crucial moment
  • Losing their temper and leaving cover, giving up their advantageous position
  • Realizing a second too late they are standing next to an explosive barrel

The issue for game designers is not the flaw, but calling the player’s attention to it. Shooting at the glowy bits is a common trope. It works precisely because it is a cliche, but it’s about as elegant as putting up a sign that says “Shoot here, dummy.” And not as effective, either. Using Water spells on Fire enemies makes more sense, but is about as exciting as turning a key in a lock. It’s easy to see why so many games have resorted to flashing random button sequences as a facsimile of exploiting a weakness, at least screen-filling UI prompts are hard to miss.

Simon says "Come up with a better idea"

The ultimate warrior

The problem is that there shouldn’t be a problem. Nature’s molded us into natural born killers.  We know when an enemy is vulnerable — from injury or inattention or separation from the herd — we can spot the target of opportunity if we see it. But there is so much going on in an action game, so much happening at such a relentless pace, it can be hard to filter out what is important. That’s why the best flaws are revealed when an enemy reacts to the player, or more accurately when they overreact.

The moment of reaction is ideal because the player is paying attention. Their action caused the reaction.  Everyone over-emphasizes the results of their own activity and focuses on the effects that they cause. They want to watch the ripples from the stones they are throwing. So they will be watching closely and are more likely to notice their opportunity. Also, since the player is the cause of the reaction, they will naturally experiment with it and understand the connection much faster. We are natural scientists, even children employ the scientific method, so giving the player control over the weakness will make them more likely to discover it.

Making it an overreaction will make it more obvious. It can be exaggerated and call attention to itself by being slightly inappropriate. It will also give the player the satisfaction of having outsmarted an enemy. It’s one thing to exploit a weakness they cannot control, but it’s so much better to capitalize on a mistake they shouldn’t have made. Provoking an enemy into a fatal error is one of the most satisfying experiences a game can provide, and the more cunning an enemy seems, the more delightful it is to fool them.

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.

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.

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.

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

Put to the Question

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.

Definition: Role

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.