GDC 2010: Design in Detail XIX

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

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.

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.

GDC 2010: Design in Detail XVI

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.

Definition: 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 XIII

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.

Balance of Power II

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.

No mana?  No problem!

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.

Like this, only a couple feet lower

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.