Tag Archives: 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 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.

Nerf Herders?

Against Statistical Design

Posted on by

Statistical Design

I suggested that a good way of improving one’s design sense is by staring at Rorschach Tests, and here is a practical example of the importance of practicing pattern-avoidance.

To me it looks like a designer's brain in a vice

Stop seeing patterns!

This image is a heatmap showing where people most often die on Assembly, a Halo multiplayer map.  These heatmaps were first used by the Halo design team to analyze maps during testing, but were so interesting looking they became part of the bungie.net statistics pages.  This data is so rich — so detailed and specific — it must be useful to a designer in some way, right?  The problem-loving brain of the game designer latches on to this as The Solution and immediately starts searching for The Problem.  It is tempting, given a powerful tool like statistical analysis, to incorporate it into the design process somehow — especially since design is often stranded in a world of abstraction and uncertainty.  Having concrete numbers is a rare treat.

However, what does this data mean?  Are red areas bad?  Should dark areas be eliminated?  Does a well-designed multiplayer map have a symmetrical shape?  What percentage of a map should be yellow?  Something about high-contrast feels unbalanced, so perhaps the map should be revised so that the gradient from safe to dangerous is more continuous.  And areas where nobody dies seem wasteful, maybe they should be removed.  And obviously the red areas will be frustrating, so they should be made safer by limiting line-of-sight and adding cover.  Pretty soon we have a completely yellow multiplayer map, that we have tricked ourselves into believing is balanced because our data looks pretty.  We have fallen victim to statistical design.

Players Aren’t Statistical

Statistics are powerful tools because they aggregate a large number of unique instances into a manageable form so it can be analyzed.  It would be impossible to watch every death of every player across thousands of games and have any cohesive understanding of how often players were dying in a given area.  Given enough examples, we would develop an emotional feeling of dread or security associated with certain spots, but the brain uses a very unscientific method to determine these attachments.  Exciting experiences are weighted much too heavily, which is why the impartiality of statistics is useful in discovering imbalances.  Using statistics to find problems is fine; designers go wrong when they use statistics to evaluate solutions.

Players don’t engage with the game statistically — they experience it personally.  It doesn’t matter if more players are killed standing in a specific spot than anywhere else on the map, what matters is the unique experience of a player killed in that spot.  If they realize that they shouldn’t have crested the hill with no cover that is right below where the Sniper Rifle spawns, vow not to do that again and move on, there is nothing wrong with the map.  Even if they do it over and over, growing more and more frustrated at their repeated mistake and creating a bright red dot on the heatmap, the map is not unbalanced.  However, if players are forced to expose themselves at a single chokepoint, or get sniped through a hidden line-of-sight in an otherwise safe area, it doesn’t matter if it is a rare experience and there is no red, the map ought to be fixed.  Neither of these situations can be found through statistical analysis, and neither of them are fixed by a solution that merely addresses the probability of being killed in a given area.

Avoiding Statistical Design

Some systems can only be balanced statistically.  If there are three factions in the game, and one faction wins 43% of the time, the factions are not balanced.  If a map is intended to be used for two-flag CTF, but the bases aren’t mirror images of one another, then the two sides had better be perfectly fair.  The necessity of reverting to statistical methods is inherent in the design of the system itself.  The designer will be forced to make changes that do not change the unique player experience — or may even harm it– in order to fix a statistical imbalance.  Worse still, players are skilled at detecting when a system must be balanced statistically, but since they do not have access to hard numbers their personal experience will tell them that it isn’t balanced — even when the data says that it is!

Nerf Herders?

Nerf Paladin?

Well-designed systems do not need to be balanced through data-manipulation.  If there are 10 weapons in the game, and one weapon is responsible for 20% of the kills, there is probably not a problem.  If the unique player experience isn’t negatively impacted, the statistical difference isn’t a balance issue.  So, the easiest way to avoid the trap of statistical design is to avoid systems that must be balanced mathematically in favor of those that can be balanced behaviorally.  If a system requires a large amount of instrumentation and is extremely sensitive to tiny value changes, instead of obsessing over statistical patterns, try revisiting the system’s design and making it less brittle.

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

Balance of Power II

Posted on by

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.

Balance of Power

Posted on by

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

Nice Gear

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.

Get it? Because neither one exists!

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 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…]

Shorting the Fun

Posted on by

Betting Against the Bank

A dizzying array of factors fed into the current global financial meltdown.  Sub-prime mortgages, anti-market regulation, credit default swaps, a real estate bubble, global conspiracy, global warming, alien sabotage… the list is endless.  But when it comes to the collapse of specific commercial institutions like Bear Sterns, it is pretty clear that short-selling accelerated or even guaranteed their failure.

A short sale (or shorting for… uh… short) is when an investor sells stock borrowed from a third-party with the intention of re-purchasing the stock and returning it at a later date.  If the stock goes down during that time, the investor gets to keep the difference as profit.  On the other hand, if the stock goes up they have to buy back the stock at the higher price and risk losing a great deal of money.  In March 2008, Bear Sterns (a global investment bank) became strapped for cash because it had over-invested in mortgage-backed securities and the bottom fell out of the housing market.  They might have been able to borrow the money to cover themselves, or at least gotten a bailout, but so many investors were short-selling Bear Sterns stock that it looked like collapse was inevitable.  This self-fulfilling prophecy ended with the company being sold to JP Morgan Chase a few weeks later.

Down with arrows!

Winning the race to the bottom

Shorting the Fun

Designers do the same thing, only instead of bringing down financial institutions, they bet against their mechanics and doom their game to mediocrity.

Take a Sniper Rifle, for instance.  Long and sleek, capable of putting a bullet through the head of a distant enemy faster than they can hear the sound of it being fired.  It has everything going for it.  Lethality to make it feel potent.  Precision to give it a high skill-ceiling.  A steady cadence with plenty of anticipation; each shot counts, but a miss isn’t a disaster.  Usable beyond the range of any counter-attack, even the hanging contrail it leaves behind is a testament to the thrill of each shot.  A designer couldn’t ask for a more perfect example of flow.

Then why do the Sniper Rifles in so many games suck out loud?  It just isn’t that hard to make a satisfying Sniper Rifle, so how do so many designers mess it up?  The surprising answer is that most Sniper Rifles probably started out fun, but at some point in development a designer got nervous about game balance and began to hedge their bets.  They made it less accurate, or decreased the damage, or added some weakness like an unstable crosshair or a really long reload time.  They were so afraid that they wouldn’t be able to make the Sniper Rifle work with the rest of the game, they shorted it and ended up losing a great deal of potential fun.

Still not a good idea...

Not to be confused with "fun shorts"

That’s how you get a Sniper Rifle that takes three shots to kill someone.  Or a tank that drives two miles an hour.  Or a spell that costs so much mana your mage can never use it in a fight.  Or any awesome and fun element with a crippling weakness that makes it all but useless.  Designers sabotaging their own games because they lost sight of what made something worth including in the first place!

  • Adding a Weakness – It may seem like the best way to balance an element that is too strong is to give it an equally large weakness, but it just doesn’t work out that way.  Either the weakness will not be enough, in which case you will have an element that is still too powerful and no longer fun to use.  Or it will be more than enough, in which case you will have designed an element that has a weakness as its defining feature instead of the original aspiration.  I would play as the invincible ninja character, but he has taken a vow of pacifism and doesn’t have any punches or kicks.
  • Creating a Counter – Another common way to address an overpowered element is to design a second element whose sole role is to counter the first.  Not only is this second element probably not fun on its own merits, but everyone will be saddled with choosing an option that they secretly hope they don’t have to employ, just to prevent everyone else from choosing the fun option they desperately want.  I will choose the unenjoyable anti-tank mine so that nobody else can have fun using a tank.
  • The Old Switch and Bait – Many games, especially those looking for a sense of progression, will initially introduce the player to a hobbled version of an element, and then unlock the truly fun version as a reward.  Of course, this ignores the fact that players usually won’t invest in a game that isn’t fun, and even if they do eventually earn the right to have fun, a vast majority of their experience will have been struggling through a crippled, unenjoyable game.  If I kill 300 more rats with this blunted shovel maybe I’ll get to use a real sword!… in this game that is ostensibly about swords.
  • Death of a Thousand Tweaks – Perhaps the most outwardly reasonable (and therefore the most nefarious) way of shorting fun is to make an endless series of minor changes, each one leaving the element a little less fun than it was.  Slightly less accurate, a touch less damage, a little longer reload, a smidge more recoil, a fraction less range, etc.  In this parody of the tuning process, the element gets gradually less fun until it is “unfun enough” to be included.  The problem is that tuning is more delicate than balance, so the element will lose the qualities that made it fun long before it becomes fair.  It will also leave players frustrated; if only this gun had been tuned better it would be really fun!

So, ignore the analysts and the pundits!  If an element or mechanic has the tiniest spark of fun, a designer’s job is to protect and nurture it, not smother it because it might out-shine the rest of the game.  No matter how tempting, there are always better options, so don’t short the fun!

So what are the alternatives to shorting the fun?



GDC 2010: Design in Detail VI

Posted on by


After paper design, we move to initial settings. Usually there is a period in between while the programmers build the system into the game.


Some of the best producers I have worked with really understood the fact that this stage needs some breathing room!


How many of you are familiar with the concept of Flow? Lots of talks have been done on this, I’m going to assume you know what I am talking about, in general.
The problem is, he wrote in the ‘70s, he doesn’t address video games. So what does flow look like in a video game?


Smiling makes you happy; laughing makes you healthy. Certain finger movements make you have flow. We call that Cadence! This timing for the Sniper Rifle is very specific, because the cadence determines the type of flow created. It is different for different weapons or different parts of the game, but cadence is important in all kinds of flow.


Verisimilitude: the quality of seeming to be true. For controls this means that the physical action of your character in some way corresponds to (or at least doesn’t clash with) the action taken by the player. Remember the Paper Design for Halo 1? It speculated that zoom was on a trigger. If I could go back in time, it probably would be.


The sniper rifle doesn’t unzoom as soon as you fire your last shot (even though that would be more efficient). It unzooms with a slight delay so you can see the results of your last shot. Why is this important?
Studies have shown that blue sleeping pills work better. They are chemically identical, but the placebo effect is enormous. Slow-mo explosions look more “real”. Ask any action director, authentic explosions look fake because we have been looking at slow ones for so long. Your brain has expectations and when those expectations are met, the effect is amplified and that encourages your brain to maintain flow.

Let me tell you a story.


The Sniper Rifle looks great on YouTube because you can really follow the action.  Even someone that has never played Halo can figure out what happened.  Maintining a thread from beginning to end is a key component of staying in the flow state.  For more information, check a specific post I wrote on the topic.

[Continued]

GDC 2010: Design in Detail V

Posted on by


The second way to develop a sense of balance about paper designs is to look for anticipation. (Anticipation really isn’t the right word for it, maybe “Imperfect Predictability”?) If you make players guess, they won’t see the point and will quit. If you don’t give them a chance, they will feel controlled and quit. Balance means probable, but not inevitable, future events. This allows the player to anticipate them.


Don’t your players into ridiculous movie villains.


David Sirlin (sirlin.net) is a SF Champion and a game designer (and just happened to be in the audience when I gave this talk at GDC.) He calls this concept Yomi.
In an action game like Halo you don’t want players to engage in this kind of second-guessing. It will paralyze them from acting and end up in random guessing. The Sniper Rifle has one purpose; you know what someone with a sniper rifle is going to do. The role prevents you from guessing by allowing them to anticipate what is going to happen. If they are expecting an event, they can process it more quickly and follow the action better.


Successfully sniping confers no benefits. As designers, we throw around the term “Feedback Loop” a lot, but they are not always good because they lead to a game being overly predictable. Anticipation requires uncertainty, and feedback loops work against that.


The best thing about roles is that they help you keep things manageable by breaking the design into workable parts.


If you are using roles, make sure players always have other options. The Sniper Rifle is never your only option, so the entire balance never rests on one weapon. By using multiple gameplay channels you reduce the difficulty of your balance problem.


If you break up the balance into groups that do not require cross-balancing your problem becomes simpler. I won’t say that monolithic is always bad, just harder.


The Sniper Rifle is not on every map. This limits the number of possible interactions that need to remain balanced.


Imagine somebody is holding a gun to your head… There is too much to do, what are you going to cut! What are you going to do? How can you get control of your scope? By making the hard choices…


What are the hard choices in the paper design pass? Which mechanics will you emphasize? How will you engage the player’s imagination?


Producers, please insert your fingers in your ears at this time. Some of the best advice I ever got was “Once you are done, cut half” and I have never regretted doing this. I’m not going to say “Kill your babies” Now that I am going to be a dad, the term doesn’t seem appropriate anymore. How about “Put your babies up for adoption”?

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]