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
Looki
ng
smart
Not
lookin
g
stupid
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
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.
~120 of these in
total
(i.e. ~ 7140 possible
transitions)
How do I decide what to do when?
Behavior FSM
Behavior FSM
??
?
Behavior Tree
hide
cover
fight
grenad
e
melee
shoot
root
search
uncove
r
pursue
idle
sleep
Behavior Tree
Three Simplifications:
1. No sibling connections
2. Binary activation functions
3. Prioritized list decisionmaking
Benefits:
•
•
No more n2 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 didn’t happen
is still fiendishly hard
Case 2: Encounters
Player Approach
Generator 1
Generator 2
“Task”
?!
Objective Trees
task name
priority
condition script
[1] generator_1 (if
g1)
[1] front (if >
2)
[2] back
[1] generator_2 (if
search
g2)
[1] front (if >
2)
[2] back
Root
[2] retreat
Objective Trees
[1] generator_1 (if
g1)
[1] front (if >
2)
[2] back
3
[1] generator_2 (if
search
g2)
[1] front (if >
2)
[2] back
3
3
Root
6
3
[2] retreat
Objective Trees
[1] generator_1 (if
g1)
[1] front (if >
2)
[2] back
2
[1] generator_2 (if
search
g2)
[1] front (if >
2)
[2] back
3
5
2
Root
6
3
5
[2] retreat
2
priority
task
name
is condition
satisfied?
condition
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
Ha! They
killed their
own guy!
Well done,
friend!
Well done,
Master Chief!
Aaargh!!!
Oh no,
they
killed my
friend!
Damn you,
Master
Chief!
You idiot!
You killed
our own guy!
Oh no, I
killed my own
guy! I’m
sorry!!!
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 system
Event: “Player kills a grunt”
killed(a,b)
event
prs_plr_k
ill
enemies(a, b),
player(a)
vocalizati
on
relevance conditions
friend(a)
speaker
conditions
0.8
Combat Dialogue
Implementation: a rule-matching system
Event: “Player kills a grunt”
killed(a,b)
killed(a,b)
killed(a,b)
killed(a,b)
prs_plr_k
enemies(a, b),
friend(a)
ill
player(a)
prs_ally_
enemies(a, b)
friend(a)
kill
crs_plr_k
enemies(a, b),
enemy(a)
ill
player(a)
crs_plr_b
friends(a, b), player(a) friend(a)
try
0.8
0.5
0.5
0.0
Probabilistically choose among top contenders
Combat Dialogue
Implementation: a rule-matching system
Event: “Player kills a grunt”
killed(a,b)
killed(a,b)
killed(a,b)
killed(a,b)
prs_plr_k
enemies(a, b),
friend(a)
ill
player(a)
prs_ally_
enemies(a, b)
friend(a)
kill
crs_plr_k
enemies(a, b),
enemy(a)
ill
player(a)
crs_plr_b
friends(a, b), player(a) friend(a)
try
0.8
0.5
0.5
0.0
Probabilistically choose among top contenders
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
[email protected]
om
?!