Design by Numbers: Simultaneous Perception

Posted on January 30, 2012 by rewardingplay

Perceived Simultaneity Threshold: 100 milliseconds

Let me tell you how I got my nickname, Jaime “Three Frames” Griesemer.

Emily "Three Frames" Crazyhair

We were working on the melee animations for Halo 3, trying to get the timing right. There were already fast. Like, blink-and-you’ll-miss-it speed. The animators were having trouble because there wasn’t enough time to add a sense of anticipation and sell the impact properly. And for some unknown reason I wanted the damage keyframe to happen faster. “The melee animations can be as long as they need to be… as long as they’re exactly three frames.” We went back and forth about it, but eventually I traded three frame melee attacks for some extra flourish on the recovery after the hit. Everybody was happy.

Until the next day when I went back to try the new melee animations. I picked up the Assault Rifle. I pressed the B button. Three frames later, the butt of the rifle crunched into the face of a helpless alien invader. I picked up the Plasma Pistol. I pressed the B button. Three frames later, my left hook connected with a random marine that was looking at me funny. I picked up a shotgun. I pressed the B button. And for some unknown reason it didn’t feel right when I cracked open the head of a passing parasite. “Wait. That wasn’t three frames. Yeah, I’m sure, check the file. See… four frames!” (In hindsight, I’m lucky my uncompromising design demands didn’t earn me anything worse than a mocking moniker.)

What was the unknown reason? How could I tell the difference of only a single frame? Why did I insist on the speed at the expense of animation quality? The answer lies in our physiological limitations. What we experience as consciousness — as a stream of consecutive events in a clear and tidy order — is not nearly so neat. It’s a cacophony. A discordant mess. Your senses collect an incredible amount of information; they’re always on, always filling your nervous system with an unrelenting torrent of unfiltered data. It comes in at different speeds and at different times. The visual part is heavily processed, so it comes in late and is usually out-of-sync with the rest of your senses.

Your brain at work

Your brain is used to this. It is, in fact, extremely good at taking all that information and combining it into a coherent experience. So good, it can take distinct events and merge them. Asynchronous events like pressing a button and seeing a melee attack. This feeling of simultaneity greatly increases the player’s connection with the action on-screen. Instead of a second-hand signal that transmits their intentions, pressing the B button becomes the act of dishing out a knuckle sandwich. But that requires your brain to blur over the delay and merge the movement of your thumb with the satisfying crunch.

Below a certain time threshold, the brain takes two events that are functionally separate — one causes the other and could not happen at the same time — and gives the impression that they were simultaneous. It turns out that threshold is around 100 milliseconds, or a little more than three frames. The reason four frames felt wrong was because the events were experienced as distinct, disassociated actions. The extra time allowed my brain to distinguish between them, in a sense inserting the controller as a step in the process and reminding me that I was not actually the one wearing metallic boxing gloves. So, for games where it is important to give the player a feeling of direct control, be careful of crossing the 100ms threshold.

GDC 2010: Design in Detail XIX

Posted on July 25, 2011 by rewardingplay

And there it is! The big detail!

It’s a large change. It’s very easy to convince yourself that you can feel tiny changes, but you will be fooling yourself. The balance never hinges on a 2% difference in a single value!

It was a smaller change than we tried initially. I think originally we changed it to 0.9, which broke the flow and wrecked the weapon, but did fix the problem, so we knew we were on the right track. In general, you want to overshoot and then come back. You have to make sure your change accomplishes your goal, and then dial it back.

There are lots of ways to verify that a change was successful. In this case, the Sniper Rifle didn’t get any less popular; People still use it whenever they can get it. But Optimizers stopped using it exclusively.

The other reason we could tell it was balanced was because we could compare how the behavior we were seeing in playtests matched the desired role we described in our paper design. It’s not quite an objective test, but it should help. And most importantly, I no longer got nervous when I watched people use the Sniper Rifle. You should verify a change with both your brains and your guts.

Ship it!

At this point during my GDC talk, the audience started clapping, cluing me into the fact that I was completely out of time.
So I just went with the flow and ended it there, which was fine. I had walked people through the balancing process, brought up the important principles, and applied them to the sniper rifle change. But I had also intended to mention a couple of things about the last stages of balancing, which I will get into next week!

GDC 2010: Design in Detail XVIII

Posted on June 21, 2011 by rewardingplay

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.

Treating Iterationitis

Posted on June 15, 2011 by rewardingplay

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 June 10, 2011 by rewardingplay

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.

Against Statistical Design

Posted on June 9, 2011 by rewardingplay

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 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 May 31, 2011 by rewardingplay

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.

GDC 2010: Design in Detail XIV

Posted on May 11, 2011 by rewardingplay

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.

GDC 2010: Design in Detail XIII

Posted on May 6, 2011 by rewardingplay

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 May 4, 2011 by rewardingplay

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

Start with a fun game
Make a tiny change (usually after exhaustive debate)
Playtest extensively to see if those changes made the game better
If they did, keep them; if not, change them back
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.

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.

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.

GDC 2010: Design in Detail XII

Posted on May 2, 2011 by rewardingplay

Notice that these guys are getting stronger and stronger as we go?

I actually got this bug. Not only is it balance feedback presented with the authority of a bug report, it’s so incredibly early in the process, there is no way to know if the Sniper Rifle was balanced or not, since most of the game didn’t even work! Ideally, production would help shield a designer from this kind of inappropriate feedback, but in all likelihood they are the ones filing it in the first place. [Pause for laugh]

Remember, you are getting paid to be the designer, it is your duty to use your best judgment and not swing back and forth based on the latest feedback, especially at this early stage. Hopefully the team will understand that and you will get to see it through.

If you design by committee, you end up like these guys.

GDC 2010: Design in Detail X

Posted on April 6, 2011 by rewardingplay

A big part of knowing if something is strong or not is Affordance, a visual clue to the function of an object. Strength tends to be obvious; it’s not a hidden feature that a player is going to have to guess at. If an object doesn’t have affordance, it probably doesn’t have a strength. [Read more about Affordance]

This book is a hardcore textbook and it rocks. (And by that I mean it is dense and hurts your head.) The authors define competence this way and try to show that the desire to show competence is a major human motivator.

Sniping starts off hard, but the more you learn, the more competent you get. In general, strengths are things you can get good at, meaning you can demonstrate competence at using an element’s strengths. But why is competence so important?

Because competence is an implicit motivator and remember, balance is longevity, so you need your players to have long-term motivation.

[To be continued…]

Balance of Power II

Posted on April 4, 2011 by rewardingplay

Tank Beats Everything

Even in the case where an element cannot be limited by role, it can be limited by availability. Sometimes the Player should feel overpowered, either as a reward for a good player or as a temporary boost for an average player. A game that is nothing but a relentless competence test can become monotonous, especially once a player has reached the limits of their physical ability to get better. Giving them an occassional taste of unmitigated power relieves the pressure to perform and is an excellent palate cleanser. An element that is fun and fulfills a player aspiration but can’t be limited to a single role is an excellent candidate for this experience.

Take that, Rock, Paper and Scissors

A successful transition from “balanced” to “overpowered” usually requires some changes, though. It needs to be exaggerated so the sounds, effects, even the fiction, match the new power level. It should become a featured element on a single level or two, the player should feel special for getting to use it, and the enemy resistance should be ratched up as well to highlight how strong they have become. The element should also be made as modal as possible, so the player knows when the “overpowered” experience begins and it is clear when it is supposed to end and resume normal gameplay.

In a Corner

Let’s say an overpowered element doesn’t fit in any of these categories. It isn’t just a perceived imbalance, the other elements can’t be strengthened to an equivalent power level, the role can’t be limited or enforced, and it isn’t appropriate for an over-the-top set piece. If nothing else can be done, it has to be weakened somehow, right? Let me tell you about The Needler…

The Needler is a weapon from the Halo series. It fires a stream of neon pink projectiles that actively track enemy targets. On impact, each needle embeds itself into armor or flesh, remaining there for a few seconds before detonating and causing further damage. If a character ever has more than 5-6 needles attached at any given time, they all explode in a particularly lethal chain-reaction known as the “Pink Mist”. It first appeared in Halo 1 and was the bane of my existence for 10+ years because it was incredibly fun to use, but equally impossible to balance.

I feel a headache coming on

It would start out too powerful, so we would weaken it. Which would make it useless, so we would change the mechanics. Which would make it effective in too many situations, so we would limit its placement. We ended up drastically weakening it right before we shipped to prevent it from wrecking the game. Three times! The amount of effort, thought, debate, programming and art resources, playtesting surveys, data analysis and sleepless nights that were poured into the Needler far outpace any four other weapons combined.

So, even if an element cannot be balanced in any other way, the answer is still not to weaken it, but to cut it completely. It is too difficult to weaken an element without destroying what made it fun in the first place, and the end results won’t be worth the hassle. It’s best to just save it for another game where it will fit without compromise.

Balance of Power

Posted on April 1, 2011 by rewardingplay

“Iron sharpens iron, and one man sharpens another”

-Proverbs 27:17 [ESV]

“The whats-it is too powerful.” It could be a weapon, an RTS unit, a character in a fighting game, a multiplayer class… it doesn’t matter because all chronic balance problems follow the same general pattern. The game starts to revolve around a single dominant element, which is inherently overpowered and reduces the game’s strategic complexity, ultimately limiting its longevity. Nobody notices when a single element is too weak, because they just avoid it. And nobody complains when a dominant element increases strategic complexity, because that makes the game better and more fun. And a simple problem, like a damage value that is just set too high, usually has a simple solution that is quickly applied. But for chronic, fundamental balance problems, the designer is repeatedly faced with the same decision. Should the dominant element be weakened for the sake of balance? (Hint: The correct answer is always “NO!”)

Perception is Reality

First, it is important to recognize that the only “balance” that matters is the balance that players perceive. The goal of balance is longevity, and if players continue to play because they believe the game is fair, it doesn’t matter if it is objectively balanced in some measurable sense. In fact, if a large enough community perceives the game to be balanced, but your metrics claim it isn’t, then the metrics are wrong.

Sometimes power is deceptive

So often the problem isn’t that an element is too powerful, but that it feels too powerful. Maybe its a gun with a really great firing sound. Or a new unit that players haven’t figured out how to counter yet. Or perhaps it appeals more to skilled players or everyone is using it because it is new and novel. These problems usually fix themselves if they are left alone. I changed the perception of an “overpowered” weapon during Halo’s development just by announcing that I had fixed it (even though I hadn’t actually changed anything.)

The Tooth Fairy is Overpowered

In almost every case, there is no such thing as an “overpowered” element; there are well-tuned elements in a crowd of underpowered, ill-tuned alternatives. The Sniper class is implemented and all of the sudden you can’t take three steps without being headshot from across the map. The problem is not that the Sniper is strong, but that the Medic and the Engineer are weak. It’s easier to make a potent Sniper, so it immediately outclasses the rest. Instead of spending time figuring out how to cripple the Sniper, focus on making the other classes equally awesome. Or better yet, ditch the ones that will never feel as powerful as the Sniper and choose different classes that have their own natural strengths.

His only weakness is his terrible agent

Too Powerful, or All-Powerful?

In the paper design balance pass, every element should have been given a role to fill. Sometimes an element breaks the balance by breaking its designated role. An anti-vehicle missile that can be used against a crowd of infantry. A “glass cannon” that can hold his own in a melee fight. A long-distance weapon that is just as effective at point-blank range. The solution in this case is not to weaken the element, but to restrict it so that its strength cannot be applied in as many situations.

Often it takes ingenuity to limit a weapon without weakening it, but it isn’t as difficult as it might seem initially. A global weakness will affect the player in every situation, so a heavy-handed global weakness will be a constant irritation. But a specific limitation will only be felt when an element is being used outside its role, which a player can learn to avoid, eliminating the annoyance entirely. Nobody complains that their fancy sports car doesn’t work underwater, they just stay on the bridge.

[Continued in Balance of Power II]

GDC 2010: Design in Detail IX

Posted on March 30, 2011 by rewardingplay

Ok, now you have a flowing Sniper Rifle and all the other weapons are fun by themselves. How do you put them together?

This slide is for the Engineers. Design needs to start doing rough balancing in the middle of production, probably before you hit any kind of Code Complete milestones. Properly supporting the designers this early in the project is going to be mean violating several best practices, but we need as much time to iterate as possible.

First, we need a solid build at all times. Easy for me to say, right? But stability is important. If the build is broken it interrupts the balance process and I have to start over. And if you don’t maintain the gameplay systems the whole time, the game will not have time to get fun. It sucks, but that’s why you are working on games and not productivity software.

I know the theory is to “optimize at the end”, but it is impossible to balance a game with poor performance. Not everything has to run at a playable framerate; you can turn off lighting or textures or whatever it takes, but designers need a responsive platform on which to build. Imagine coding if you couldn’t see what you typed until two seconds after you typed it. That’s what it is like trying to tune a game with bad framerate.

For example, I have seen this in playtest after playtest. If you a level doesn’t have good lighting in a playtest build, the AI will score lower. People will think it looks stupid for some unknown reason. I don’t know why, but it shows how performance problems make it hard to balance the game.

During this pass, you are balancing strength.

In What the Dog Saw, Gladwell tries to figure out why there are 50 kinds of mustard, but just one kind of Ketchup. He concludes that Heinz is the best because it has all of the tastes in balanced proportions.

Heinz Ketchup has every flavor your tongue can taste. Here’s some of the ingredients: tomatoes (bitter), vinegar (sour), corn syrup (sweet), salt (uh… salt) And then you put it on french fries (umami). Every flavor is strong (ie has a high amplitude) but they are still balanced against one another.

Halo is like ketchup! It has lots of very strong elements, but since they are all strong they blend together into a balanced whole. In fact, without strength balance is much more difficult, because random factors destabilize the experience. A game with weak elements is like ketchup with weak flavors; if they become weak enough you start to taste the plastic from the bottle and the rat poop from the bottling plant.