Artificial Intelligence in
Game Design
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
Actions in current state
Another State
Stimuli
Another State
“Guardbot” Example
Patrol
Move back and forth in front of door
Energy at 100%
Chase
Move towards player Energy = Energy - 1 Player visible
Return
Move towards door Energy = Energy - 1 At door
Player not visible
Energy below 50%
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
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
Move towards door Energy = Energy - 1 Energy == 0
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
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
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 <= distance(location(door.getLocation)) || distance(location(door.getLocation)) > 10) return 2; else return 1;
Emotional FSMs
• States represent emotions for character
• Actions express emotion
• Stimuli change emotional state
Confident Angry
Frightened
Player HP < 10
Player hit > 5 HP
My HP < 10 Heavy hit
by me
Emotional FSMs
• Can combine with action states appropriate to emotion
– Looks more realistic if orc displays fear before running
Confident Angry
Frightened
Player HP < 10
Player hit > 5 HP
My HP < 10 Heavy hit
by me
Player hit > 10 HP
My HP < 5
Emotional FSMs and Personalities
• Can “tweak” parameters for different NPCs
• Differences must be large enough to be noticeable
Confident Angry
Frightened
Player HP < 5
Player hit > 1 HP
My HP < 5 Heavy hit
by me
Player hit > 20 HP
Orc with anger
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
Emotional FSMs
Confident
• Smiles
• Shouts insult
• Stands ground
Angry
• Growls
• Frowns
• Faster attack
• Less accurate
Fearful
•
Backs away• Grimaces
Timeouts in FSMs
•
Problem: Abrupt transitions in FSMs
– As player approaches, NPC jumps back and forth
between “Walk around” and “Run” states
Player < 5 feet away
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
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 }
Extended “
Guardbot
” Example
Patrol
Move back and forth in front of door
Energy at 100%
Player visible
Escaped
Move towards door Energy = Energy - 1 At door Player not visible Energy below 50% Return
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
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 Turning Forward Player to side Dodge Obstacle in front Start Player to side Player in front Obstacle not in front
Hierarchical State Machines
•
Usually implemented as stack
– Push low-level state on stack when enter
– Pop and move to next state when finished
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
Turning
Chasing
Guarding Door
Forward
Player in front
Return
Go to HQ
Exiting Low-level States
•
Can store current low level state and return if
necessary once exception handled
Build Farm
Clear land Build barn Plant crops
Dam break
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
Chasing
Attack
Within 1 unit
Return
