Double Buffered

A Programmer’s View of Game Design, Development, and Culture

GDC 2010: Design in Detail: Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3

Posted by Ben Zeigler on March 14, 2010

Here’s some notes from the session Design in Detail: Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3 presented by Jaime Griesemer from Bungie. He was in charge of multiplayer balance for Halo 1, 2, and 3 so has a lot of relevant experience. The talk was jam packed with information, so odds are very high that I missed something. At the end he was going pretty dang quick to fit it all in the hour session. Oh, and at some point he had a few slides about the odds of monkeys with typewriters reproducing the talk being like 0.2%, but it was pretty out of place so I honestly can’t remember where it fit in.

Designing Balance

  • Longevity means balanced. If a game like Halo 2 has been played and enjoyed by millions for years, it is balanced.
  • Balance can’t happen until the end of development, but you can’t wait until the end to balance because you won’t get it done. The solution is to balance in iterative passes. Once you’ve balanced at a certain level, don’t go backwards until you absolutely have to.
  • Passes are roughly (Note: I think I missed one) Role -> Flow -> Strength -> Limitations -> Detail
  • Two cognitive halves to balance. First, you have to develop an intuitive sense of balance. Using the non-rational part of reasoning, your brain (orbital frontal cortex) builds models and uses them to predict the future. If something feels wrong to you about the balance of the game, this is what tells you.
  • That part of the brain is great at telling you something is wrong, but not at telling you how to fix it. You have to use the other half to make the hard choices. Your brain (pre frontal cortex) needs to use reason to figure out what to change. But it can only work on so much information at a time. You have to work at a low detail level, and ONLY pay attention to info relevant to the current stage.
  • As an example, there’s an experiment from the Choice episode of Radiolab. Subjects were given either a long number or short number to remember, and then were ambushed with the offer of cake or an apple. People with the short numbers picked apples, but people with the long numbers picked cake, because they didn’t have enough reasoning capacity left to make a rational food choice and went with the emotional one. (Note: That episode of Radiolab is great, and as a fan I have to say you should all go read “How We Decide” by Jonah Lehrer. The evidence is really strong for Jaime’s point here).
  • The first part to each pass is going to be paper design. You need to plan out the behavior of all objects on paper before implementing them, so you can make sure they make sense. Figure out basic mechanics, desired feel, critical assets and important details.

Balancing Roles

  • When designing roles you have to balance simple against complex. The goal is to make the game barely manageable at it’s deepest.
  • Roles need to have actual functional differences. Rock-paper-scissors is not actually good design, as the 3 roles are completely identical. The depth in any multiplayer game comes from the roles and their interactions
  • For a shooter, you should have no more than 1 weapon per role. If you add weapons that satisfy the same role but are different, you’re simply adding complexity and NOT depth. All shooters have the same weapons because they have the same roles. (Note: And players realize that now and get bored)
  • Similarly, you can’t leave any role without a weapon. Rock-paper-nothing is not even a game.
  • When cleaning up your paper design you should practice iterative deletion. Delete whatever isn’t necessary to fill a distinct role, and then delete everything that NOW isn’t necessary. And so forth.
  • You have to balance chaos against certainty at this point. You want players to be able to think about probable, but not inevitable future results.
  • In a largescale multiplayer game you need to be careful about the levels of “yomi” needed to succeed. Basically you should stop at “I know what you know about me” and not get into too much recursion. If it looks like a gun it should be a gun.
  • Beware of positive and negative feedback loops. If doing well causes you to do even better this gets in the way of balance.
  • Use slots whenever possible instead of having to balance larger chunks. Always balance the core elements first. Cut half of whatever you do.

Balancing Flow

  • Flow can’t really be balanced until objects first start to come online during production. At this point, the designer is in charge and should be setting the tone. Feedback is not super important at this point in the process.
  • During this phase you need to get the cadence just right. If it’s too slow the player will get bored, and if it’s too fast the distinct events will star to blur together.
  • Verisimilitude is key at this point. Triggers should be for shooting and buttons are for punching, analogous to the real world action. Work on making it feel real.
  • This is where you add the first pass of spectacle. Think about sounds, control, animation. In the sniper rifle case it unzooms for reload 0.5 seconds late, just so you can see your target die satisfyingly.
  • Causality needs to be established. Your game has to look good on youtube, so you can tell what is making what happen. Players need to understand the causality of game events or they will think it cheats. Make this as obvious as possible, and throw out realism to establish it.
  • The flow of a game is fragile, so as a designer you’ll have to use your imagination to get in the flow state this early in dev. Make your own sound effects. Whatever works.
  • You want your game to have a low floor for flow so players can get into it, but a very high ceiling so they can always go deeper into an individual mechanic. Add as much detail as possible at the high end, to give them something to strive for.

Balancing Strength

  • To enter the next phase, gameplay needs to be functional and largely optimized. Framerate above graphics quality. It has to work.
  • Ketchup works because it’s 5 primary flavors, all pushed to the max. Halo (and by extension all game should) is like ketchup.
  • Affordance is key at this stage. If the strength of something has to be explained, then it isn’t really a strength.
  • It can be tricky to balance, because designers can misinterpret competence (getting good at a weapon) with the weapon being balanced. We CANNOT use our intuition at this stage because it will lie to us. Changes will have to be done in larger batches, and we need to avoid bias effects.

Balancing Limitations

  • Once everything is strong and useful, it’s time to start adding limitations. Limitations are not weaknesses. You add limitations to restrict the situations in which a role is successful, not add randomness.
  • If the same role wins in too many situations, add limitations. If the outcome of a certain role in a situation is essentially random, there may be too many limitations to be understandable by the players
  • Work on serious playtesting at this point. You want players to play, and you shouldn’t argue with them. Look for their reactions, NOT their solutions. “I don’t like x” is useful, “I don’t like x because of y” is great, and “You should do x” is useless. Trust the player’s gut (intuition) but don’t trust their reasoning as they do NOT have the same mental context you do as the designer. (Note: I 100% agree with and endorse this feedback strategy)
  • Negative feedback generally means that the game in their head does not match the game as it actually exists. Either try to match it better, or do a better job of realistically setting expectations via teaching.
  • Identify the specific goals of your playtester and keep that context in mind. Optimizers look to find the best overall, Ragers quit when frustrated, Role players always try the same weapon, “Your mom” will get confused, Griefers will try to destroy it for others, and Pros will hate you for any randomness.

Detail Balancing, and the Sniper Rifle Specifically

  • Look to see if any weapons are being used outside of the roles you initially designed. See if any weapons are strictly dominating others.
  • Eventually, using the Sniper Rifle hit the intuition of the designers. Using it felt wrong, something was out of balance, which was that the sniper rifle was too effective at close range, and too effective when getting body shots without nearby cover.
  • The first idea is to reduce the strength knobs. But you should avoid this as it’s going backwards, and it’ll make the weapon feel week. Don’t reduce damage, range, or add random weaknesses. Don’t make the sniper rifle worse at it’s primary role.
  • Couldn’t reduce sniper rifle magazine to 3, as then you couldn’t kill 2 ranged enemies without a reload. Increasing reload or time to zoom only fixed half the problem. Modifying max ammo count would fix the average problem but NOT the instantaneous problem, which is what people actually notice.
  • In this case Flow made sense to modify. The cadence was picked to make the sniper rifle feel fast and rapid fire (Note: rapid fire sniper with one shot kill is a weird concept, he didn’t explain the original idea behind this) but it needed to change. So, the time between shots was increased, because this didn’t weaken the original role but made it worse in other roles.
  • It went from 0.5 to 0.7 because you should never change anything less than 10%. Players won’t notice it at all, and a balance problem has to be fairly big to be noticeable in the first place. Overshoot and then come back if you can.

6 Responses to “GDC 2010: Design in Detail: Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3”

  1. […] 1:30PM: Design in Detail: Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3: I’ve been doing some detail oriented gameplay iteration, so I’d be happy to pick up some specific tips. I hope it’s more than just “cause we said so” (Posted my frantically written notes) […]

  2. Ben F said

    Overall a very good talk!

    One nitpick: he kept using Rock-Paper-Scissors to demonstrate errors in game design, despite asserting that Rock-Paper-Scissors was horribly designed to begin with. If Rock-Paper-Scissors isn’t good game design, then showing how it becomes broken in certain cases doesn’t really prove anything.

    Also, the “every role has to be filled” statement just seems like nonsense to me – one can always invent new roles, so how would you know when you’ve filled them all? I think the fact that all FPS games have the same set of weapons has much more to do with genre expectations than with some fundamental law of game design.

    Still, very cool talk overall!

    • JZig said

      For “Every role has to be filled” it was pretty clear that the way you find new roles is… you try it. Either in paper design or prototyping. There’s no need to go through the deletion process if every role you THINK exists really does exist. I imagine bungie has tried a variety of other roles, and none of them stuck. At least, that’s what I would do when trying to think up new gameplay roles.

  3. […] GDC 2010: Design in Detail: Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Sec… Ben Zeigler's notes on Bunge's Jaime Griesemer's talk at GDC, all about balancing. Sample quotation: "It can be tricky to balance, because designers can misinterpret competence (getting good at a weapon) with the weapon being balanced. We CANNOT use our intuition at this stage because it will lie to us. Changes will have to be done in larger batches, and we need to avoid bias effects." Really, the whole thing is jampacked with interesting stuff (not all of which I agree with, but most of it is very good indeed). (tags: bungie games design balance gdc gdc2010 psychology ) […]

  4. Aubrey said

    Ben F: the Rock Paper Scissors design is problematic only when every choice is equal. It turns the player’s guessing game into a random choice.

    Basically, if I pick scissors, and you *happen* to pick stone, you win, but because you could have equally lost, or drawn, you didn’t make any real decision (past the metaphorical flavour of the choice). Your win was effectively down to chance. Any choice I could have made was as good as another (though my past history of choices may affect yours… people don’t intuitively believe randomness. They tend to want to turn things into a pattern, and can veer toward predictability, too. For the same reason, a million monkeys on a type-writer would not produce the works of shakespere because they’re not likely to work purely randomly).

    When the choices are uneven (positive in some ways, drawbacks in others – i.e. the low risk, low reward jabs in streetfighter vs. the high risk, high reward special moves), your decision making process is far more nuanced, and the outcome far more interesting (whether or not you win the attack). Because there’s more weight to the choices of either party, the “yomi” process can begin – you considering what I will consider etc.

    You probably already know of him but David Sirlin goes into this stuff in more detail and is well worth a google.

  5. […] be more truthful the more a game moves away from a conventional Player vs. Environment game. Jaime Griesemer talks about ignoring the literal feedback of players, but never proposes lying to them in a […]

Sorry, the comment form is closed at this time.

%d bloggers like this: