A state-driven agent is an agent that performs an action based on its current state. The logic can be implemented through the use of a D-FSM that changes state depending on the Agent's "perception" and "stimuli" and perform actions on entering, being in, and exiting a state.

I'm trying to implement this type of design in a Entity-Component-System (ECS) architecture.

My first thought was to implement an "FSM" component containing a current_state and a rulebook, a System that updates the FSM component current_state depending on its rulebook and a System that implements the actions of an Entity ( and modify its components accordingly ) depending on the state of the FSM component.

I'm not sure this is a correct ECS implementation and that it can cleanly represent the enter_state/exit_state -> perform an action behaviour.

So, how should SDA be implemented in a ECS architecture?


2 Answers 2


The approach I have taken in the past was to separate the behavior and the AI aspects into two systems much as you described. On the behavior side, you have a series of predefined aspects that can be chained together into a behavior tree like patrol, attack, threat detection, etc. The behavior tree describes how these behaviors interact, which has priority, etc. The benefit to separating the behavior in this way is you can create a series of several behavior tree patterns per level and simply reuse the pattern across multiple AI entities. This saves on memory budget and makes it much easier to make a change to a behavior tree and have that change reflect across multiple entities with ease.

On the opposite side when I create an AIController, I must give the AIController a behavior tree. The behavior tree is much like a PlayerController's keyboard/mouse. The behavior tree is updated each logical tick and it emits events that the controller is responsible for keeping track of, translating into generalized commands and dispatching the commands to the entity.

As I pointed out, this works in much the same way as keyboard/mouse's input being interpreted by a PlayerController, translated into generalized game commands, and dispatched to the entity.

  • \$\begingroup\$ This is roughly similar to how I've solved the problem I feel it works well. It's important to make your AI controller interface with other aspects of the game entities and engine without making a distinction between player and AI. \$\endgroup\$
    – sydan
    Commented Jan 6, 2015 at 8:52

Assuming that there are only going to be a small number of FSM classes (one for movement, one for AI, etc.) then I would make each state a component (or part of a component). For example, if an entity has Walking, Climbing, Melee and Ranged components, in these components will be encoded the Walking, Climbing, Patrolling, and Attacking states of two different FSMs. Although you will have to have a separate place for each entity to actually keep track of which states it's in, such as an additional AI component, this will make it relatively simple to extend the mixin philosophy to your FSMs.

  • \$\begingroup\$ Could you clarify the meaning of " in these components will be encoded the Walking, Climbing, Patrolling, and Attacking states of two different FSMs"? \$\endgroup\$
    – lds
    Commented Aug 8, 2014 at 7:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .