Transparent Decision-Making and AI Design

Transparent Decision-Making and

AI DesignDamian 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, 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?!”

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 FSM

???

Behavior Tree

melee

shoot

grenade

uncover

pursue

sleep

fight

search

hide

idle

root

cover

root

fight

shoot

Behavior Tree

Three Simplifications:1.No sibling connections2.Binary activation functions3.Prioritized list decision-

making

Benefits:• No more n2 complexity• Scalability

Behavior Tree: Designer Tools

1. Behavior Parameters

2. Styles3. 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 didn’t

happen is still fiendishly hard

Case 2: Encounters

Player Approach

Generator 1 Generator 2

“Task”

?!

Objective Trees

search

[1] generator_1 (if g1)


Root

[2] retreat

priority

task namecondition

script

[1] front (if > 2)[2] back


Objective Trees

search



Root

[2] retreat


[1] front (if > 2)[2] back6

3

3

3

3

Objective Trees

search



Root

[2] retreat


[1] front (if > 2)[2] back6

2

3

2

3

[1] front (if > 2)

2[1] generator_1 (if g1)

5

5

is condition satisfied?

task namepriorit

yconditio

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

I’m sorry!!!

Damn you,

Master Chief!

Aaargh!!!

Combat Dialogue

<A> kills <B> “Event”“Oh no, they killed our friend!”

“Vocalization”

Match ~100 events ~320 vocalizations(and find a speaker)

Combat Dialogue

Implementation: a rule-matching systemEvent: “Player kills a grunt”

killed(a,b)prs_plr_

killenemies(a, b),

player(a)friend(a)

event vocalization

relevance conditions

speaker condition

s

0.8

Combat Dialogue

killed(a,b)prs_plr_

killenemies(a, b),

player(a)friend(a) 0.8

Probabilistically choose among top contenders

killed(a,b)prs_ally

_killenemies(a, b) friend(a) 0.5

killed(a,b)crs_plr_

killenemies(a, b),

player(a)enemy(a

)0.5

killed(a,b)crs_plr_

btryfriends(a, b),



Combat Dialogue

killed(a,b)prs_plr_

killenemies(a, b),


Probabilistically choose among top contenders

killed(a,b)prs_ally

_killenemies(a, b) friend(a) 0.5

killed(a,b)crs_plr_

killenemies(a, b),

player(a)enemy(a

)0.5

killed(a,b)crs_plr_

btryfriends(a, b),



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 algorithm2.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 [email protected]

om

?!

Documents

Transparent Decision-Making and AI Design