1. 1 Game AI Finite State Machine

2. 2 Finite State Machine (FSM) is the Most Commonly used Game AI Technology Today Finite State Machine (FSM) is the Most Commonly used Game AI Technology Today –Simple –Efficient –Easily extensible –Powerful enough to handle a wide variety of situations Theory (Simplified) Theory (Simplified) –A set states, S –An input vocabulary, I –Transition function, T(s, i) »Map a state and an input to another state Introduction (1/2)

3. 3 Practical Use Practical Use –State »Behavior –Transition »Across states »Conditions –It’s all about driving behavior Flow-chart Diagram Flow-chart Diagram –UML State Chart »Arrow Transition Transition »Rectangle State State Introduction (2/2)

4. 4 An Example of FSM As a Diagram Gather Treasure Flee Fight Monster in sight No monster Monster dead Cornered

5. 5 Character AI Character AI “Decision-Action” Model “Decision-Action” Model Behavior Behavior –Mental State Transition Transition –Players’ action –The other characters’ actions –Some features in the game world FSM for Games

6. 6 Code-based FSM Code-based FSM –Simple Code One Up »Straightforward »Most common –Macro-assisted FSM Language Data-Driven FSM Data-Driven FSM –FSM Script Language Implement FSM

7. 7 Coding an FSM – Code Example 1 void RunLogic(int *state) { switch(*state) switch(*state) { case 0: // Wander case 0: // Wander Wander(); Wander(); if (SeeEnemy()) *state = 1; if (SeeEnemy()) *state = 1; if (Dead()) *state = 2; if (Dead()) *state = 2; break; break; case 1: // Attack case 1: // Attack Attack(); Attack(); *state = 0; *state = 0; if (Dead()) *state = 2; if (Dead()) *state = 2; break; break; case 2: // Dead case 2: // Dead SlowlyRot(); SlowlyRot(); break; break; }}

8. 8 Coding an FSM – Code Example 2 void RunLogic(FSM *fsm) { // Do action based on the state and determine next input // Do action based on the state and determine next input input = 0; input = 0; switch(fsm->GetStateID()) switch(fsm->GetStateID()) { case 0: // Wander case 0: // Wander Wander(); Wander(); if (SeeEnemy()) input = SEE_ENEMY; if (SeeEnemy()) input = SEE_ENEMY; if (Dead()) input = DEAD; if (Dead()) input = DEAD; break; break; case 1: // Attack case 1: // Attack Attack(); Attack(); input = WANDER; input = WANDER; if (Dead()) input = DEAD; if (Dead()) input = DEAD; break; break; case 2: // Dead case 2: // Dead SlowlyRot(); SlowlyRot(); break; break; } // DO state transition based on computed input // DO state transition based on computed input fsm->StateTransition(input); fsm->StateTransition(input);}

9. 9 Mealy & Moore Machines Mealy Machine Mealy Machine –A Mealy machine is an FSM whose actions are performed on transitions Moore Machine Moore Machine –A Moore machine’s actions reside in states –More intuitive for game developers

10. 10 FSM Language Use Macros Coding a State Machine Directly Causes Lack of Structure Coding a State Machine Directly Causes Lack of Structure –Going complex when FSM at their largest Use Macro Use Macro Beneficial Properties Beneficial Properties –Structure –Readability –Debugging Simplicity Simplicity

11. 11 FSM Language Use Macros – An Example #define BeginStateMachine … #define State(a) … … bool MyStateMachine::States(StateMachineEvent event, int state) int state){ BeginStateMachine BeginStateMachine State(0) State(0) OnUpdate OnUpdate Wander(); Wander(); if (SeeEnemy()) SetState(1); if (SeeEnemy()) SetState(1); if (Dead()) SetState(2); if (Dead()) SetState(2); State(1) State(1) OnUpdate OnUpdate Attack(); Attack(); SetState(0); SetState(0); if (Dead()) SetState(2); if (Dead()) SetState(2); State(2); State(2); OnUpdate OnUpdate RotSlowly(); RotSlowly(); EndStateMachine EndStateMachine}

12. 12 Data-Driven FSM Scripting Language Scripting Language –Text-based script file –Transformed into »C++ Integrated into source code Integrated into source code »Bytecode Interpreted by the game Interpreted by the game Authoring Authoring –Compiler –AI editing tool Game Game –FSM script engine –FSM interface

13. 13 Data-Driven FSM Diagram Authoring FSMs bytecode Compiler AI Editing Tool Condition & Action Vocabulary Games FSM Script Engine FSM Interface Condition & Action Code Game Engine Artist, Designers, & Developers

14. 14 AI Editing Tool for FSM Pure Text Pure Text –Syntax ? Visual Graph with Text Visual Graph with Text Used by Designers, Artists, or Developers Used by Designers, Artists, or Developers –Non-programmers Conditions & Action Vocabulary Conditions & Action Vocabulary –SeeEnemy –CloseToEnemy –Attack –…–…–…–…

15. 15 FSM Interface Facilitating the Binding between Vocabulary and Game World Facilitating the Binding between Vocabulary and Game World Glue Layer that Implements the Condition & Action Vocabulary in the Game World Glue Layer that Implements the Condition & Action Vocabulary in the Game World Native Conditions Native Conditions –SeeEnemy(), CloseToEnemy() Action Library Action Library –Attack(…)

16. 16 FSM Script Language Benefits Accelerated Productivity Accelerated Productivity Contributions from Artists & Designers Contributions from Artists & Designers Ease of Use Ease of Use Extensibility Extensibility

17. 17 Processing Models for FSMs Processing the FSMs Processing the FSMs –Evaluate the transition conditions for current state –Perform any associated actions When and How ? When and How ? – Depend on the exact need of games Three Common FSM Processing Models Three Common FSM Processing Models –Polling –Event-driven –Multithread

18. 18 Polling Processing Model Processing Each FSM at Regular Time Intervals Processing Each FSM at Regular Time Intervals –Tied to game frame rate –Or some desired FSM update frequency –Limit one state transition in a cycle –Give a FSM a time-bound Pros Pros –Straightforward –Easy to implement –Easy to debug Cons Cons –Inefficiency »Some transition are not necessary to check every time Careful Design of Your FSM Careful Design of Your FSM

19. 19 Event-driven Processing Model Designed to Prevent from Wasted FSM Processing Designed to Prevent from Wasted FSM Processing An FSM is Only Processed When It’s relevant An FSM is Only Processed When It’s relevant Implementation Implementation –A Publish-subscribe messaging system (Observer pattern) –Allows the engine to send events to individual FSMs –An FSM subscribes only to the events that have the potential to change the current state –When an event is generated, the FSMs subscribed to that events are all processed “As-needed” Approach “As-needed” Approach –Should be much more efficient than polling ? Tricky Balance for Fine-grained or Coarse-grained Events Tricky Balance for Fine-grained or Coarse-grained Events

20. 20 Multithread Processing Model Both Polling & Event-Driven are Serially Processed Both Polling & Event-Driven are Serially Processed Multithread Processing Model Multithread Processing Model –Each FSM is assigned to its own thread for processing –Game engine is running in another separate thread –All FSM processing is effectively concurrent and continuous –Communication between threads must be thread-safe »Using standard locking & synchronization mechanisms Pros Pros –FSM as an autonomous agent who can constantly and independently examine and react to his environment Cons Cons –Overhead when many simultaneous characters active –Multithreaded programming is difficult

21. 21 Interfacing with Game Engine (1/2) FSMs Encapsulate Complex Behavior Logic FSMs Encapsulate Complex Behavior Logic –Decision, condition, action, … Game Engine Does Corresponding Game Engine Does Corresponding –Character animation, movements, sounds, … The Interface : The Interface : –Code each action as a function »Need recompile if any code is changed »ie., FleeWolf() –Callbacks »Function pointers »ie., actionFunction[fleeWolf]() –Container method »actionFunctions->FleeWolf(); »DLL

22. 22 Interfacing with Game Engine (2/2) Take TheFly3D as Example: Take TheFly3D as Example: class AArmyUnit : public FnCharacter { … void DoAttack(…); } AArmyUnit *army; army->Object(…); army->MoveForward(dist, …); … army->DoAttack(…);

23. 23 FSM Efficiency & Optimization Two Categories : Two Categories : –Time spent –Computational cost Scheduled Processing Scheduled Processing –Priority for each FSM –Different update frequency Load Balancing Scheme Load Balancing Scheme –Collecting statistics of past performance & extrapolating Time-bound for Each FSM Time-bound for Each FSM Do careful design Do careful design –At the design level Level-of-detail FSMs Level-of-detail FSMs

24. 24 Level-Of-Detail FSMs Simplify the FSM When the Player Won’t Notice the Differences Simplify the FSM When the Player Won’t Notice the Differences –Outside the player’s perceptual range –Just like the LOD technique used in 3D game engine Three design Keys : Three design Keys : –Decide how many LOD levels »How much development time available ? »The approximation extent –LOD selection policy »The distance between the NPC with the player ? »If the NPC can “see” the player ? »Be careful the problem of “visible discontinuous behavior” –What kind of approximations »Cheaper and less accurate solution

25. 25 Extending the Basic FSM Extending States Extending States –Begin-end block Stacks & FSMs Stacks & FSMs –Stack-based “history” of FSMs »“Remember” the sequence of states passed through »“Retrace” its steps at will –Hierarchical FSM Polymorphic FSMs Polymorphic FSMs Fuzzy State Machine Fuzzy State Machine –Combined with fuzzy logic BeginDoAction(); DoActions(); EndDoAction();

26. 26 A Hierarchical FSM Example Gather Treasure Flee Fight Monster in sight No monster Monster dead Cornered Find Treasure Go To Treasure Take Treasure Find Treasure Gather Treasure Live Active FSM Stack

27. 27 Another Hierarchical FSM Example Patrol Investigate Attack Done Noise Saw Enemy Done Go to A Look for Intruders Go to A Look for Intruders Patrol Report Noise Go Over To Noise Look for Intruders False Alerm! Investigate noise