Finite State Machines

Finite State Machines

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

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

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

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

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

Pac Man Ghost FSM

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

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; };

Finite State Machine Design Use some global constants to define the states (which are in integers) #define kroam 1 #define kevade 2 #define kattack 3 #define khide 4

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(); int checkhealth();

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()) else state=kattack; state=kroam;

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()) else state=kattack; state=kroam;

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?

Example: Ant FSM

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?

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.

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?

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

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?

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

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

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)

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

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

Weaknesses of FSMs 1. Rigid modeling of behaviors Each character can only have one state at a time straightforward but limited 2. Complex transition conditions can affect efficiency if many conditions need to be checked 3. 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

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