Organizing an entity system with external component managers?

Question

I'm designing a game engine for a top-down multiplayer 2D shooter game, which I want to be reasonably reuseable for other top-down shooter games. At the moment I'm thinking about how something like an entity system in it should be designed. First I thought about this:

I have a class called EntityManager. It should implement a method called Update and another one called Draw. The reason for me separating Logic and Rendering is because then I can omit the Draw method if running a standalone server.

EntityManager owns a list of objects of type BaseEntity. Each entity owns a list of components such as EntityModel (the drawable representation of an entity), EntityNetworkInterface, and EntityPhysicalBody.

EntityManager also owns a list of component managers like EntityRenderManager, EntityNetworkManager and EntityPhysicsManager. Each component manager keeps references to the entity components. There are various reasons for moving this code out of the entity's own class and do it collectively instead. For example, I'm using an external physics library, Box2D, for the game. In Box2D, you first add the bodies and shapes to a world (owned by the EntityPhysicsManager in this case) and add collision callbacks (which would be dispatched to the entity object itself in my system). Then you run a function which simulates everything in the system. I find it hard to find a better solution to do this than doing it in an external component manager like this.

Entity creation is done like this: EntityManager implements the method RegisterEntity(entityClass, factory) which registers how to create an entity of that class. It also implements the method CreateEntity(entityClass) which would return an object of type BaseEntity.

Now comes my problem: How would the reference to a component be registered to the component managers? I have no idea how I would reference the component managers from a factory/closure.

Answer 1

Systems should store a key value pair of Entity to Component in some sort of Map, Dictionary Object, or Associative Array (depending on language used). Furthermore, when you create your Entity Object, I wouldn't worry about storing it in a manager unless you need to be able to unregister it from any of the Systems. An Entity is a composite of components, but it shouldn't handle any of the component updates. That should be handled by the Systems. Instead treat your Entity as a key that is mapped to all components it contains in the systems, as well as a communication hub for those components to talk to each other.

The great part about Entity-Component-System models is that you can implement the ability to pass messages from one component to the rest of an entity's components quite easily. This allows a component to talk to another component without actually knowing who that component is or how to handle the component it's changing. Instead it passes a message and lets the component change itself (if it exists)

For instance, a Position System would not have much code in it, only keeping track of Entity Objects mapped to their Position Components. But when a position changes, they can send a message to the Entity involved, which in turn is handed off to all of that entity's components. A position changes for what ever reason? Position System sends Entity a message saying that the position changed, and somewhere, that entity's image rendering component gets that message and updates where it'll draw itself next.

Conversely, A Physics System needs to know what all of it's objects are doing; It must be able to see all world objects to test collisions. When a collision happens, it updates the Entity's direction component by sending some sort of "Direction Change Message" to the entity instead of referring to the Entity's component directly. This decouples the manager from needing to know how to change directions by using a message instead of relying on a specific component being there (which it may not be there at all, in which case the message would just fall on deaf ears instead of some error occurring because an expected object was absent).

You'll notice a huge advantage from this since you mentioned you have a Network Interface. A Network Component would listen to all messages coming in that everyone else should know about. It loves the gossip. Then when the Network System updates, the Network components send those messages to other Network Systems on other client machines, which then resend those messages to all the other components to update player positions, etc. Special logic might be needed so that only certain entities can send messages over the network but that's the beauty of the System, you can just have it control that logic by registering the right things to it.

In short:

Entity is a composition of Components that can receive messages. Entity can receive messages, delegating said messages to all of their components to update them. (Position changed Message, Speed Change Direction, etc) It's like a central mailbox that all components can hear from each other instead of talking directly to each other.

Component is a small part of an Entity that stores some state of the entity. These are able to parse certain messages and throw other messages out. For instance, a "Direction Component" would only care about "Direction Change Messages" but not "Position Change Messages". Components update their own state based on messages, and then update other components' states by sending messages from their System.

System manages all components of a certain type, and is responsible for updating said components each frame, as well as dispatching messages from the component's they manage to the Entities that the Components belong to

Systems could be able to update all of their components in parallel, and store all messages as they go. Then when execution of all Systems' update methods complete, you ask each system to dispatch their messages in a specific order. Controls first possibly, followed by Physics, followed by direction, position, rendering, etc. It matters which order they are dispatched in since a Physics Direction Change should Always out weigh a control based direction change.

Hope this helps. It's a hell of a Design Pattern, but it's ridiculously powerful if done right.

Answer 2

I'm using a similar system in my engine and the way I've done it is each Entity contains a list of Components. From the EntityManager, I can query each of the Entities and see which ones contain a given Component. Example:

class Component
{
    private uint ID;
    // etc...
}

class Entity
{
    List<Component> Components;
    // etc...
    public bool Contains(Type type)
    {
        foreach(Component comp in Components)
        {
            if(typeof(comp) == type)
                return true;
        }
        return false;
    }
}

class EntityManager
{
    List<Entity> Entities;
    // etc...
    public List<Entity> GetEntitiesOfType(Type type)
    {
        List<Entity> results = new List<Entity>();
        foreach(Entity entity in Entities)
        {
            if(entity.Contains(type))
                results.Add(entity);
        }
        return results;
    }
}

Obviously this isn't the exact code (you'd actually need a template function to check for different component types, rather than using typeof) but the concept is there. Then you could take those results, reference the component you're looking for, and register it with your factory. This prevents any direct coupling between Components and their managers.

Answer 3

1) Your Factory method should be passed a reference to the EntityManager that called it (I'll use C# as an example):

delegate BaseEntity EntityFactory(EntityManager manager);

2) Have CreateEntity also receive an id (e.g. a string, integer, it's up to you) besides the class/type of the entity, and automatically register the created entity on a Dictionary using that id as a key:

class EntityManager
{
    // Rest of class omitted

    BaseEntity CreateEntity(string id, Type entityClass)
    {
        BaseEntity entity = factories[entityClass](this);
        registry.Add(id, entity);
        return entity;
    }

    Dictionary<Id, BaseEntity> registry;
}

3) Add a Getter to EntityManager to get any entity by ID:

class EntityManager
{
    // Rest of class omitted

    BaseEntity GetEntity(string id)
    {
        return registry[id];
    }
}

And that's all you need to reference any ComponentManager from within your Factory method. For instance:

BaseEntity CreateSomeSortOfEntity(EntityManager manager)
{
    // Create and configure entity
    BaseEntity entity = new BaseEntity();
    RenderComponent renderComponent = new RenderComponent();
    entity.AddComponent(renderComponent);

    // Get a reference to the render manager and register component
    RenderEntityManager renderer = manager.GetEntity("RenderEntityManager") as RenderEntityManager;
    if(renderer != null)
        renderer.Register(renderComponent)

    return entity;
}

Besides Id you can also use some sort of Type property (a custom enum, or just rely on the language's type system), and create a getter that returns all BaseEntities of a certain type.