Tag Archives: sense of balance

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

Up, Up and Away!

Against Eschatological Design

Posted on by

The last few months of a game’s development is a magical time.  Ideally, everything is coming together, the team is firing on all cylinders, and the experience is getting better by the hour.  Bugs are getting fixed, the build is more stable and performs better, the art is looking polished, and playtest results begin to climb to their highest levels right as the game is locked down.  The difference between those last precious moments of post-production, where everything is happening too fast to follow, and the months (often years) of glacially slow progress at the beginning of a project are so stark, they create the perception that a switch has been thrown, that the game has suddenly become fun.  The designer’s new-found power to affect change, and the positive feedback from the rest of the team, leads to a feeling of vindication and exhilaration.  Finally, all the hard work has paid off and the game has crossed the Fun Barrier.

It is tempting, after the flush of this experience, to look back on a game’s development as a power curve.  To retroactively smooth out the experience so it fits a nice mathematical progression, making the outcome of a fun game inevitable from the start.  To pretend as if the only unknown was if the game would cross the Fun Barrier before the project ran out of time or funding.  To ensure success on the next project by figuring out how to increase the exponent on the power curve, to work harder and add features faster, to run more playtests and balance earlier, so the game has time to reach the steep end of its exponential curve.

Up, Up and Away!

Fun = (Iterations * Time) ^Talent ?

The problem is that fun doesn’t really work that way.  A player experiences fun as a binary switch, either they are having fun at a given moment or they aren’t, like a square wave.  There’s no such thing as almost fun; an experience doesn’t gradually go from 90% enjoyable to 100% fun in a continuous curve.  A game gets better because it sustains a fun experience for longer stretches at a time, with less unfun gaps in between.

Worst Line Rider level ever

Fun = Fun * Polish ?

An experienced game designer is sensitive to very short, almost subliminal moments where a mechanic is actually fun.  Even in an early prototype phase, they can detect these snippets and predict with confidence which mechanics have potential and which ones don’t.  So, instead of finding ways to be more effective at polishing hopelessly dull gameplay, they can quickly abandon mechanics that never display those glimpses of greatness and focus exclusively on eliminating or minimizing the unfun gaps in those mechanics are already fun in spurts.  This is why exceptional designers tend to produce simpler, more reliably enjoyable games with fewer mechanics that feel almost effortless to play.  And why the vast majority of average games are released with an abundance of features, but subject players to hours of tedium or frustration as they labor to find fleeting moments of fun on their own.

GDC 2010: Design in Detail XIII

Posted on by


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.

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 VII

Posted on by


But how do I know which initial settings will lead to flow? How do I train myself to set things up the right way? Or an even better question, how to I make myself into a good designer?


Sniping flow is very fragile because it is so easy to break. Distractions, misses, and frustration abound. It can be difficult to focus, especially when you are first setting a game up. They key is to master your own flow so that you can control the amount of distraction it takes to break your rhythm.

First, make yourself easy to entertain, so you while you are setting it up you can put yourself in a mindset that allows you to maintain flow. Practice filling in details that don’t exist yet. I’m not kidding, get your mouth engaged! I make motor noises when balancing the Warthog and say “pew-pew” for guns.  Kids are easy to entertain because they make up the fun as they go along.

Another technique is to play B-Games with an open mind. Try to see the fun in spite of all the problems. If you can’t have fun with an imperfect game, you won’t be able to find the flow in your own imperfect game.


On the other hand, don’t be satisfied with “sorta fun”. Sniping flow is supposed to have a high ceiling. By this I mean that when you get into a flow state, it should be incredibly deep. So don’t sell it short by being too easy to entertain. A good way to learn to do this is to play good games harshly. Play Halo and then rip the hell out of it. (I do!)
Warning: This is going to wreck your ability to play games. That’s ok because you get to make games, which is a lot more fun


Control over Flow is the essential design skill. In my opinion, control over flow is what makes someone a good designer. Don’t expect other disciplines to have it. Most Programmers see bugs. Most Artists see in still frames. Most Producers see inexplicable delays. But as a designer you should cultivate this conscious control. I imagine a fun thermostat inside my head that I can set at will.


I hate to say it, but most Sniper Rifles aren’t fun. And sniper rifles are easy compared to some things. I believe it is because so many designers skip past this stage and assume that they will be able to make it fun at the end, but find the fun first at all costs! Remember, you aren’t doing Science, you don’t need a control group. Just change stuff and try different configurations. This is why you do this step in private; you don’t need everyone to know all the dead ends you ran down.


Imagine you were trying to teach yourself how to drive. If you just fiddled with one control at a time, you might never figure it out. Pressing the accelerator before you find the ignition doesn’t do anything. You might misinterpret the turn signal until you see how the car operates in motion. Again, this is not science, it is training. You are training your powerful emotional brain through dopamine, and if you leave things static your brain will stop trying to figure it out.


Daniel Tammet has Asperger’s disease and it has given him amazing skill with numbers. He can just intuitively spot prime numbers. Everyone has this power to more or less extent. For me, there is an audible click when something hits the sweet spot, like a record player falling into the groove, that lets me know when something is going to be fun for players.

So, go with your gut!  Trust your heart.  Reach out with your feelings?

To be continued…

GDC 2010: Design in Detail IV

Posted on by


How do you develop your sense of balance for paper designs? It can be done, you can look at a paper design and have an intuition about how it will work. You are looking for the role, and for a couple key factors that are the results of the role.


The first thing you are looking for is to make sure the paper design is neither too simple, nor too complex. If your paper design is one sentence long, it is probably too simple. People are going to reach the limitations quickly and stop playing. (Remember, balance is longevity)

If it is more than a page long, it is likely too complex. People will never reach their comfort level, they will stop playing because they can’t understand what is happening. Balance is a barely manageable number of choices. (I bet I end up writing a post on this slide at some point.)


This is where roles come in because they provide depth without increasing complexity.

The Sniper Rifle is the best weapon in some situations. The Sniper Rifle has a clear role, times and situations where it is the best. The payoff for using the Sniper Rifle is different depending on what situation you are in. This is good, because game theory tells us that if all the possible strategies have the same payoff, players will pick randomly. As game designers we want to avoid choices that don’t ultimately matter.

Roles are also good because they cause asymmetry, which demand movement. There are incentives to move from one strategy to another depending on the situation.


One of the tropes of the design community… Rock, Paper, Scissors. But it’s a terrible game!!! Every choice has the same payoffs, so you pick randomly. There is no player agency if their choice is meaningless.

It’s a cool shirt, though (www.noisebot.com)

This was easily the most controversial slide in this talk. Several people took issue with the fact that RPS is a bad game because many journalists and designers improperly use it to describe a situation where one unit strictly dominates another, like in a good RTS. But imagine a RTS game where you could only pick one unit, you had to pick it before the game started, and if you picked wrong you couldn’t possibly win, It’d be a bad game!
The reason a RTS game works is because it isn’t RPS:
– You can play mixed strategies (choose more than one kind of unit)
– Strategies have different costs to play (tanks cost more than barbarians)
– You can change strategies mid-game
– Strategies rarely have an all-or-nothing payoff (10 Air units can usually kill 1 Anti-air unit)

So I am not using RPS in the casual sense of “a game with counter-strategies” but as defined in game theory; Hopefully that clears things up a bit.

I also got a lot of people saying, “RPS is the foundation of Street Fighter!” This is true, somewhat, more than the RTS case, anyway. but imagine a turn-based game of SF where the first hit wins the match. Again, a bad game.

The reason SF works is that it is also not really RPS:
-SF is a series of RPS interactions, so things like reputation and anticipation come in.
-It is played very quickly, so low level decision making and muscle memory determine your strategy more than choices, so it isn’t truly random.
-And even with that, most non-expert players tend to “button-mash” which is a great example of “random strategy”

Believe me, I am not trying to insult RTS games or SF (or even Ro Sham Bo Tournament Champions) but to encourage designers to see how roles lead to non-equal payoffs, and therefore avoid random strategies.


“Rock, Paper, Scissors, Lizard, Spock” is even worse game design. (This game is from the show “The Big-Bang Theory”) It looks more interesting, but it isn’t; it is just more complicated. It will still reduce to equal payoffs and random play.


This doesn’t even make sense! (Interesting note: Halo 1 was this close to shipping without a Shotgun, which makes even less sense…)


Avoid strict dominance…Wait, what is strict dominance?


Who picked the Health Potion? The single-use health replenisher you can buy for 30 rupees?
Who picked the Piece of Heart? The totally unique health-extender you can never buy?

Right, everyone picks the Piece of Heart. (If you didn’t, it’s ok, you were probably eight.)


Iterative deletion means you remove all the dominated strategies, then you remove all the strategies that were only good against those strategies. If you cut the Tank, cut the Anti-Tank Mine. Often when you are making cuts in the final stages of production, it seems like a good idea to cut a little bit from a lot of places, but it is uaully better to cut an entire game mechanic and all of the game elements that use it. Otherwise you end up with several systems that feel like they have missing pieces, rather than a single system that is entirely absent.


After GDC I got challenged to come with an example like Rock, Paper, Scissors that is good game design, so I invented Pirates, Ninjas, Sharks. Each has their own strengths. Ninjas are better at night, but Sharks always win in the water, while Pirates come in crews, etc. A good game is one that you can argue about forever.

[Continued]