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 Affordances, mechanics

Some simulation Dynamics or “gameplay”

Some agents 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

Too Difficult

Too Easy

FlowChannel

LowSkill

HighSkill

increasing skill

incr

easi

ng

ch

alle

ng

e

M. Csikszentmihalyi

Tennis

Backhand?

Beat Your Boss?

FlowChannel

Hit the ball?

Volley for 3 hours in hot sun?

increasing skill

incr

easi

ng

ch

alle

ng

e

Training

New tasks

New Goals

FlowChannel

Newskills

ImprovedSkill

increasing skill

incr

easi

ng

ch

alle

ng

e

Engagement = Cyclical

Each challenge = new trip Designer and Player

Understand these patterns Control them

Failure

Success

10sec.

10min.

1hr.

10hrs.time

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

Object

Enemy

Search

Obstacle

Spawn

Win (or retreat)

Die

Fight

FindFind

Get (or not)

Solve (or not)

Die

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 Flow OutInventory Level

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

Game Play Session

User Model

Action Planner

observations

actions

conditions

Dynamic Systems View

Game Play Session

State Estimator

Control Policy

observations

actions

states

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

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

11 12 2

h terf

t

,

Right now

Comfort zone 30% or greater chance of death 15 points of health per intervention

Reported directlyNot supported by the “in game fiction”

Interventions per look aheadThreshold (avoid meddling)Currently pace-dependent

Comfort Zone

Comfort Zone

ERF and Health

ERF

0.00E+00

2.00E-02

4.00E-02

6.00E-02

8.00E-02

1.00E-01

1.20E-01

0 50 100 150 200 250

ERF

Health

0

10

20

30

40

50

60

70

80

90

100

0 50 100 150 200 250

Health

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

Gorilla Scene evaluation/replacement

Ballart et al Blocks

Intille Ubi-comp

Slightly Off Topic

Change Blindness Simons/Resnick

Gorilla Scene evaluation/replacement

Ballart et al Blocks

Intille Ubi-comp

Design mitigates disruption, use it!

Design for adjustment

Levels Layout Maps

Dynamics (Enemies) 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

hunicke@cs.northwestern.edu

www.cs.northwestern.edu/~hunicke/

www.igda.org www.indiegamejam.com www.experimental-gameplay.org