The Case for Dynamic Adjustment

1
The Case for Dynamic Adjustment

• Robin Hunicke
• Northwestern University
• June 24, 2005

2
Background

• University of Chicago
• Interdisciplinary Studies
• Autobiographical Narrative
• Memory, Cognition, AI
• Northwestern University
• Reactive Robotics
• Simulation and Games
• Art Technology

3
Also

• IGDA
• Education Committee
• WomenDev
• Games
• Indie Game Jam
• Experimental Gameplay Workshop
• GDC, etc

4
So

• Confront technical problems
• Consider the design perspective
• Facilitate interdisciplinary dialog
• Diversity, diversity, diversity

5
Why Games?
6
Dream Scenario

• Engaged Students
• Solving problems
• Analogizing
• Extrapolating
• Moving forward
• in the (digital) context of their choice

7
Reality

• Engagement is hard
• Curriculum design is hard
• Computers are stupid
• Software is expensive
• Time
• Money
• Creativity
• Planning

8
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

9
Games A View

• Some rules
• Affordances, mechanics
• Some simulation
• Dynamics or gameplay
• Some agents
• Create obstacles
• Deliver information
• All React to the player

10
Game AI

• Typically
• Improve the agents
• Reactions to simulation
• Each other
• Player
• Alternately
• Build new systems
• Natural Language
• Drama Manager

11
Or

• Systems for dynamic adjustment
• Track state
• Observe patterns
• Adjust accordingly
• In particular
• Difficulty
• The players experience of challenge and triumph
  at the controls.

12
Engagement
13
Challenge

• Obstacles
• Conflict
• Rules
• System
• Flow

14
Flow
High Skill
Too Difficult
Flow Channel
increasing challenge
Low Skill
Too Easy
increasing skill
M. Csikszentmihalyi
15
Tennis
Volley for 3 hours in hot sun?
Backhand?
Flow Channel
increasing challenge
Hit the ball?
Beat Your Boss?
increasing skill
16
Training
Improved Skill
New tasks
Flow Channel
increasing challenge
New skills
New Goals
increasing skill
17
Engagement Cyclical

• Each challenge new trip
• Designer and Player
• Understand these patterns
• Control them

18
Success
10 sec.
10 min.
1 hr.
10 hrs.
time
Failure
W. Wright
19
Flux vs. Flow

• Regulating this feedback
• Engineering chaos, then calm
• Keeps the player engaged

20
Difficulty
21
Game Difficulty

• Typically static at run-time
• Tuned by playtest
• Flow happens
• but only for a niche

22
Experiencing Flow

• Expand the flow channel?
• Can AI help?

23
FPS as a Base Case
Die
Win (or retreat)
Enemy
Fight
Search
Get (or not)
Spawn
Find
Find
Object
Solve (or not)
Die
Obstacle
24
Gameplay Mechanics

• Health
• Ammunition
• Enemy Type/HP/Accuracy
• Weapon Type/Strength/Accuracy
• of Targets
• Distance

25
Enemy Dynamics

• Number
• Strength
• Accuracy
• Variability in behavior
• intelligence
• tactical behavior
• surprise

26
Overall Aesthetics

• Ramping challenge
• Responsive reward
• Sense of gradual, earned mastery

27
Games are Didactic

• Pleasure comes from mastery
• Design reinforces learning curve
• Genre-based cues
• crates and sewers
• health and bosses

28
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

29
Simulation at the helm

• Forumla-1 Racing
• The better it is, the harder it is
• New players excluded
• Adjustment can change this

30
Adjusting Difficulty
31
One Perspective
Flow Out
Flow In
Inventory Level
32
Health
33
Health
34
Health
35
In A Nutshell

• Look at
• Player Inventory
• Current obstacles
• Performance over time
• Generate projected probability of failure
• Adjust accordingly

36
AI View of this Process
observations
User Model
Game Play Session
conditions
actions
Action Planner
37
Dynamic Systems View
observations
State Estimator
Game Play Session
states
actions
Control Policy
38
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

39
Something for Everyone

• Comfort Zone Regulator
• Babysitter
• Trial and error
• Steady supply, consistent demand

40
Something for Everyone

• Discomfort Zone Tracking System
• Boxing coach or Drill Sergeant
• Ramping challenge
• Sporadic supply, intense but erratic demand

41
Or

• You can just turn it off!

42
Hamlet
43
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

44
Game Chart

• Some C and C widgets
• Display data
• Play session traces

45
Health Basics

• Observe
• Damage done to player
• Damage done to monsters
• Store stats for each class

46
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!

47
ERF

• h current player health
• all on deck monsters
• t look ahead (300 10 seconds)

48
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

49
Comfort Zone
50
Comfort Zone
51
ERF and Health
52
Users
53
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

54
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

55
Questions

• Performance
• Challenge
• Frustration
• Enjoyment

56
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

57
Experts

• Dying less - not mad about it
• No change in perception of difficulty
• Assumption
• Im kicking ass!

58
Novices

• Living longer not necessarily happier
• Taste in games/activities
• Typically negative from the beginning
• Perception
• I suck!

59
Context

• What
• When
• How
• How often

60
Slightly Off Topic

• Health meter
• Simons/Resnick
• Gorilla
• Scene evaluation/replacement
• Ballart et al
• Blocks
• Intille
• Ubi-comp

61
Slightly Off Topic

• Change Blindness
• Simons/Resnick
• Gorilla
• Scene evaluation/replacement
• Ballart et al
• Blocks
• Intille
• Ubi-comp
• Design mitigates disruption, use it!

62
Design for adjustment

• Levels
• Layout
• Maps
• Dynamics (Enemies)
• Off screen enemies
• Dynamically constructed obstacles
• So on
• Mechanics (Weapons/Attacks/Powerups)

63
Programming

• Engine
• Hooks for constant monitoring
• Data gathering and evaluation
• Spontaneous/Remote control
• Dynamic Content

64
Conclusion
65
Baby Steps

• Fully realized, aware or context sensitive
  games/applications a ways off
• Starting at the bottom
• but we can make progress!

66
Can we do better?

• Best policies?
• More robust policies?
• Other factors?

67
Even a little better is better

• 10 less work
• 10 more fun
• ... or both!

68
Connect

• hunicke_at_cs.northwestern.edu
• www.cs.northwestern.edu/hunicke/
• www.igda.org
• www.indiegamejam.com
• www.experimental-gameplay.org