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
2007 Valve
Valve Corporation.
Corporation. All
All Rights
Rights Reserved.
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.