Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been reading about component based entity-system for couple days now and I'm not quite sure if it is worth implementing in my next game. I haven't started making the game yet, but I have bunch of ideas for it. In my imaginations the game will be very similiar to QUBE and Portal (1). 3D puzzler, no enemies, no weapons ( although there may be some "guns", just like portal has portal-gun ). The "basis" of the levels would be constructed from voxel-like data just like in QUBE, but there may be some models aswell ( although, since this is one-man project and I'm no artist, the models will be simple and there wont be many of them ).

I couldn't imagine that I'll ever have more than 20-30 different entities, if even that many.

This is a project that I expect to be working with for a long time, so I'm now trying to properly research all the possible "engine"-architectures before I actually start making the game. I want the game to be flexible and that I could easily implement more features as I progress.


  1. After reading this, do you think I should implement component-based entity system or not? If yes, why?

  2. If I were to implement component-based entity system ( or in a matter of fact, any entity-system at all ), what would "terrain"/"voxel data" be? Would it be entity?

EDIT: I forgot to mention, the other option would be just simple inheritance-based entity-system. The game will be done using C# + XNA ( and WPF for the level-editor ).

share|improve this question

closed as not constructive by Tetrad Jan 20 '12 at 17:37

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

What exactly are the entities you have in mind? Maybe not a full list, but at least give us a few representative examples. – jhocking Jan 20 '12 at 13:27
@jhocking Umm.. Well, the entities I have in my mind are just like button, laser, "hard-light" bridges, aerial faith plates, funnels etc. from Portal 2. Entities I've in mind are like that. Of course, there would be a "model entity" which can hold models, then for example "door entity" which would be constructed from voxels/cubes, but it would be animated somehow when the door is opened. And of course player would be entity. – flai Jan 20 '12 at 14:36
1 This question reads more like "I want to participate in a discussion about the worth of component based entity systems" instead of "I have this problem I need solved.". The answers are going to be just a polling of opinions more than anything else. – Tetrad Jan 20 '12 at 17:37
Feel free to bring this question to the chat, though. – Tetrad Jan 20 '12 at 17:37
up vote 4 down vote accepted

Short answer: probably

Longer answer: A component-based entity system becomes more valuable quickly as the number of distinct entity types increases, so your saying "20-30 different entities" is an important consideration. However it doesn't really take many different entities for component-based to be a big advantage. 20 different entities would certainly benefit a lot from a component-based system, although you also don't think 20 is many entities so I'm curious what exactly you consider "different".

For example, I wouldn't consider an old brass key and an electronic keycard to be different entities, but rather two instances of the same entity with different art assets assigned to the entity. Would you consider those to be different entities?

Another important consideration besides the sheer number of entities is their complexity. A component-based system helps a lot with complex entities, but is just unnecessary overhead for simple entities.

Going back to my keys example, I probably wouldn't bother with a component-based system for keys. I would use a component-based entity system for enemies, but then you said your game won't have enemies. What exactly are the entities you have in mind? Maybe not a full list, but at least give us a few representative examples.

share|improve this answer
I consider "model-entity", which can hold any model that can be rendered, as one entity. I doubt I will in the end even have many "complex" entities in the end. To the last question, I replied to your comment in the OP where you asked the same question. – flai Jan 20 '12 at 14:46
ah then for simple entities like that I wouldn't really recommend a component system. Where a component system is useful is for easily mixing and matching components of various complex entities (eg. a goblin has the model+physics+attacker+walking components, a dragon has the model+physics+attacker+flying components, a turret has the model+attacker components, etc.) – jhocking Jan 20 '12 at 16:17

You mentioned you want the game to be flexible. Do you mean that as only adding new features (better lighting, physics, etc), or also flexibility in terms of game-design? If you also want the game-design part of the development to be flexible, component-based entity systems would be pretty useful.

Unfortunately, I can't give you a competent answer to your second question.

If you choose to implement a CBS, there's two important things you need to ensure:

  1. That components have a way to communicate between themselves very fast (this implies passing the right components to all other components that need them, so they are able to access them directly).

  2. There's a messaging system in place so that components can inform each other when something rare happens, without having to check their state every frame for something that only happens very rarely, like sending a message when the player gets hit.

share|improve this answer
I mean adding new features as in adding different puzzle-elements, such as what funnel, aerial faith plates etc. are in Portal 2. Of course, ease of changing render, physics etc. code is also important. – flai Jan 20 '12 at 14:40
@Jakko What you describe (especially the puzzle elements: laser-shooters, moving platforms, etc) seem like things that would be implemented as entities, so I guess a CBS can be helpful in your case. – Paul Manta Jan 20 '12 at 14:47

If the answer and the benefits arent't obvious to you immediately then it's probably not a good idea. Just make it work with the least amount of abstraction possible and when it's done perhaps some sort of "system" will emerge. But don't start by designing a system and then try to fit a game into it.

share|improve this answer

Yes there are benefits in entity complexity, yada yada yada, but the real benefit of an entity component system comes not from the ease of creating new entities, or the ease of changing entire sub-systems; it comes from the ability to leverage cache-effecient algorithms. With components, for example, your physics code only needs to know about the object's position, velocity, and collision volume. It doesn't care about the model being displayed, or that it happens to be tinted green, and it doesn't have to waste space in the cache for the entire entity. Unfortunately, these benefits aren't nearly as great in C#.

Short answer : Yes, but don't half-ass it. Make your components data-only, and enforce this rigorously. Define behavior in separate modules that update all like components at once, and separate disparate data into separate components as much as possible.

For reference,

share|improve this answer

Based on what you have written I would say that a full on Entity/Component system may be over kill. A question to ask yourself is how deep and tangled do you see your inheritance hierarchy getting? EC Systems are good for cases where entities can take on functionality unexpectedly like if you have an RTS with flying units and ground units, and you decide you want a Mech type unit that can both fight on the ground and fly.

You could always split the difference. Have your game object inheritance hierarchy but if you start having functionality that does not neatly fit within it, factor that functionality out into a component. This is the approach I have been taking and have found it successful.

Anecdotally, I have found more success with having a simple GameObject hierarchy combined with components than having a "pure" EC set up with only a generic GameObject.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.