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 player’s 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