Download Slides - The collected game design rants of Marc LeBlanc

Document related concepts

Evolutionary game theory wikipedia , lookup

Chicken (game) wikipedia , lookup

Turns, rounds and time-keeping systems in games wikipedia , lookup

Deathmatch wikipedia , lookup

Replay value wikipedia , lookup

Game mechanics wikipedia , lookup

Artificial intelligence in video games wikipedia , lookup

Transcript
Is this thing on?
Game Design Workshop
Orientation
Marc “MAHK” LeBlanc
GDC 2004
Orientation Overview
Part I: Workshop Format
Part II: Outline Our Formal Approach
Part III: Formal Approach in Detail
Part IV: Tuning
Part I: Introduction
In this part we will:
• Explain the workshop high concept
• Describe the format
• Introduce the faculty
About The Workshop
• This is the fifth year
• Hands-on
• Focused on iterative design
• Grounded in a formal approach to
game design
• Intended to be open-ended
Things You Won’t Learn Here
• How to get a job as a game designer
• How to write a design document
• Where game ideas “come from”
• How to get your game funded
• How to use a level editor
In Other Words...
• It’s not about the Business
(Getting a job, pitching a game, getting funded)
• It’s not about the Profession
(Writing documents, tracking bugs, using tools)
• It’s about the Craft
(Making games that are fun)
What You’ll be Doing
• Playing games
• Analyzing games
• Critiquing games
• Modifying games
• Refining games
A Few Ground Rules
• Please attend the whole thing
• Collaborate, Share, and Encourage
• Save the “meta-discussion” for the
very end
Workshop Format
• Small-group activities.
 Main Exercises (3)
 Electives (choose 1 from 3 each day)
Introducing the Faculty
• Myself
• Andrew Leker
• Rob Fermier
• Steve Librande
• Jonathan Hamel
• Art Min
• Robin Hunicke
• Randy Smith
• Frank Lantz
• Tim Stellmach
Part II: A Formal Approach
In this section, we present:
• A formal framework for game design
• A view of the designer-player
relationship
Game Design “Frameworks”
• Paradigms for organizing our
understanding
Game Design “Frameworks”
• Paradigms for organizing our
understanding
• Example Frameworks:
 The 400 Project
 Design Patterns
Game Design “Frameworks”
• Paradigms for organizing our
understanding
• Example Frameworks:
 The 400 Project
 Design Patterns
• Separate from the process
Our Framework
• Grounded in a formal approach
• Organized around the designerplayer relationship
The Designer-Player Relationship


Designer
Player
The Designer-Player Relationship

Designer
Game

Player
The Designer-Player Relationship

Designer
Creates
Game
Consumes

Player
The Designer-Player Relationship

Designer
Creates
Game
Book
Consumes

Player
The Designer-Player Relationship

Designer
Creates
Game
Book
Movie
Consumes

Player
The Designer-Player Relationship

Designer
Creates
Game
Book
Movie
Painting
Consumes

Player
The Designer-Player Relationship

Designer
Creates
Game
Book
Movie
Painting
Chair
Consumes

Player
The Designer-Player Relationship

Designer
Creates
Game
Book
Movie
Painting
Chair
Car
Consumes

Player
The Designer-Player Relationship

Designer
Creates
Game
Book
Movie
Painting
Chair
Car
Pizza
Consumes

Player
The Designer-Player Relationship

Creates
Game
Consumes
Designer

Player
The difference is the way that
games are consumed.
An Extreme Opposite Example:
A Theatrical Play
The “design team” knows:
• Script
• Lighting
• Acoustics
• Seating
• Intermissions
Games, on the Contrary
The designer doesn’t know:
• When will the player play?
• How often? For how long?
• Where? With Whom?
And most importantly...
• What will happen during the game?
Obligatory Editorial
This lack of predictability is the essence
of play.
It should be embraced, not eschewed.
Games as Software
Code
Games as Software
Code
Process
Games as Software
Code
Process
Requirements
Games as Software
Code
Rules
Process
Requirements
Games as Software
Code
Process
Rules
Activity
Requirements
Games as Software
Code
Process
Requirements
Rules
Activity
“Fun”
A Design Vocabulary
Code
Process
Requirements
Rules
Activity
“Fun”
A Design Vocabulary
Code
Process
Requirements
Mechanics
Rules
Activity
“Fun”
A Design Vocabulary
Mechanics
Process
Requirements
Dynamics
Game
“Fun”
A Design Vocabulary
Mechanics
Dynamics
Aesthetics
The MDA Framework
Mechanics
Dynamics
Aesthetics
Definitions
• Mechanics: The rules and concepts that
formally specify the game-as-system.
• Dynamics: The run-time behavior of the
game-as-system.
• Aesthetics: The desirable emotional
responses evoked by the game dynamics.
The Designer/Player Relationship,
Revisited
 Mechanics
Designer
Dynamics
Aesthetics

Player
The Player’s Perspective
Mechanics
Dynamics
Aesthetics

Player
The Designer’s Perspective
 Mechanics
Designer
Dynamics
Aesthetics
Three “Views” of Games
Mechanics
Dynamics
Aesthetics
But they are causally linked
The Building Blocks: Formal Models
•
•
•
•
No Grand Unified Theory
Instead, lots of little models
We can think of models as “lenses”
Models can be formulas or
abstractions
• Discovering new models is an
ongoing process
MDA is a “Taxonomy” for Models
• Knowledge of Aesthetics
• Knowledge of Dynamics
• Knowledge of Mechanics
• Knowledge of the interactions
between them
Properties of Good Models
We want our models to be:
• Formal (well-defined)
• Abstract (widely applicable)
• Proven (known to work)
On any given game, we expect to use several
different abstractions, not one big one.
Part III: MDA in detail
In this part, we discuss Aesthetics,
Dynamics and Mechanics in detail.
The Designer’s Perspective
 Mechanics
Designer
Dynamics
Aesthetics
Understanding Aesthetics
We need to get past words like “fun”
and “gameplay.”
• What kinds of “fun” are there?
• How will we know a particular kind of
“fun” when we see it?
Eight Kinds of “Fun”
Eight Kinds of “Fun”
1. Sensation
Game as sense-pleasure
Eight Kinds of “Fun”
1. Sensation
2. Fantasy
Game as make-believe
Eight Kinds of “Fun”
1. Sensation
2. Fantasy
3. Narrative
Game as unfolding story
Eight Kinds of “Fun”
1.
2.
3.
4.
Sensation
Fantasy
Narrative
Challenge
Game as obstacle course
Eight Kinds of “Fun”
1.
2.
3.
4.
5.
Sensation
Fantasy
Narrative
Challenge
Fellowship
Game as social framework
Eight Kinds of “Fun”
1.
2.
3.
4.
5.
6.
Sensation
Fantasy
Narrative
Challenge
Fellowship
Discovery
Game as uncharted territory
Eight Kinds of “Fun”
1.
2.
3.
4.
5.
6.
7.
Sensation
Fantasy
Narrative
Challenge
Fellowship
Discovery
Expression
Game as self-discovery
Eight Kinds of “Fun”
1.
2.
3.
4.
5.
6.
7.
8.
Sensation
Fantasy
Narrative
Challenge
Fellowship
Discovery
Expression
Submission
Game as mindless pastime
Clarifying Our Aesthetics
• Charades is “fun”
• Quake is “fun”
• Final Fantasy is “fun”
Clarifying Our Aesthetics
• Charades is
 Fellowship, Expression, Challenge
• Quake is
 Challenge, Sensation, Competition, Fantasy
• Final Fantasy is
 Fantasy, Narrative, Expression, Discovery, Challenge, Masochism
Each game pursues multiple aesthetics.
Again, there is no Game Unified Theory.
Clarifying Our Goals
• As designers, we can choose certain
aesthetics as goals for our game design.
• We need more than a one-word
definition of our goals.
What is an “Aesthetic Model?”
• A rigorous definition of an aesthetic goal
• States criteria for success and failure
• Serves as an “aesthetic compass”
Some examples…
Goal: Competition
Model: A game is competitive if players
are emotionally invested in defeating
each other.
Success:
 Players are adversaries.
 Players want to win.
Failure:
 A player feels that he can’t win.
 A player can’t measure his progress.
Goal: Realistic Flight Simulation
Model: Flight dynamics match user
expectations.
Success:
 Match a mathematical formula
 Pass our “realism checklist”
Failure:
 Counter-intuitive system behavior.
Goal: Drama
Model: A game is dramatic if:
• Its central conflict creates dramatic tension.
• The dramatic tension builds towards a climax.
Dramatic Tension
Clima x
Conflict
Resolution
Narrative Time
Goal: Drama
Success:
 A sense of uncertainty
 A sense of inevitability
 Tension increases towards a climax
Failure:
 The conflict’s outcome is obvious (no uncertainty)
 No sense of forward progress (no inevitability)
 Player doesn’t care how the conflict resolves.
On to Dynamics...
Understanding Dynamics
• What about the game’s behavior can
we predict before we go to playtest?
• How can we explain the behavior
that we observe?
Formalizing Game Dynamics
Input
(Player)
Rules
Output
State
(Graphics/
Sound)
The “State Machine” Model
Examples: Chess, Quake
Models of Game Dynamics
• Again, no Grand Unified Theory
• Instead, a collection of many
Dynamic Models.
• Dynamics models are analytical in
nature.
Some examples…
Example: Random Variable
Chance in 36
This is a model of 2d6:
2
3
4
5
6Die7roll8
9 10 11 12
Example: Feedback System
A feedback system monitors and regulates its own state.
Room
Thermometer
Heater
Too Cold
Too Hot
Cooler
Controller
An Ideal Thermostat
Example: Operant Conditioning
• The player is part of the system, too!
• Psychology gives us models to explain
and predict the player’s behavior.
Where Models Come From
• Analysis of existing games
• Other Fields:
 Math, Psychology, Engineering…
• Our own experience
On to Mechanics...
Understanding Mechanics
• There’s a vast library of common
game mechanics.
Examples
• Cards
 Shuffling, Trick-Taking, Bidding
• Shooters
 Ammunition, Spawn Points
• Golf
 Sand Traps, Water Hazards
Mechanics vs. Dynamics
• There’s a grey area
 Some behaviors are direct consequences of rules.
 Others are indirect.
 “Dynamics” usually means the latter.
Mechanics vs. Dynamics
• There’s a grey area
 Some behaviors are direct consequences of rules.
 Others are indirect.
 “Dynamics” usually means the latter.
• Dynamics and Mechanics are different
views of games.
Mechanics vs. Dynamics
• There’s a grey area
 Some behaviors are direct consequences of rules.
 Others are indirect.
 “Dynamics” usually means the latter.
• Dynamics and Mechanics are different
views of games.
• Dynamics emerge from Mechanics.
Interaction Models
• How do specific dynamics emerge
from specific mechanics?
• How do specific dynamics evoke
specific aesthetics?
Example: Time Pressure
• “Time pressure” is a dynamic.
• It can create dramatic tension.
• Various mechanics create time
pressure:
 Simple time limit
 “Pace” monster
 Depleting resource
Moving Forward…
Let’s hope the future brings us:
• A rich aesthetic vocabulary
• A eclectic library of game mechanics
• A catalog of formal models: Aesthetic,
Dynamic, Interaction
In other words,
“Formal Abstract Design Tools”
Part IV: Tuning
In this part we will:
• Define tuning
• Present a formal approach
What we mean by “Tuning”
Analyze
Test
Revise
Tuning is an iterative process.
We’re not limited to:
• Parameter tweaking
• “Fiddling with knobs”
MDA in the Tuning Process
• Aesthetic Models help us:
 Articulate our goals
 Point out our game’s flaws
 Measure our progress
• Dynamic Models help us:
 Pinpoint our problems
• Both kinds help us:
 Evaluate possible revisions
Learning From the Tuning Process
Between iterations, we re-evaluate:
• Our goals
• Our models
• Our assumptions
Sometimes we need to revise our own
thinking as well.
The Tuning Process
Before we start
•
Know our aesthetic goals
While we iterate
•
Aesthetic and dynamics models guide
our way
Between Iterations
•
Learn from the process
Time for Coffee...
Part V: Some Common Themes
Here are some themes you’ll see
throughout the workshop.
Theme: Dynamics and Fantasy
• Our game dynamics have meaning
within our game’s core fantasy.
• That meaning may or may not be
compatible.
• In order to remain faithful to our
subject matter, dynamics and fantasy
must be in alignment.
© Steve Jackson Games www.sjgames.com
Theme: State Space and
Design Flexibility
• The state space of a game is the set of
possible states the system can be in.
• The larger the state space, the easier
it is to make changes.
• As we modify our design, we can
expect the state space to grow.