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?

  • Welcome to Programmers.SE. Your question, as written, doesn't make clear why a "CES" architecture is relevant or important. Is this an academic exercise, or are you being forced to program by buzzword in your employment? – DougM Jul 24 '14 at 19:56
  • It's a self-learning exercise. I'm learning about CES architecture and as an exercise I'm translating the code of a book I'm reading ( that seems to use a Inerithance-based entity system ) to a CES based code ( in C so without using OOP constructs ) – lds Jul 24 '14 at 20:00
  • You will have more answers on the GameDev.SE, frankly speaking (although ECS is very interesting generally and applicable to not just games). – Den Aug 7 '14 at 13:39
  • Thank you for your advice. Should I open a new question there or is there a way to move this one? And should I delete this one if I open it on another stackexchange site? – lds Aug 7 '14 at 16:33

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.