Index of /Kuliah2016-2017/KecerdasanBuatanUntukGame
Artificial Intelligence in
Game Design
Representing NPCs as
Finite State Machines
Finite State Machines
• Non-player character in one of several possible
states
– Must be some initial state
• That state controls actions taken by the NPC
• Transitions to other states caused by
internal/external stimuli
Current State
Stimuli
Another State
Stimuli
Another State
Actions in
current state
“Guardbot” Example
start
Chase
Patrol
Move back and
forth in front of door
Energy at 100%
Move towards player
Player visible Energy = Energy - 1
Player not
visible
At door
Energy
below 50%
Return
Move towards door
Energy = Energy - 1
Pac-Man Example
Finite State Machines
• Each state can be reflex agent
Example: “fight” state
Fight
Player swings Raise shield
Player waits Swing sword
Player moves Move towards player
Run
Hit points < 5
Designing FSMs
• What different things does NPC do?
– Types of action taken
• Chase, wander, etc.
– Steps in some process
• Get food from fridge Cook food eat food
– Can include “terminal” state
• Object destroyed and deallocated
Return
Dead
Energy == 0
Move towards door
Energy = Energy - 1
Implementing FSMs
• Can treat each state like a C++/Java class
– Possibly derived from some base “State” class
• Typical methods in class:
– Enter()
Executed once when state entered
Example: entering “Fight” state causes NPC to select weapon
– Exit()
Executed before go to another state
Example: exiting “Guard door” state causes NPC to lock door
Implementing FSMs
• Typical methods in class:
– Update()
Executed by game engine each frame
while NPC in this state
Example: reflex actions taken by NPC in “Fight” state
– int CheckTransitions()
• Executed by game engine each frame
while NPC in this state
• Returns ID of the next state to enter based on
current stimuli (same as current state if no change)
Implementing FSMs
class Chase extends State {
int stateNumber = 1; // Patrol = 0, Return = 2
public:
void Enter() {say(“intruder alert”);}
void Exit() {say(“intruder has escaped”);}
void Update() {
moveTowards(player.getLocation);
if (rand() < 0.3) say (“exterminate”);
energyLevel--;
}
int checkTransitions() {
if (energyLevel 10) return 2;
else return 1;
}
}
Emotional FSMs
• States represent emotions for character
• Actions express emotion
• Stimuli change emotional state
Player HP < 10
Confident
Angry
Player hit > 5 HP
Heavy hit
by me
Player hit
> 10 HP
Frightened
My HP < 10
Emotional FSMs
• Can combine with action states appropriate to emotion
– Looks more realistic if orc displays fear before running
Player HP < 10
Confident
Angry
Player hit > 5 HP
Heavy hit
by me
Player hit
> 10 HP
Frightened
My HP < 5
Running
My HP < 10
Emotional FSMs and Personalities
• Can “tweak” parameters for different NPCs
• Differences must be large enough to be noticeable
Player HP < 5
Confident
Angry
Player hit > 1 HP
Heavy hit
by me
Player hit
> 20 HP
Frightened
My HP < 5
Orc with
anger
management
issues
Emotional FSMs
• NPC must clearly express emotional state
– Facial expression (difficult in low resolution)
– Body language
• Posture, motion, etc.
– Sound (speakers must be on)
• Spoken phrases
• Sounds (growl, etc.)
– Abilities
• Strong emotion might make character less accurate!
Emotional FSMs
Confident
Angry
• Smiles
• Shouts insult
• Stands ground
• Growls
• Frowns
• Faster attack
• Less accurate
Fearful
• Backs away
• Grimaces
• Slower attack
Timeouts in FSMs
• Problem: Abrupt transitions in FSMs
Player < 5 feet away
Player >= 5 feet away
– As player approaches, NPC jumps back and forth
between “Walk around” and “Run” states
Timeouts in FSMs
• Solution: State “timeouts”
– Continue high-emotion states for fixed amount of time
after stimulus gone
• Keep running for time even after at safe distance
• Supported by evidence from biology
Stay in running
state for at least
10 seconds even
in player not close
Timeouts in FSMs
class Run extends State {
int timeout;
void Update() {
Flee(player.getLocation());
if (distance(location, player.getLocation()) < 5)
timeout = 10;
// run for 10 frames even after escape)
}
int CheckTransitions() {
if (timeout > 0) {
timeout--;
return 1; // stay in run state
}
else return 0; // go to walk around state
}
Extended “Guardbot” Example
Player
in front
Turning
Player visible
Patrol
Move back and
forth in front of door
Energy at 100%
Player
to side
Forward
Dodge
Player
visible
Player not
visible
At door
Obstacle
in front
Player within
2 units
Fire
Escaped
Move towards door
Energy = Energy - 1
Energy
below 50%
Return
Move towards door
Energy = Energy - 1
FSM Issues
Problems with Finite State Machines:
• Complexity
– Potentially hundreds of states
• Design difficult
• Debugging impossible
• Duplication
– Many blocks of states similar
• Example: Return state also needs “Turn”, “Move”, and “Dodge”
– Many transitions similar
• Example: Need “low energy” transition from all states in “Chase”
Hierarchical State Machines
Single high-level state contains entire low-level FSM
– Need initial state that high-level passes control to
– Need final states that correspond to transitions from
high-level state
Chase
Player
to side
Start
Turning
Obstacle
not in front
Player
in front
Player
to side
Forward
Player not
within 10
units
Escaped
Dodge
Obstacle
in front
Player within
2 units
Fire
Hierarchical State Machines
• Usually implemented as stack
– Push low-level state on stack when enter
– Pop and move to next state when finished
Start
Turning
Chasing
Chasing
Chasing
Guarding
Door
Guarding
Door
Guarding
Door
Escaped
…
Chasing
Escaped
Guarding
Door
Guarding
Door
Exiting Low-level States
• “Interrupts” may cause exit before task is completed
– Example: Caution flag interrupts passing
• All states on stack may have interrupt conditions
– Check all at each frame
– Better than having same transition for all states
Player
in front
Turning
Chasing
Guarding
Door
Energy
< 50%
Forward
Return
Emergency
recall
Go to HQ
Exiting Low-level States
• Can store current low level state and return if
necessary once exception handled
Build Farm
Clear land
Dam break
Build barn
Plant crops
Return to
appropriate
state when
dam fixed
Fix Dam
Weaknesses of FSMs
• Abrupt transitions between emotional states
– Confident Terrified not a realistic transition
– May need more intermediate states
Confident Worried Terrified
• Multiple next states may be indicated by stimuli
– Must make sure all are mutually exclusive
Within 1 unit
Attack
Chasing
Energy < 10
Return
Game Design
Representing NPCs as
Finite State Machines
Finite State Machines
• Non-player character in one of several possible
states
– Must be some initial state
• That state controls actions taken by the NPC
• Transitions to other states caused by
internal/external stimuli
Current State
Stimuli
Another State
Stimuli
Another State
Actions in
current state
“Guardbot” Example
start
Chase
Patrol
Move back and
forth in front of door
Energy at 100%
Move towards player
Player visible Energy = Energy - 1
Player not
visible
At door
Energy
below 50%
Return
Move towards door
Energy = Energy - 1
Pac-Man Example
Finite State Machines
• Each state can be reflex agent
Example: “fight” state
Fight
Player swings Raise shield
Player waits Swing sword
Player moves Move towards player
Run
Hit points < 5
Designing FSMs
• What different things does NPC do?
– Types of action taken
• Chase, wander, etc.
– Steps in some process
• Get food from fridge Cook food eat food
– Can include “terminal” state
• Object destroyed and deallocated
Return
Dead
Energy == 0
Move towards door
Energy = Energy - 1
Implementing FSMs
• Can treat each state like a C++/Java class
– Possibly derived from some base “State” class
• Typical methods in class:
– Enter()
Executed once when state entered
Example: entering “Fight” state causes NPC to select weapon
– Exit()
Executed before go to another state
Example: exiting “Guard door” state causes NPC to lock door
Implementing FSMs
• Typical methods in class:
– Update()
Executed by game engine each frame
while NPC in this state
Example: reflex actions taken by NPC in “Fight” state
– int CheckTransitions()
• Executed by game engine each frame
while NPC in this state
• Returns ID of the next state to enter based on
current stimuli (same as current state if no change)
Implementing FSMs
class Chase extends State {
int stateNumber = 1; // Patrol = 0, Return = 2
public:
void Enter() {say(“intruder alert”);}
void Exit() {say(“intruder has escaped”);}
void Update() {
moveTowards(player.getLocation);
if (rand() < 0.3) say (“exterminate”);
energyLevel--;
}
int checkTransitions() {
if (energyLevel 10) return 2;
else return 1;
}
}
Emotional FSMs
• States represent emotions for character
• Actions express emotion
• Stimuli change emotional state
Player HP < 10
Confident
Angry
Player hit > 5 HP
Heavy hit
by me
Player hit
> 10 HP
Frightened
My HP < 10
Emotional FSMs
• Can combine with action states appropriate to emotion
– Looks more realistic if orc displays fear before running
Player HP < 10
Confident
Angry
Player hit > 5 HP
Heavy hit
by me
Player hit
> 10 HP
Frightened
My HP < 5
Running
My HP < 10
Emotional FSMs and Personalities
• Can “tweak” parameters for different NPCs
• Differences must be large enough to be noticeable
Player HP < 5
Confident
Angry
Player hit > 1 HP
Heavy hit
by me
Player hit
> 20 HP
Frightened
My HP < 5
Orc with
anger
management
issues
Emotional FSMs
• NPC must clearly express emotional state
– Facial expression (difficult in low resolution)
– Body language
• Posture, motion, etc.
– Sound (speakers must be on)
• Spoken phrases
• Sounds (growl, etc.)
– Abilities
• Strong emotion might make character less accurate!
Emotional FSMs
Confident
Angry
• Smiles
• Shouts insult
• Stands ground
• Growls
• Frowns
• Faster attack
• Less accurate
Fearful
• Backs away
• Grimaces
• Slower attack
Timeouts in FSMs
• Problem: Abrupt transitions in FSMs
Player < 5 feet away
Player >= 5 feet away
– As player approaches, NPC jumps back and forth
between “Walk around” and “Run” states
Timeouts in FSMs
• Solution: State “timeouts”
– Continue high-emotion states for fixed amount of time
after stimulus gone
• Keep running for time even after at safe distance
• Supported by evidence from biology
Stay in running
state for at least
10 seconds even
in player not close
Timeouts in FSMs
class Run extends State {
int timeout;
void Update() {
Flee(player.getLocation());
if (distance(location, player.getLocation()) < 5)
timeout = 10;
// run for 10 frames even after escape)
}
int CheckTransitions() {
if (timeout > 0) {
timeout--;
return 1; // stay in run state
}
else return 0; // go to walk around state
}
Extended “Guardbot” Example
Player
in front
Turning
Player visible
Patrol
Move back and
forth in front of door
Energy at 100%
Player
to side
Forward
Dodge
Player
visible
Player not
visible
At door
Obstacle
in front
Player within
2 units
Fire
Escaped
Move towards door
Energy = Energy - 1
Energy
below 50%
Return
Move towards door
Energy = Energy - 1
FSM Issues
Problems with Finite State Machines:
• Complexity
– Potentially hundreds of states
• Design difficult
• Debugging impossible
• Duplication
– Many blocks of states similar
• Example: Return state also needs “Turn”, “Move”, and “Dodge”
– Many transitions similar
• Example: Need “low energy” transition from all states in “Chase”
Hierarchical State Machines
Single high-level state contains entire low-level FSM
– Need initial state that high-level passes control to
– Need final states that correspond to transitions from
high-level state
Chase
Player
to side
Start
Turning
Obstacle
not in front
Player
in front
Player
to side
Forward
Player not
within 10
units
Escaped
Dodge
Obstacle
in front
Player within
2 units
Fire
Hierarchical State Machines
• Usually implemented as stack
– Push low-level state on stack when enter
– Pop and move to next state when finished
Start
Turning
Chasing
Chasing
Chasing
Guarding
Door
Guarding
Door
Guarding
Door
Escaped
…
Chasing
Escaped
Guarding
Door
Guarding
Door
Exiting Low-level States
• “Interrupts” may cause exit before task is completed
– Example: Caution flag interrupts passing
• All states on stack may have interrupt conditions
– Check all at each frame
– Better than having same transition for all states
Player
in front
Turning
Chasing
Guarding
Door
Energy
< 50%
Forward
Return
Emergency
recall
Go to HQ
Exiting Low-level States
• Can store current low level state and return if
necessary once exception handled
Build Farm
Clear land
Dam break
Build barn
Plant crops
Return to
appropriate
state when
dam fixed
Fix Dam
Weaknesses of FSMs
• Abrupt transitions between emotional states
– Confident Terrified not a realistic transition
– May need more intermediate states
Confident Worried Terrified
• Multiple next states may be indicated by stimuli
– Must make sure all are mutually exclusive
Within 1 unit
Attack
Chasing
Energy < 10
Return