Transparent Decision-Making and AI Design

1. Transparent Decision-Making and AI Design Damian Isla AI Lead, Bungie Studios

2. Agenda • Halo • Decision-making in Three Contexts • Behavior • Encounters • Dialogue • Conclusions

3. Halo

5. Complex Worlds • Physics • Physics-based animation • Projectiles • Effects • Damage propogation • Destruction • AI

6. Complex Worlds Halo is … • a simulation • a game

7. Complex Worlds What that actually means: • AI is full of rules to deal with complexity • (Practically) all of those rules are gameplay relevant • Therefore designers need access to them

8. AI Goals Game AI must be: • Coherent • for the player • Transparent • for the player • for the designer • Workable • for the engineer

9. Player Transparency • Player can explain AI behavior • “He dove out of the way because I threw the grenade.” • Player can predict certain AI behavior • “If I throw the grenade, I bet the AI will dive out of the way.” • Player forms an ongoing narrative in his/her head • “I threw the grenade, so he dove out of the way, and then cursed at me, and threw a grenade back, but I shot it in the air and hurt him, so he went nuts and charged me …” • The AI needs to facilitate / encourage that narrative

10. Designer Transparency • Designer can explain AI behavior • “He dove out of the way because his danger_dive behavior is active.” • Designer can predict certain AI behavior • “When I throw this grenade, there’s a 75% chance he’ll dive out of the way” • Designer knows how to achieve different behavior • “Hmm … he reacted to that grenade too quickly … I think I’ll increase his projectile-acknowledgement delay from 0.5 to 0.7 seconds.” • Design knows how to diagnose and fix MISbehavior • “WOAH … why the hell did he do THAT?!”

11. AI and Complexity • How do we go about making transparent AI? • In this talk, I will present three different approaches to decision-making that occur in the Halo AI.

12. Case 1: Behavior

13. Hide? • Panic? • Get in that vehicle? • Throw a grenade? • Hold my ground?

14. Behavior A program that takes temporary control of an actor to achieve a specific goal. • Fight • Hide • Enter vehicle • Throw grenade • etc. How do I decide what to do when? ~120 of these in total (i.e. ~ 7140 possible transitions)

15. Behavior FSM

16. Behavior FSM ???

17. Behavior Tree hide cover grenade fight fight melee shoot shoot root root uncover search pursue idle sleep

18. Behavior Tree Three Simplifications: • No sibling connections • Binary activation functions • Prioritized list decision-making Benefits: • No more n2 complexity • Scalability

19. Behavior Tree: Designer Tools bool hide_relevance() { if (damage > MAX_DAMAGE) { return true; } else { return false; } } • Behavior Parameters • Styles • Inhibition Groups • “Turn off all grenades” • “Turn off all vehicles” • “Turn off all retreats”

21. Behavior Trees • Scalable, modular • Engineer still controls the structure • Figuring out why something happened is easy • Figuring out why something didn’t happen is still fiendishly hard

22. Case 2: Encounters

23. Player Approach Generator 1 Generator 2

24. “Task” ?!

25. condition script Objective Trees task name priority [1] front (if > 2) [1] front (if > 2) [1] generator_1 (if g1) [2] back [2] back Root [1] generator_2 (if g2) search [2] retreat

26. Objective Trees 3 [1] front (if > 2) [1] front (if > 2) [1] generator_1 (if g1) [2] back [2] back 3 Root 3 6 [1] generator_2 (if g2) search 3 [2] retreat

27. Objective Trees 2 [1] front (if > 2) [1] front (if > 2) [1] front (if > 2) [1] generator_1 (if g1) [1] generator_1 (if g1) 2 [2] back [2] back 2 Root 3 5 6 [1] generator_2 (if g2) search 3 5 [2] retreat

28. task name other stuff priority condition is condition satisfied?

30. Objective Results • Takes training • Great prototyping tool • Much cleaner implementation • no messy script • sharing encounters between designers • Very extendable

31. Case 3: Combat Dialogue

32. You idiot! You killed our own guy! Aaargh!!! Ha! They killed their own guy! Oh no, I killed my own guy! I’m sorry!!! Oh no, they killed my friend! Well done, friend! Well done, Master Chief! Damn you, Master Chief!

33. Combat Dialogue <A> kills <B>  “Event” “Oh no, they killed our friend!”  “Vocalization” Match ~100 events  ~320 vocalizations (and find a speaker)

34. Combat Dialogue Implementation: a rule-matching system Event: “Player kills a grunt” killed(a,b) prs_plr_kill enemies(a, b), player(a) friend(a) 0.8 event vocalization relevance conditions speaker conditions

35. Combat Dialogue Implementation: a rule-matching system Event: “Player kills a grunt” killed(a,b) prs_plr_kill enemies(a, b), player(a) friend(a) 0.8 killed(a,b) prs_ally_kill enemies(a, b) friend(a) 0.5 killed(a,b) crs_plr_kill enemies(a, b), player(a) enemy(a) 0.5 killed(a,b) crs_plr_btry friends(a, b), player(a) friend(a) 0.0 Probabilistically choose among top contenders

36. Combat Dialogue Implementation: a rule-matching system Event: “Player kills a grunt” killed(a,b) prs_plr_kill enemies(a, b), player(a) friend(a) 0.8 killed(a,b) prs_ally_kill enemies(a, b) friend(a) 0.5 killed(a,b) crs_plr_kill enemies(a, b), player(a) enemy(a) 0.5 killed(a,b) crs_plr_btry friends(a, b), player(a) friend(a) 0.0 Probabilistically choose among top contenders

40. Combat Dialogue • Use the appropriate tools • Excel has its place • Expected results were extremely “soft” • target was an “experience” • target was negotiated between design and audio • Data-mining was absolutely critical

41. Conclusions

42. Technique Summary • Behavior Tree • Objective Tree • Rule-system Two parts to transparency: • Transparent algorithm • A tools infrastructure for editing and debugging

43. Conclusions • Lots of decision-making going on in a typical AI • Not looking for “smart” architecture, looking for “expressive” architecture • Transparency is an essential component of expressivity • Transarency almost always achieved through simplicity

44. Thank You! Questions? Damián Isla damiani@bungie.com ?!