artificial intelligence for games finite state machines patrick olivier [email protected]
TRANSCRIPT
“Intelligent” Behaviours
• Restrict “behaviour” to “intelligent behaviours”• For example:
– trajectory of a car is not “intelligent” – decision to fight and what to fight – decision to flee and what to flee from
• Complex behaviours implement more intelligent opponents– define a kind a “personality” for NPCs or opponents– formalising behaviours makes gameplay explicit
Finite state machines: theory• Simple theoretical
construct:– Set of states (S)– Input vocabulary (I)– Transition function T(s,i)
• A way of denoting how an object can change its state over time
1 2
3 4
5b
a
c
d
e
f
g
Finite state machines: practice
• Character AI modeled as a sequence of mental states
• World events can force a state change
• Easy to grasp, even for non-programmers
• Input to the FSM continues as long as the game continues
Gather Treasure
Flee
Fight
Monster In Sight
No Monster
Monster Dead Cornered
Finite state machines: example• States
– Atttack– Inspect– Spawn– Patrol
• Events– E: see an enemy– S: hear a sound– D: die
• Action performed– On each transition– On each update in some states
(e.g. attack)
SpawnD
Inspect
~E
D
AttackE,~D~E
E
E
D
SPatrol
E
~S
S
D
Pac-man: Blinky (the red ghost)
FSMs: advantages & disadvantages
• Advantages:– Easy to understand– Easy to implement– Flexible: suitable for a range of problems
• Disadvantages:– Scalability: can be cumbersome– State oscillation
FSMs: implementation issues• Polling
– Simple and easy to debug– Inefficient since FSM’s are always evaluated
• Event Driven Model– FSM registers which events it is interested in– Requires Observer model in engine
• Multithreaded– Each FSM assigned its own thread– Requires thread-safe communication– Conceptually elegant– Difficult to debug
Class exercise• 10 minutes exercise• work in pairs or threes• pick a game scenario• agree on percepts for the scenario• each develop an FSM for a different NPCs• aim for interesting interactions:
– between player and NPCs– between NPCs
• hand in a “final” sheet (with names on it)
Extensions: Hierarchical FSMs
• expand a state into its own sub-FSM• some events move you around the same level in
the hierarchy, some move you up a level• when entering a state, choose a sub-state:
– set a default, and always go to that– random choice– depends on the nature of the behaviour
Extensions: Hierarchical FSMs
StartTurn Right
Go-throughDoor
Pick-upPowerup
Wander ~E
E~S
SD
~E
Attack
Chase
Spawn
Extensions: stack-based FSMs• Gives the AI a (limited) form
of ‘memory’ • Switch states, then return to
a previous state• Permits temporary
interruption• More realistic behaviour• Not all states stack-able• Replacement behaviours
Extensions: inertial FSMs
• Need to address the oscillation problem
• For example – basketball:– LOS=FALSE stand-state– LOS=TRUE basket-drive-state
• Introduce inertia to dampen state changes
• State inertia (e.g. minimum running times)
• Perceptual inertia (e.g. multiple firings)
Other extensions of FSMs…• Inter-character concurrent FSM
– Coordinating multiple characters
• Intra-character concurrent FSM– Coordinating multiple behaviours (in one NPC)
• Levels of detail (LODs)– Analogous to LOD in graphics– e.g. crowd simulation
• Proximal NPCs use fully elaborated FSM
• Distal characters use fixed paths or worse
Nondeterministic FSMs
• Probabilistic FSMs– multiple transitions for same
event– each transition has
probability that it will be taken– probabilistically choose a
transition at run-time
Attack
Start
Approach
Jump &Shoot
Aim& Shoot
Slide& Shoot
.1
.3
.4
.3
.3
.4.2
Questions?