170 likes | 294 Vues
This document explores the application of Finite State Machines (FSMs) in game AI, emphasizing the design of intelligent behaviors for non-player characters (NPCs). It outlines how FSMs can define various states and transitions that contribute to realistic decision-making, enhancing gameplay experience. The theoretical and practical aspects of FSMs are discussed, including their advantages, like ease of understanding and implementation, as well as challenges such as scalability. The document also presents possible extensions to FSMs, including hierarchical and probabilistic models for richer NPC behaviors.
E N D
Artificial Intelligence for GamesFinite State Machines Patrick Olivier p.l.olivier@ncl.ac.uk
“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
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 a 1 2 f b e 5 c g 3 4 d Finite state machines: theory
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 Monster In Sight Gather Treasure Flee No Monster Fight Monster Dead Cornered Finite state machines: practice
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) Attack E,~D ~E E D E ~S Inspect Patrol S E D ~E Spawn D S D Finite state machines: example
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 Attack Wander ~E Chase E Pick-up Powerup ~S S Start Spawn D Turn Right ~E Go-through Door
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
Approach Attack Slide & Shoot .3 .3 .3 .1 Start .4 .2 Aim & Shoot Jump & Shoot .4 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