Finite State Machines

1. Finite State Machines

2. Finite State Machines (FSMs) • An abstract machine that can exist in one of several different and predefined states • Defines a set of conditions that determine when the state should change • State defines the behaviors to be executed

3. Finite State Machines (FSMs) • Long history of involvement in game AI • Ghosts in Pac Man are FSMs • Ghosts can roam freely, chase player, evade player • The transition between these behaviors are determined by the player’s actions • Even today, FSMs are still very commonly used • Easy to understand, implement, debug • Lightweight and efficient

4. Basic State Machine Model • A generic FSM diagram: • ‘S’ nodes are states, ‘t’ arrows are transitions • Each FSM typically models a set of behaviors for a character or group of characters

5. Basic State Machine Model • 4 possible states {Si, S1, S2, S3} • Transition functions {t1,t2, t3,t4, t5} • Initial state  Si , remains in this state until t1 provides a stimulus to switch to S1

6. ‘Pac Man Ghost’ FSM • 3 possible states: Roam, Chase, Evade • Transitions include conditions for remaining in a same state

7. ‘Pac Man Ghost’ FSM

8. Finite State Machine Design • Previous sample implementation may not be the most efficient design • Efficient design  Encourage re-usability • Two main components in design • Data structures used to store the data associated with the game AI entity • Functions for operating transition between states

9. Finite State Machine Design • Structures and Classes • Typical to store all game AI-related data in a structure or class • You can also store the current AI state (for FSM) class AIEntity { public: int type; int state; int row; int column; int health; int strength; int intelligence; int magic; };

10. Finite State Machine Design • Use some global constants to define the states (which are in integers) #define kRoam 1 #define kEvade 2 #define kAttack3 #define kHide 4

11. Finite State Machine Design • Transition functions • Add additional functions that determine how the AI entity should behave class AIEntity { public: int type; int state; int row; int column; int health; int strength; int intelligence; int magic; Boolean playerInRange(); intcheckHealth(); };

12. Finite State Machine Design • In your main game loop, constant checking should be done to determine when to change states if ((checkHealth()<kPoorHealth) && (playerInRange()==false)) state=kHide; else if (checkHealth()<kPoorHealth) state=kEvade; else if (playerInRange()) state=kAttack; else state=kRoam;

13. Finite State Machine Design • How would the original FSM diagram looked like for this example behavior? if ((checkHealth()<kPoorHealth) && (playerInRange()==false)) state=kHide; else if (checkHealth()<kPoorHealth) state=kEvade; else if (playerInRange()) state=kAttack; else state=kRoam;

14. Example: Ant FSM • Description of Ant AI • First, the ants will move randomly in their environment in an attempt to locate a piece of food. Once an ant finds a piece of food, it will return to its home position. When it arrives home, it will drop its food and then start a new search for water rather than food. The thirsty ants will roam randomly in search of water. Once an ant finds water, it will resume its search for more food. • Returning food to the home position also will result in a new ant emerging from the home position. The ant population will continue to grow so long as more food is returned to the home position. Of course, the ants will encounter obstacles along the way. In addition to the randomly placed food will be randomly placed poison. Naturally, the poison has a fatal effect on the ants. • Can you summarize the behavior in an FSM?

15. Example: Ant FSM

16. AI Design-to-Implementation • Storyboarding  Character Design  AI Design (FSM)  AI Implementation • FSMs can model behaviors very easily, but much more work needs to be done earlier for character design • Can we use one generic FSM to model the behavior of a few types of AI characters?

17. Re-using one generic FSM? • No, if your AI characters require different set of states and transitions • Yes, if they have the same set of states and transitions, but different condition variables • E.g. A stronger and matured ant and a junior ant might have the same behaviors (states, transitions) but different requirements for finding food/water, or different resistance levels towards poison.

18. Limitations of a single FSM • A single FSM can have limitations in expressing some behaviors. • A common source of difficulty is “alarm behaviors”, or behaviors that require the AI character to do something urgently at any given state, and to resume back the state later • Can you think of a scenario where this might happen?

19. Example: Cleaning Robot AI • Single FSM operates with no problems • However, the robot can run low on power and requires recharging • Alarm mechanism: Interrupting the normal behavior to respond to something else important

20. Example: Cleaning Robot AI • Adding “Get Power” state to accommodate the alarm mechanism is not difficult  but number of states increase about x2 • What if we have a “Hide” alarm that is another alarm behavior?

21. Example: Cleaning Robot AI • So, rather than combining all the logic into a single FSM, we can separate into several FSMs, arranged in a hierarchy • Higher levels of hierarchy can respond to alarm behaviors

22. Hierarchical State Machine • Higher level: Operates the alarm behavior (to get power) • Lower level (within the Clean Up mother state): Operates the cleaning up behavior

23. Hierarchical State Machine • H* state: “History state” that indicates which sub-state (in lower level) should be entered (initially) or resumed (if just returned from the higher level)

24. Hierarchical State Machine • It is possible to implement both FSMs separately, but a lot of switching between the two is required  implementation inefficiency • Nested hierarchy: We are in more than one state at a time (on different levels), just keep track of multiple levels of states

25. Cross Hierarchical Transition • If the robot has no objects to collect (of found nothing useful), makes sense to go back to charging bay rather than wasting power • Transition from lower level state to a higher level state – Lower level FSM is reset, with no history record

26. Weaknesses of FSMs • Rigid modeling of behaviors • Each character can only have one state at a time – straightforward but limited • Complex transition conditions can affect efficiency • …if many conditions need to be checked • Behaviors are deterministic • Designer pre-determines the actions and behaviors of the character, unlikely for it to respond out side what it was designed to

27. Addressing them… • Rigid modeling of behaviors • Modeling multiple states in a nested hierarchy might help to construct more complex behaviors • Complex transition conditions can affect efficiency • Use decision trees in the transitions • Behaviors are deterministic • Apply fuzzy logic to the transitions