Implementing state-driven agents within an Entity-Component-System approach

by Animamorta   Last Updated May 26, 2018 15:05 PM

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?



Answers 1


It depends on what the actual entity is and what the actual thing is you're modeling as a state machine.

In an ideal world, the state machine would live wholly contained within the component. The component would expose some interface, which the end user could work with and not know/care that the internals are actually moving a state machine around. This is good when the thing you're modeling is a "thing" that exists as part of the larger entity and when the state machine is relatively static - known inputs, with known outputs and known state transitions.

But sometimes, the entity itself acts as a sort of aggregation mechanism for the state machine. This happens more frequently when the state machine is dynamic. The inputs/outputs/state transitions can change depending on what components live in the entity. In this case, you may want to separate the state machine based on what bits you want to change and where the dependencies lie.

The big thing to focus on here is the spirit of the Single Responsibility Principle: "a class or module should have one and only one reason to change". Where you draw the lines to make that true depends on how you expect your system to change over time.

Telastyn
Telastyn
July 24, 2014 17:43 PM

Related Questions




State Design Pattern

Updated July 05, 2016 08:02 AM