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.
- 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.
- 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.
- 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.
- 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.
- 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”
Sorry, the comment form is closed at this time.