Entity System with C++

I'm working on a game engine using the Entity System and I have some questions.

How I see Entity System :

Components : A class with attributs, set and get.

1. Sprite
2. Physicbody
3. SpaceShip
4. ...

System : A class with a list of components. (Component logic)

1. EntityManager
2. Renderer
3. Input
4. Camera
5. ...

Entity : Just a empty class with a list of components.

What I've done :

Currently, I've got a program who allow me to do that :

// Create a new entity/
Entity* entity = game.createEntity();

->setPosition( 15, 50 )
->setRotation( 90 )
->setMass( 70 )
->setTexture( "name.png" )


My questions

1. Did the system stock a list of components or a list of entities ?
2. In the case where I stock a list of entities, I need to get the component of this entities on each frame, that's probably heavy isn't it ?
3. Did the system stock a list of components or a list of entities ? In the case where I stock a list of entities, I need to get the component of this entities on each frame, that's probably heavy isn't it ?
• If you wrote the whole thing, then like you said: "the entity has a list of components". My sixth sense tells me someone will undoubtedly submit an answer mentioning data oriented design and talk a lot about how great it is. Essentially, they'll tell you the way you iterate over that list of components and not breaking the cache are the main interests you should focus on. If you're into design patterns, then you might want to check out the Visitor and Decorator patterns. They're similar to what you have.. Sep 7, 2012 at 15:38
• I want to know what "The entity system" is. See I ported the Artemis Entity system from java to C++. Entities in my case don't have lists of components. They simply bind components to themselves with an ID. There are different approaches to create an Entity system. Sep 7, 2012 at 16:45
• I think @Sidar's implementation is the way to go about entity systems. Sep 7, 2012 at 17:10

The system contains a list of components. Components that have dependencies can contain referenced to those dependencies, linked up when the component is added (e.g., physics depends on transform).

Note that as Conner pointed out, the aetup you have is not an "entity system" since you have an Entity class with a list of child components, but more of a general component based design. Somewhat subjective, but I'd lean towards keeping what you have, as there are various excellent uses for having that container game object (being able to list all components on a game object for an editor or serialized, having a place to store game object flags, fast lookup/validation of game object IDs, etc.), and there are plenty of cases where putting logic in a component is both simpler and faster and easier to maintain than trying to move everything into a system (e.g. Behavior components that directly modify what a game object does, rather than simply providing data to systems). Avoid the academically pure entity system and focus on solutions that actually get useful work done the easiest and most efficient way possible.

EDIT: Definitely check out Sean's post and take his advice. I merely meant to answer what a "true" entity system is, but you should definitely do what works for you. As they say, "If your entity system's architecture ain't broke, don't fix it."

Did the system stock a list of components or a list of entities ?

Typically, a system should maintain a list of entities that it is interested in. Also, you mention that your entities maintain a list of components. Ideally (or typically) the components are associated with the entity, but they are not a property of the entity. I.e. maintain a world list of components and their associations.

In the case where I stock a list of entities, I need to get the component of this entities on each frame, that's probably heavy isn't it ?

It's not as slow as you might think. Ideally, you can create a sort of "mapper" that will do fast retrieval of a component.

An implementation of an entity system that I believe adheres to good design is the Artemis Entity System. It's written in Java, but it's also open-source, and well-documented. You can see the source here.

• If he likes he can look at my port for C++. It's probably not perfect but it works. bitbucket.org/stalei/artemiscpp/overview . It could use a lot of improvement though. But the idea for both the original and the port are the same. Sep 7, 2012 at 16:49
• @Sidar is yours a recent port? The author of the original recently rewrote the system and addressed a lot of issues that the first version had. Sep 7, 2012 at 18:08
• It's a month old. Well my first commit was in 2012-06-25. It's almost 1 to 1. But It's probably not C++ kosher. Sep 7, 2012 at 19:11
• I see they have made some new changes. Perhaps I shall add these new changes. Sep 7, 2012 at 19:31

1) Entities. Components should be unique to every entity, and added on creation, before adding the entity to the engine itself, though the engine should be capable of creating entities via some kind of logic system.

2) Do not attempt to copy data from every entity each frame. It is indeed a heavy operation, once you begin dealing with hundreds or thousands of entities. Copying once, allowing continued access is a better approach. My approach was for each system to store proxies of the entity, which stores only components which each system is interested in. (Movement system doesn't care about graphics, physics or logic, only position and velocity, so only needs a proxy with access to those two components).

3) This question seems like the same as 2), so I'll simply expand a little. Each system gets a unique proxy type, which contains the relevant components. You can either have the system implement methods which access and operate on those proxies, or have the proxies themselves implement the logic. I chose the latter. The benefit to this is that with minor modifications, I can have my systems multi-threaded, in that control over component access can be done within each proxy node using a mutex, preventing concurrent access to those components. You may choose to avoid multi-threading (it's certainly not always necessary), but It's still good software design to include abstraction layers in your code.

In this way, Entities only need be added or removed to each system, and only the core engine actually maintains the entities themselves. Storing multiple collections of entities is unnecessary and wasteful.

When an entity is added to each system, it can check if the entity has the components it requires, and if not, the entity is simply ignored. If it does, then a proxy is created, and the relevant components are extracted from the entity and stored in the proxy for later access.