Need opinions: is it worth making component based entity system? [closed]

Question

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.

Questions:

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 ).

Answer 1

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.

Answer 2

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.

Answer 3

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, http://software.intel.com/en-us/articles/how-to-manipulate-data-structure-to-optimize-memory-use-on-32-bit-intel-architecture/

Answer 4

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.

Answer 5

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.