Hi.
For the purposes of this question: Assume a bog-standard ECS system. Entities contain a set of references to components, components are pure data, and systems are (possibly stateful) functions that register/deregister compatible entities on entity creation/deletion/update, and are evaluated in a fixed order at a fixed rate. I say this just so that we know we're all talking about the same thing, as ECS means different things to different people.
Let's assume a game somewhat like the old Atari Berzerk:
The world is an undirected graph of rooms containing the player and monsters. When the player moves into one of the room's doors, the player is moved to the connected room in the graph. Let's assume that monsters and the player can move between rooms, and that each room contains some sort of room-specific physics context for performing collision detection and the like (perhaps one Box2D world per room). One physics context per room because entities in different rooms cannot collide or interact physically in any manner. Let's also assume that the rooms themselves can be created and destroyed at run-time (perhaps procedurally generated to some extent).
So, we probably need:
- a system that's responsible for performing physics updates and collision detection for entities in all rooms, and publishing events when collisions occur
- a system that's responsible for managing the graph of rooms, keeping track of which entities are in which rooms, and publishing events when entities move from room to room
- a system that's responsible for running AI
- a system that renders the room containing whatever is the current camera
Additonally, the camera, player, and all monsterlike entities should probably hold a reference to the room to which they currently belong.
This raises a lot of questions! It seems as though the four systems will end up fairly tightly coupled and need to share long-lived data that is not tied to any particular entity (and therefore won't be in components and is not appropriate to be shared via events).
- The system managing physics needs to know about the current set of rooms, because it has to run physics updates for those rooms that it considers active.
- The AI system needs to know about the graph of rooms when planning paths that span multiple rooms.
- The rendering system needs to know about rooms to some extent in order to render the contents of a room.
- The room system obviously needs to know about rooms because it is the authority for the graph of rooms and is responsible for tracking entities and creating/destroying rooms.
Each of these four aspects are fairly distinct, however. Are the rooms themselves entities? They have a similar lifecycle to entities, multiple systems need to update their own internal state when rooms are created/deleted, and it seems like at least some of the above could be implemented by giving entities that represent rooms a RoomComponent (that may be completely empty) and having systems maintain their own state keyed on the ID of each registered entity that has a RoomComponent.