Design to handle logic within a state

Question

I am designing a new game and I am trying out the entity-component design where entities are comprised of groups of components holding a bunch of attributes. I also have a stack of 'game states' and 'game systems'. On creation, a new state grabs a bunch of (singleton) system s from a provider of systems. The systems are created at the beginning and maintain a list of entities that are relevant to it by inspecting what components are on the entity. At the moment I have the game logic within a bunch of 'systems', the state simply maintains a list of systems to update/draw.

I realize that the state should really be holding all information relevant to the state. For instance the state should be holding the information on who's turn it is e.t.c. I have it so the system stores all information on the state at the moment and accesses it via the observer pattern. This is turn leads to all sorts of problems as it pretty much couples the system s to the state + it makes the code pretty messy and inefficient.

For instance I have a movement system that is interested in entites with the 'movable' component. The system needs to read from the state who can move at this point. How far they are allowed to move and also controller input to actually do the move. For each of these things I must access the observer methods to modify the state from the system.

The game is turn based at the moment and one of the states is a movement state, it has two systems registered to it, a movement system and a camera system which it updates in turn.

At the moment the movement system gets from the state an entityId representing the 'selected' entity and checks input to see if the player is moving it. If moved the 'location' component is updated on the entity and the system stores the location onto the state via the observer. The camera system then looks up this location on the state and updates the entity with the 'camera' component with this location.

The solution I have at the moment does not seem elegant at all and it is extremely long winded to implement even simple functionality. I am thinking I am doing something fundamentally wrong with the design. I have a few questions that come to mind:

1. Should the state hold the list of entities and do the logic?
   • The systems should maybe only be pure logic calls at this point that hold no variables.
   • How would I handle entities in this situation? I can envisage a state holding loads of entities only to be used for specific segments of the logic.
2. Should the components hold the logic?
3. Should I just make the systems into 'micro-states'? Which is to make them separate instances and have them hold local variables needed for the state.

Answer 1

There are currently no established best practices in component entity system engines design (unlike MVC for example).

My personal biased preferred way is to:

1. Treat entities as nothing more then an IDs that "group" components together.
2. Put data/state into components.
3. Put logic into some components - if they react to messages.
4. Put logic into systems - if something needs to be updated every cycle of the game loop.
5. Make components communicate with each other via messaging.
6. Make systems iterate over all components of a specific type.