# Must all AI states be able to react to any event?

FSMs implemented with the State design pattern are a common way to design AI agents. I am familiar with the State design pattern and know how to implement it.

How is this used in games to design AI agents?

Consider a simplified class Monster, representing an AI agent:

class Monster {
State state;
// other fields omitted

public void update(){ // called every game-loop cycle
state.execute(this);
}

public void setState(State state){
this.state = state;
}

// irrelevant stuff omitted
}


There are several State subclasses implementing execute() differently. So far, classic State pattern.

AI agents are subject to environmental effects and other objects communicating with them. For example, an AI agent might tell another AI agent to attack (i.e. agent.attack()). Or a fireball might tell an AI agent to fall down. This means that the agent must have methods such as attack() and fallDown(), or commonly some message receiving mechanism to understand such messages.

1. With an FSM, the current State of the agent should be the one taking care of such method calls - i.e. the agent delegates to the current state upon every event. Is this correct?

2. If correct, how is this done? Are all states obligated by their superclass to implement methods such as attack(), fallDown() etc., so the agent can always delegate to them on almost every event? Or is it done in some other way?

I would probably try and keep everything that changes the agent's attributes with the agent (decreaseHealth) and split the involved behaviour into several FSMs (animation, combat, etc).

IE: the agent has a method getHit that is somehow called when the agent gets hit (by the physics system, other agents, fireballs, etc).

Other FSMs can register to be informed when getHit is called. For example the combat system, which would then change state: if the agent has a shield or protection spell, reduce it's value and change to 'defensive' state, if not call decreaseHealth directly on the agent and go to 'suppressed' state.

Other FSMs would register to be informed when decreaseHealth is called: The sound-system would change from 'talking' to 'screaming' state, the animation-system would change from 'play running animation' to 'play falling down animation' state, etc.

I think this situation would benefit from a Hierarchical State Machine which is the type I use in my games to solve this problem.

A hierarchical state machine (HSM) is a state machine where states are grouped together and have parent states. Therefore grouped states can all react to events collectively to produce behavior that is general for a specific set of states. For example I'm currently working on a generic ground based movement script for my game, the 'Legs' component supplies the states:

• grounded
• standing
• walking
• running
• airborne
• jumping
• falling

etc...

You can see that some states are substates of others, in this way if the actor entity receives an event such as 'jump' and it is in the ground state (which is to say that it is in any of the states: standing, walking or running) it will transition to the jumping state. A similar event could occur for something only applicable to the airborne state.