Transcript GLS_DDA_2005 - Northwestern University

The Case
for Dynamic Adjustment
Robin Hunicke
Northwestern University
June 24, 2005
Background

University of Chicago




Interdisciplinary Studies
Autobiographical Narrative
Memory, Cognition, AI
Northwestern University



Reactive Robotics
Simulation and Games
Art & Technology
Also…

IGDA



Education Committee
WomenDev
Games



Indie Game Jam
Experimental Gameplay Workshop
GDC, etc
So…




Confront technical problems
Consider the design perspective
Facilitate interdisciplinary dialog
Diversity, diversity, diversity
Why Games?
Dream Scenario





Engaged Students
Solving problems
Analogizing
Extrapolating
Moving forward
… in the (digital) context of their choice
Reality




Engagement is hard
Curriculum design is hard
Computers are stupid
Software is expensive




Time
Money
Creativity
Planning
Scope




Fully interactive Agents/Narrative
Knowledge-rich training applications
Granular simulations/systems
Video games




Significant physical simulation
Little knowledge and training
Fixed narrative
Remedial agents
Games: A View

Some rules


Some simulation


Dynamics or “gameplay”
Some agents



Affordances, mechanics
Create obstacles
Deliver information
All: React to the player
Game AI

Typically

Improve the agents




Reactions to simulation
Each other
Player
Alternately

Build new systems


Natural Language
Drama Manager
Or…

Systems for dynamic adjustment




Track state
Observe patterns
Adjust accordingly
In particular

Difficulty

The player’s experience of challenge and triumph at
the controls.
Engagement
Challenge




Obstacles
Conflict
Rules
System
…Flow
Flow
High
Skill
increasing challenge
Too Difficult
Flow
Channel
Low
Skill
Too Easy
increasing skill
M. Csikszentmihalyi
Tennis
Volley for
3 hours in
hot sun?
increasing challenge
Backhand?
Flow
Channel
Hit the
ball?
Beat Your
Boss?
increasing skill
Training
increasing challenge
New tasks
Improved
Skill
Flow
Channel
New
skills
New Goals
increasing skill
Engagement = Cyclical


Each challenge = new trip
Designer and Player


Understand these patterns
Control them
Success
10
sec.
time
10
min.
1
hr.
10
hrs.
Failure
W. Wright
Flux vs. Flow



Regulating this feedback
Engineering chaos, then calm
Keeps the player “engaged”
Difficulty
Game Difficulty



Typically static at run-time
Tuned by playtest
Flow happens
– but only for a niche
Experiencing Flow


Expand the flow channel?
Can AI help?
FPS as a Base Case
Die
Win
(or retreat)
Enemy
Fight
Search
Spawn
Find
Die
Obstacle
Get
(or not)
Find
Solve
(or not)
Object
Gameplay Mechanics






Health
Ammunition
Enemy Type/HP/Accuracy
Weapon Type/Strength/Accuracy
# of Targets
Distance
Enemy Dynamics




Number
Strength
Accuracy
Variability in behavior



intelligence
tactical behavior
surprise
Overall Aesthetics



Ramping challenge
Responsive reward
Sense of gradual, earned mastery
Games are Didactic



Pleasure comes from mastery
Design reinforces learning curve
Genre-based cues


crates and sewers
health and bosses
Games are Didactic



Pleasure comes from mastery
Design reinforces learning curve
Genre-based cues



crates and sewers
health and bosses
Resistance to DDA is understandable
Simulation at the helm

Forumla-1 Racing



The “better” it is, the harder it is
New players excluded
Adjustment can change this
Adjusting Difficulty
One Perspective
Flow In
Inventory
Level
Flow Out
Health
Health
Health
In A Nutshell

Look at





Player Inventory
Current obstacles
Performance over time
Generate projected probability of failure
Adjust accordingly
AI View of this Process
observations
User Model
Game Play
Session
conditions
actions
Action Planner
Dynamic Systems View
observations
State Estimator
Game Play
Session
states
actions
Control Policy
Estimation



Estimate probability of getting hit
Average measurements over time
Monitor and intervene when necessary


Continuous observation
Choice of control


Single-instance tweaking
Systematic tweaking
Something for Everyone

“Comfort Zone” Regulator



Babysitter
Trial and error
Steady supply, consistent demand
Something for Everyone

“Discomfort Zone” Tracking System



Boxing coach or Drill Sergeant
Ramping challenge
Sporadic supply, intense but erratic demand
Or…

You can just turn it off!
Hamlet
Hamlet

Half-Life mod





Monitor game statistics
Predict failure/death
Define adjustment actions and policies
Execute those actions and policies
Base Case for evaluation


Many options for adjustment
Chose simplest one
Game Chart

Some C# and C++ widgets


Display data
Play session traces
Health Basics

Observe



Damage done to player
Damage done to monsters
Store stats for each class
Expected Shortfall

In a nutshell:





For all “on deck” monsters
Sum damage and squared damage
Compute  and  of damage per class
Calculate probability of death
If needed – adjust!
ERF

1  1 1  erf
2

 h  t 


  2t  

h = current player health
 ,  = all on deck monsters

t = look ahead (300 ~ 10 seconds)

Right now

Comfort zone


30% or greater chance of death
15 points of health per intervention
Reported directly
 Not supported by the “in game fiction”


Interventions per look ahead
Threshold (avoid meddling)
 Currently pace-dependent

Comfort Zone
Comfort Zone
ERF and Health
ERF
Health
1.20E-01
100
90
1.00E-01
80
70
8.00E-02
60
6.00E-02
ERF
50
Health
40
4.00E-02
30
20
2.00E-02
10
0.00E+00
0
0
50
100
150
200
250
0
50
100
150
200
250
Users
Testing



40 users
Play the game
Fill out a form




1-5 scales with 1 and 5 labled
Some self-reporting
Half adjusted
Single-blind
Enviornment




Case Closed (mod of Half-Life 1)
Dell Dimension 8200
1.8 megahertz Intel Pentium processor
1 gig RAM, NVidia GeForce3 graphics card



125,000 CPU cycles
average of 69 microseconds per tick
0.6 microseconds for the ERF calculation
Questions




Performance
Challenge
Frustration
Enjoyment
Summary


People live longer, get farther
Low correlation between



how often it adjusts
how often people perceive adjustment
no correlation between perceived adjustment and
actual adjustment methods
Experts



Dying less - not mad about it
No change in perception of difficulty
Assumption

I’m kicking ass!
Novices




Living longer – not necessarily happier
Taste in games/activities
Typically negative from the beginning
Perception

I suck!
Context




What
When
How
How often
Slightly Off Topic


Health meter
Simons/Resnick



Ballart et al



Gorilla
Scene evaluation/replacement
Blocks
Intille
Ubi-comp
Slightly Off Topic


Change Blindness
Simons/Resnick



Ballart et al



Gorilla
Scene evaluation/replacement
Blocks
Intille
Ubi-comp
Design mitigates disruption, use it!
Design for adjustment

Levels



Dynamics (Enemies)




Layout
Maps
Off screen enemies
Dynamically constructed obstacles
So on
Mechanics (Weapons/Attacks/Powerups)
Programming

Engine




Hooks for constant monitoring
Data gathering and evaluation
Spontaneous/Remote control
Dynamic Content
Conclusion
Baby Steps



Fully realized, “aware” or “context sensitive”
games/applications a ways off
Starting at the bottom…
…but we can make progress!
Can we do better?



Best policies?
More robust policies?
Other factors?
“Even a little better is better”

10% less work

10% more fun
... or both!
Connect
[email protected]
www.cs.northwestern.edu/~hunicke/



www.igda.org
www.indiegamejam.com
www.experimental-gameplay.org