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

Agenda Halo Decision-making in Three Contexts –Behavior –Encounters –Dialogue Conclusions

Halo

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

Complex Worlds Halo is … 1.a simulation 2.a game

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

AI Goals Game AI must be: Coherent –for the player Transparent –for the player –for the designer Workable –for the engineer

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

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, theres a 75% chance hell dive out of the way Designer knows how to achieve different behavior –Hmm … he reacted to that grenade too quickly … I think Ill 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?!

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.

Case 1: Behavior

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

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)

Behavior FSM

?? ?

Behavior Tree melee shoot grenad e uncove r pursue sleep fight search hide idle root cover root fight shoot

Behavior Tree Three Simplifications: 1.No sibling connections 2.Binary activation functions 3.Prioritized list decision- making Benefits: No more n 2 complexity Scalability

Behavior Tree: Designer Tools 1.Behavior Parameters 2.Styles 3.Inhibition Groups –Turn off all grenades –Turn off all vehicles –Turn off all retreats bool hide_relevance() { if (damage > MAX_DAMAGE) { return true; } else { return false; }

Behavior Trees Scalable, modular Engineer still controls the structure Figuring out why something happened is easy Figuring out why something didnt happen is still fiendishly hard

Case 2: Encounters

Player Approach Generator 1Generator 2

Task ?!

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

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

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

is condition satisfied? task name prioritycondition other stuff

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

Case 3: Combat Dialogue

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

Combat Dialogue kills Event Oh no, they killed our friend! Vocalization Match ~100 events ~320 vocalizations (and find a speaker)

Combat Dialogue Implementation: a rule-matching system Event: Player kills a grunt killed(a,b) prs_plr_k ill enemies(a, b), player(a) friend(a) eventvocalizati on relevance conditionsspeaker conditions 0.8

Combat Dialogue killed(a,b) prs_plr_k ill enemies(a, b), player(a) friend(a) 0.8 Probabilistically choose among top contenders killed(a,b) prs_ally_ kill enemies(a, b)friend(a) 0.5 killed(a,b) crs_plr_k ill enemies(a, b), player(a) enemy(a) 0.5 killed(a,b) crs_plr_b try friends(a, b), player(a)friend(a) 0.0 Implementation: a rule-matching system Event: Player kills a grunt

Combat Dialogue killed(a,b) prs_plr_k ill enemies(a, b), player(a) friend(a) 0.8 Probabilistically choose among top contenders killed(a,b) prs_ally_ kill enemies(a, b)friend(a) 0.5 killed(a,b) crs_plr_k ill enemies(a, b), player(a) enemy(a) 0.5 killed(a,b) crs_plr_b try friends(a, b), player(a)friend(a) 0.0 Implementation: a rule-matching system Event: Player kills a grunt

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

Conclusions

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

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

Thank You! Questions? Damián Isla om ?!