Valve’s Design Process for Creating Half-Life 2 Presented by David Speyrer and Brian Jacobson © 2007 Valve Corporation. All Rights Reserved. The Fuzzy Problem of “Fun” ¾ Obvious in hindsight -- “I know it when I see it” ¾ Has many solutions ¾ Subjective ¾ Defies direct analysis © 2007 Valve Corporation. All Rights Reserved. An Engineering Approach ¾ Define your goals and constraints ¾ Come up with an idea of how to meet them ¾ Perform an experiment to test the idea ¾ Evaluate the quality of the experiment ¾ Evaluate the quality of the idea ¾ Evaluate the quality of your goals ¾ Repeat © 2007 Valve Corporation. All Rights Reserved. Necessary Ingredients ¾ The right attitude ¾ Well defined, measurable goals ¾ Well communicated goals • Niche product? • Mass market? ¾ Well devised tests © 2007 Valve Corporation. All Rights Reserved. Defining Goals ¾ “Product focus” helps you define good goals ¾ Care more about the quality of the product than your particular contribution to it ¾ Filter all goals through the lens of customer experience ¾ Good customer experience equals success © 2007 Valve Corporation. All Rights Reserved. Engineering Game Design ¾ Goal is a fun game ¾ Ideas are your game designs ¾ Playtests are your experiments ¾ Evaluate your designs as a result of playtests ¾ Repeat © 2007 Valve Corporation. All Rights Reserved. What does “playtest” mean? ¾ QA? ¾ Balancing? ¾ Focus testing? ¾ Fun? © 2007 Valve Corporation. All Rights Reserved. Running a Good Playtest ¾ Are playtesters having the experience you designed? ¾ Is the experience you designed desirable? ¾ Learn about things that affect customer experience • Game code/NPC behavior • Effects art • Environmental art • Sound • Training • Pacing • Difficulty © 2007 Valve Corporation. All Rights Reserved. A Playtest in Progress © 2007 Valve Corporation. All Rights Reserved. Running a Good Playtest ¾ Make sure the people responsible for the design and execution are there • Simplifies evaluation • Prioritizes • Motivates ¾ Simulate the player “in their living room” • Don’t give them hints • Don’t answer any questions • Don’t provide extrinsic rewards ¾ Use external playtesters © 2007 Valve Corporation. All Rights Reserved. Questioning Playtesters ¾ Don’t rely too much on questions ¾ Often you learn more from what playtesters don’t experience ¾ Ask non-leading questions ¾ Can be great for measuring effectiveness of certain elements • Storytelling • Perception © 2007 Valve Corporation. All Rights Reserved. Design Iteration ¾ Often this occurs late in production • Some of your designs work, others don’t • Fix the most egregious problems ¾ Late playtesting is less valuable • It’s too late to make substantive changes © 2007 Valve Corporation. All Rights Reserved. Playtesting as Production ¾ Use playtest results to drive production! • Create 15 minutes of gameplay in rough form • Playtest • Use playtest to prioritize work for next week • Repeat until complete ¾ We felt done as soon as playtesting was no longer painful to watch © 2007 Valve Corporation. All Rights Reserved. © 2007 Valve Corporation. All Rights Reserved. © 2007 Valve Corporation. All Rights Reserved. Small Increments ¾ Do the smallest amount that lets you learn something about the player experience ¾ Use 1-2 week increments • Shorter results in not enough time to make changes • Longer results in churn and flail © 2007 Valve Corporation. All Rights Reserved. “I’m Just Worried That…” ¾ Don’t let theoretical problems prevent playtesting • They might not actually be problems • If they are problems, the playtest will prioritize which to solve first • Playtest may generate ideas of how to solve actual problems better ¾ Don’t worry about how it looks • Art production is less risky than gameplay production © 2007 Valve Corporation. All Rights Reserved. Other Benefits ¾ Useful for learning ¾ Easy to measure an element’s incremental value or damage ¾ A great way to avoid design arguments ¾ Can use playtest results to drive other aspects of production © 2007 Valve Corporation. All Rights Reserved. Playtesting as Production ¾ Solutions to playtest problems can be iterative ¾ Solve your problems in the right order ¾ Look for trends • Don’t overcorrect • Don’t oscillate ¾ Finish successful elements before moving on © 2007 Valve Corporation. All Rights Reserved. Product-level Benefits ¾ Allows you to schedule to a particular quality metric ¾ Scopes game design risk for key features ¾ Allows you to optimize toward your most successful elements ¾ Allows you to measure risk, speed, cost © 2007 Valve Corporation. All Rights Reserved. Playtesting as Production in Larger Projects ¾ Create multiple small independent design teams • Each chapter was done by a particular design team ¾ Create a sandbox for each team to work in ¾ Create processes to help with global decisions • Story • Global mechanics (weapons, NPCs) • Art • Consistency • Quality © 2007 Valve Corporation. All Rights Reserved. Process #1: Establish Initial Constraints ¾ A preproduction phase established initial product decisions • Story elements and settings • Art concepts/style guides • Major design principles • NPCs, mechanics, weapons, vehicles • Chapter progression and themes ¾ Prototype gameplay maps were created © 2007 Valve Corporation. All Rights Reserved. Process #1: Establish Initial Constraints ¾ Some decisions were used by design teams as constraints • Story, settings, design principles ¾ Others were treated as suggestions • Mechanics, weapons, enemy NPCs were picked up by design teams • Some elements never were adopted ¾ Some major elements in the shipping game were developed after this phase © 2007 Valve Corporation. All Rights Reserved. Process #2: Promote Design Economy ¾ Encouraged reuse of existing game elements in new ways ¾ Useful in helping with global consistency and quality • More of your game is about the same elements • More hands working on each element improves quality ¾ Used teamwide playtests to expose elements to other design teams • Successful elements naturally diffused through the game + = FUN © 2007 Valve Corporation. All Rights Reserved. Process #3: Establish Strike Teams ¾ Formed to address cross-team issues ¾ Some strike teams existed for the entire project • The “Weapons Cabal” ¾ Most were more transient • Occurred when a design team used another’s gameplay elements ¾ Decisions in well-tested maps were treated as constraints © 2007 Valve Corporation. All Rights Reserved. Process #4: The “Overwatch Cabal” ¾ Evaluated global product-level quality at Alpha ¾ Communicated high/lows to all design teams • List constructed from company-wide feedback ¾ Consisted of a member from each design team and art/sound/animation teams ¾ Design teams were responsible for addressing feedback • Cuts/changes were driven by individual teams • All changes were made during the Alpha period © 2007 Valve Corporation. All Rights Reserved. Alpha ¾ What kind of changes should you make during Alpha? • Don’t introduce major new elements • Be ruthless and cut your worst problems • Do add density if necessary using existing elements ¾ Some aspects of your game can’t be measured until it’s all there • Pacing • Difficulty curve • Variety • Chapter-to-chapter inconsistencies © 2007 Valve Corporation. All Rights Reserved. Conclusions ¾ Engineering process can be applied to game design ¾ Let your production teams drive your design ¾ Use playtesting to drive game production ¾ Large teams can use this technique if the appropriate processes are in place ¾ Allow for a final iteration over your entire game once it’s playable from beginning to end © 2007 Valve Corporation. All Rights Reserved..