Tag Archives: slides

GDC 2010: Design in Detail XIX

Posted on by


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 by


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

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

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


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

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

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


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

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

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


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

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


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

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

GDC 2010: Design in Detail XVII

Posted on by


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


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


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


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

GDC 2010: Design in Detail XVI

Posted on by


Sometimes you have to let your head drive.

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


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


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


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

GDC 2010: Design in Detail XV

Posted on by


Without anyone getting kicked in the face…


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


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

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


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


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


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

GDC 2010: Design in Detail XIV

Posted on by


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


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

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


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


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

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

GDC 2010: Design in Detail XII

Posted on by


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 XI

Posted on by


So how do you recognize strength when you see it? How can you train yourself to appreciate strength?


The first way to develop a sense for strength is to change the balance constantly. People hate it because it resets their competence, but it will prevent them from optimizing their skills and their strategies. One theory about Beginner’s Luck is that when you first attempt a new skill your brain is very engaged and thinks the entire action through very carefully. On subsequent tries, your brian gets lazy and tries to take shortcuts, so you are more likely to be successful on your first try than on subsequent tries. Also, development is hard, and deadlines are approaching, so the temptation is to lock things down as soon as possible. Resist temptation and keep the balance changing until you find the true strength of the game elements.


As you strengthen an element, the other elements become relatively weaker. After a pass through the elements, you will find that the first one can no longer compete, and must be strengthened again. Keep doing this until all the elements feel powerful.


This guy is really good at Halo…


Pro-players often complain that “The guys making decisions suck at their own game” and it’s true! I’ll admit that I’m not very good at Halo. I’ll even claim that I’m not good on purpose! The problem is that the dopamine released for being a good player is the same as the chemical reward for being a good game designer. Since you can’t tell the difference, you may mistake the thrill of winning for the satisfaction of balancing the game. You should always feel like you are learning about your game, and if you start to feel like you have mastered it you need to change something so you aren’t good again.


You must acknowledge your own tendency to optimize and ignore problems once they have become familiar. Don’t work on the same element for too long, don’t become comfortable. If something feels so familiar you stop noticing it, change it.


At the same time, if something is right, if it is just perfect and you don’t want to lose it, you need to play it so much that it becomes part of you. I can still, after years and years, drive a new Warthog and tell you if it is tuned correctly or not. I’m known in the Animation Pit as “Three Frames” Griesemer, because if they added a single extra frame to a Halo melee attack I could tell immediately. You need to hone your sensitivity by playing with a finely tuned element over and over until it is ingrained in your muscle memory.

GDC 2010: Design in Detail IX

Posted on by


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.

[To be continued…]

GDC 2010: Design in Detail II

Posted on by


In order to develop a sense of balance, you need to understand how your brain works. You have an Orbito-Frontal Cortex; It’s called that because it is located behind your eyes, but it’s really your Gut.  When you learn something new, it goes through a process where it builds a model of the world and makes predictions about that model.  If it is right, it releases Dopamine, which cements the model a little bit.

If you are a designer, you need to familiarize yourself with how this process feels, because your ultimate goal should be to get the game inside your head.  You want the model in your gut and the game in the world to be the same.  You should be able to predict how the game will play in a given situation before actually picking up the controller.


Ok, back to Halo 2.  We had to patch, even though we didn’t want to.  Patches are risky and expensive.  Luckily we had network bugs, so we were going to have to patch anyway.  (I’m not sure we would have gotten to patch Halo 2 strictly for balance changes; I’m glad we didn’t find out.)

Choosing what to patch was harder.  You want to tweak everything, but you can’t because then testing gets out of hand.  Games that have the ability to easily change the gameplay often over-patch fopr precisely this reason.

Choosing what NOT to patch was hardest.  We didn’t change the Sniper Rifle because it was right below the line of what we could safely re-balance

Which brings me to my final theme:  Make the hard choices.  Balancing is hard because it requires you to do things you don’t want to.  And it is tricky because there are so many ways to confuse or talk yourself out doing it properly.  But the worst thing you can do is leave the decision up to chance because you can’t make a tough call.


Why are these choices hard?  Again, the answer is your brain.  You also have a Pre-Frontal Cortex.  It’s called that because… Who knows?  We call it your brain.

It is a poor tool, but it’s what we have.  You can’t reason out everything, in fact you can’t reason out very much at all.  There are so many ways that your logical mind has to trick you.  You must confine yourself to reason on the detail scale.  You just can’t hold enough factual information in your brain to make rational decisions about very complex situations.


Radiolab is a great show on New York Public Radio.  They have a podcast, you should subscribe!  In an episode called “Choice” they describe this experiment where psychologists give people a number to memorize, 2 digits to 10 digits.  Then they send them to another room to repeat their number.  On the way, they have someone interrupt them (All good psychological tests are about fooling the subjects) and ask them if they want an Apple or some Cake.

The people with short numbers pick Apples at a high rate; Apples are better for you, fewer calories, watch your waistline.  Those trying to remember longer numbers more often choose Cake.  They are so busy with numbers, they make the decision emotionally.

That’s right, 7-10 numbers are enough to completely fill your rational brain!  My high school calculator had more horsepower than that!

So when you have to think rationally, think about details or you will get hopelessly lost.  And fat.


Ok, here are the four themes of my talk:
– Balance is longevity
– Balance in passes
– Develop your sense of balance
– Make the hard choices

I am going to use these themes to explore the Detail.  Now let’s get to the Sniper Rifle!

[Continue]

GDC 2010: Design in Detail

Posted on by


Ok, so when I gave this talk at GDC I didn’t have time to finish, even though I was talking very fast.  I did better when I gave it at Blizzard, until my voice ran out and I could barely speak.  So I probably should have cut some ideas out and saved them for this year.

I do see the irony of failing to trim a talk that advices designers to drastically reduce the scope of their game as early as possible.  But to me, the value of GDC has always been that it makes me think about my own problems from a different perspective and inspires new ideas as I listen.  So I wanted to cram as much idea-fodder into the talk as possible, not produce a fluid, polished experience.


I did not make the call on the Pistol, I didn’t even know about that call, it was made directly to the cache file after everything was supposed to be locked down, in fact… but I’m not bitter about it.  I did decide to give the BR some spread, which has been the topic of much debate.  Luckily Reach has been even more controversial, so nobody remembers it anymore.  It’s interesting that every single Halo game has had major controversy over the MP starting weapon, I bet you could write an interesting talk about that.


In 2009 I was at the Art Institute of Chicago visiting my family.  (I grew up in and around Chicago.)  I saw one of the most famous paintings of all time and took a picture of it with my phone.  I actually did have the idea for this talk at exactly that moment, at least vaguely.  Any guesses as to the painting?


It’s “A Sunday Afternoon on the Island of La Grhand Zhot” by Zhorzh Soo-rah (I really wanted to pronounce his name right…heh)  This painting inspired my talk (and its very long title)  Still don’t recognize it?  Here it is from a little farther back.


(I showed you the part in the lower right by the monkey)
This painting isn’t famous for how it looks, or what it shows, but how it was made.


Seurat lived in the 1800’s.  He was very interested in how we perceive color.  Scientists were just discovering that what we see as one color is actually a mixture of different colored light.  To demonstrate this fact, he invented Pointillism, the artistic process of using tiny dots of basic colors to produce an image.  The same way your printer does.

There is a really great play called Sunday in the Park with George that I recommend you see if you are interested in learning more.  You can skip the final act, though.

So I started thinking…  What happens if we take Halo 3 and break it into it’s tiny details…


And analyze just one of them.  Take one tiny Decision, and explore it exhaustively.  Specifically, the time between shots for the sniper rifle.  (I had a lot of fun putting together the pictures for this slide deck.  I never tried to pointilize a screenshot before.)


So here is the actual title of my talk.

If you have been to GDC, you know that most of the talks are too broad to be really interesting.  It doesn’t get much more specific than this!  (Of course, I took this narrow topic and used it to explore lots of subjects and theories, but still…)


My opinions may not represent Bungie management.  In fact, I know they don’t.  (If I only knew the irony of that statement at the time!)  My opinions may not represent reality; this is the past as I remember it, but as we will find out, brains are not reliable.  All examples, even negative ones, are from good games.  I tried to pick on games that everyone knows are great, to avoid controversy.

This talk was really hard to write! Really hard. The more specific the topic, the more there is to say.  It ballooned to almost 300 slides, editing took forever (and it turns out I still didn’t edit it down enough!)


First, some context from Halo 2.


Halo 2 wasn’t just popular, it was popular for years and the Sniper Rifle remained balanced the whole time.  It never needed to be changed, limited, banned, it was still fun.

This can give us a practical definition of Balance:  Balance is Longevity.


(X= 3, I told them my talk would appeal to Engineers!)

Balancing an equation is a process.  But game balance is a state that either exists or it doesn’t.


The 4th rule of Jenga makes it clear (say it with me):

4. Your turn ends 10 seconds after you stack your block

It isn’t balanced unless it lasts.  (I bet you didn’t expect to see a Jenga reference!)


There have been other talks about Halo 2’s crunch; I’m not going to re-hash them.  My really quick personal post-mortem:  Don’t set yourself up to try and fix bugs in the Tutorial and balance the Weapons at the same time, It’s not going to work.  At least not without wrecking your personal life.

Production is always worried about a repeat.  (As you can tell during this talk, Production and I have a love-hate thing going.  It is mostly a joke, but Deisgn and Production have very different goals and the game is only going to work if they cooperate.)  They were always asking me when I am going to be done, so I invented the Balancer’s Paradox.

Balancer’s Paradox
– I can’t balance the Sniper Rifle damage until we set the Player’s health
– I can’t balance the player’s health until we know the engagement distance
– I can’t balance the engagement distance until we set the Sniper Rifle damage.

But after using this for awhile, I actually had to invent a solution…  Balance in passes.  The Sniper Rifle always has to be balanced! You could ship at any time!  So you keep it balanced all the time.  But there’s balanced, and then there’s balanced…


At the end of each pass, the game is balanced to a certain level.  Once a game is balanced to that level, do not backtrack.  Basically, what this means is that if you have balanced the strength of a game element, don’t make it weaker in order to limit the roles of that element.  Unless you have to, of course, in whic case it will impact the schedule so you need to let Production know.

Halo 3’s Balance Passes are listed here.  I think they would work for most games.  They match with stages of game development and I’ll go over them in more detail later.


Remember: Balance is Longevity.  And we could tell by playing it that it wasn’t going to last.  We all had the same feeling and we didn’t really doubt it.  But how did we know?  We had developed our sense of balance.


In Outliers, Malcolm Gladwell lays out his 10,000 hour rule.  This makes me the world’s only expert in trying to balance the Halo Sniper Rifle.  Sort of a narrow expertise, I admit.

Niels Bohr offers this definition of an expert.  This also makes me the world’s foremost expert in trying to balance the Halo Sniper Rifle (and in Driving too Fast for Conditions.)

But what are time and mistakes? They are just experience.  So why is experience so much more important to being an expert than training, knowledge or talent?  Because of how your brain works.

[Continue]