Valve`s Design Process for Creating Half

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.