Advertisement Jump to content
GuiTeK

Implementing an Entity Component System in C++

This topic is 1780 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,
 
I've recently discovered the Entity Component System (ECS) and indeed, it seems to be a good design pattern for games.
My game is still pretty small, but there is already a great number of classes. That's why I'm planning on refactoring my whole code to implement an ECS.

I've read several articles and tutorials about ECS, I think I have a good overall comprehension of the pattern, but I have some questions about the implementation.
 
This is how I see it:

  • An abstract class (interface) Component from which all components inherit from.
  • An Entity class. Each instance stores an array of Components*. Components can be added to an entity through the addComponent(Component*) method. This method also attaches the entity to the right systems (e.g. if we add the component Position, the entity is attached to the system MoveSystem).
  • An abstract class System from which all systems inherit from. As described above, each system keeps an array of the entities it should work on. Finally, each system has an update() method to update the entities.

So far, is it correct?

 

Ok, so I wonder how I should implement the systems. Since there is no reason to instanciate them (it would make no sense), the methods should be static, don't you think? Or better, I could use a singleton to make sure there is only one instance of each system.

What do you think?

 

 

Thank you.

Share this post


Link to post
Share on other sites
Advertisement

hi.

You dont really need to put them in a array, I just place them in as a  object and have my entity class have virtual functions like GetComponentMotion and the likes.

I do this so Im not always polling a array to find the component. See if you have 20 components it could be the last one you want and thats 19 time through the array

just to find some thing.

Share this post


Link to post
Share on other sites

Ok thanks for your answers.

 

I have another trouble:

  • My game has maps
  • Maps are made of cells
  • Cells have a position, an ID and a texture.

What should be the components, what should be the entities?

 

I'm pretty sure Map should be an entity, but then:

  • Cell can't be an entity (otherwise I can't use it in my Map entity)
  • Cell can't be a component since it uses other components (Position, ID and Texture).

 

And the same problem goes for a lot of things. Can one use component in other components or did I get it all wrong?

Share this post


Link to post
Share on other sites


Ok, so I wonder how I should implement the systems. Since there is no reason to instanciate them (it would make no sense), the methods should be static, don't you think? Or better, I could use a singleton to make sure there is only one instance of each system.

 

Why does instantiating them make no sense? Surely you have some non-global state that various systems need to do their job.

 

There's really no reason to make the methods static, or to make them singletons. It is a limitation and gains you nothing. Just instantiate the systems you need, and add them to some explicitly-ordered list in your "world manager" (or whatever) so it can go through them and Update them.

 


An Entity class. Each instance stores an array of Components*. Components can be added to an entity through the addComponent(Component*) method. This method also attaches the entity to the right systems (e.g. if we add the component Position, the entity is attached to the system MoveSystem).

 

That's one possible implementation. Another is to store each Component of a particular type in an array of that type, and then the entity exists simply as a mapping to an index in the individual Component arrays. There are many different ways to store them, depending on the sort of cache performance or flexibility you need (for instance, do you allow for more than one component of a particular type on an entity?).

Share this post


Link to post
Share on other sites


And the same problem goes for a lot of things. Can one use component in other components or did I get it all wrong?

 

I don't think I've ever seen an ECS that allows for putting components inside other components. But, there are other ways to create a hierarchy. For instance, if you had a character (an entity) that was holding a sword (another entity), and the sword's position needed to match the character's, you could have a TransformChildren component on the character entity that contains a list of child entity ids. Then you would have a system that operates on all the TransformChildren components and updates the child entities with the correct position. You can create all sorts of hierarchies this way: visual, team, ownership/inventory (e.g. a character has a box entity in his inventory, and that box contains other entities).

 


I have another trouble:
My game has maps
Maps are made of cells
Cells have a position, an ID and a texture.
What should be the components, what should be the entities?
 
I'm pretty sure Map should be an entity, but then:
Cell can't be an entity (otherwise I can't use it in my Map entity)
Cell can't be a component since it uses other components (Position, ID and Texture).
 
So now you can better answer this question. There's no reason that both map and cells both couldn't be entities. Whether or not that actually is a good idea would depend on the nature of your game. As Juliean said, the map maybe doesn't need to be part of the ECS at all (sure, some of the game systems probably need to be able to query the map to find out what kind of cel is at a particular location - but that doesn't mean the map/cells need to be an entity).
 
What do you gain by making cells be entities? Can cells change position and change texture? If so, then that might suggest they should be entities. But if this is just a static map with a huge number of cells laid out in a predictable pattern (e.g. a grid), then I really don't see any reason they should be entities.

Share this post


Link to post
Share on other sites

Thanks for your answers, now I understand a little better the whole thing.

 

Still, I hesitate to implement it in my game for the reasons below:

  • I like my architecture to be clear, not to be a mix of several design patterns which are supposed to be "contestants" (e.g. Map would be a traditional class whereas Character would be an entity). It's quite confusing I think.
  • With the OOP approach, the "skeleton" of the game is well defined by the classes: you read the Character class and you know everything about it. Whereas with the ECS approach, a Character is divided in several files (1 entity, x components and x systems) and you don't know where it all gets together. However, I agree the code is more modulable with an ECS.

So I think for now I'll stick with the "old" OOP approach. I'm sure it can work flawlessly as a lot of games don't use an ECS and they work well.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!