Component based architecture: "pure" or some inheritance?

Question

(I asked a similar question, but it had more questions inside it and I feel it wasn't clear enough, so I'm opening a new one).

Until recently I implemented all my games using an inheritance hierarchy. Those were simple games.

For example:

          Entity
          /    \
      Movable  Static
      /  \        /  \
    Orc  Mage   Tree  Wall

This worked for simple games.

However recently I read about 'entity component systems'. Using this approach, a class doesn't inherit from another class in order to receive functionality. Instead it is composed with it, which allows for more flexible designs.

My question is this:

I know that each component is a class (derived from a common base class).

However, there is one thing I don't understand: In the 'component system' approach, is there one class that all entities are instances of - and the only difference between entities is the components they contain?

For example: There is a class Entity. All entities in the game are instances of this class.

The only differences between them is that they are composed with different Component objects.

For example:

Component aiComponent = new AIComponent();
Component movementComponent = new MovementComponent();
Component physicsComponent = new PhysicsComponent();
Component rangedAttackComponent = new RangedAttackComponent();

Entity orc = new Entity();
orc.addComponent(aiComponent);
orc.addComponent(movementComponent);
orc.addComponent(physicsComponent);

Entity shootingCastle = new Entity();
shootingCastle.addComponent(aiComponent);
shootingCastle.addComponent(rangedAttackComponent);
shootingCastle.addComponent(physicsComponent);

All of this as opposed to my old approach:

Orc orc1 = new Orc();
ShootingCastle castle1 = new ShootingCastle();

As you can see, both orc and shootingCastle are instances of the Entity class. But they are composed with different components.

Is this how 'entity component systems' are supposed to be? No inheritance hierarchy at all? Or is there still a basic inheritance hierarchy, but most of the logic is inside components?

Answer 1

Yes! No! Maybe!

To 1:

No, your understanding of the Component-Entity-Model is not fully correct. If you had a "superclass" than you did something wrong in the first place. You will gain much if you resolve that issue first before chopping up your code into components.

As a basic rule of thumb favor composition over inheritance. This does not necessarily mean you naturally end up at a Entity Component Model. You can extract bits of your code into objects without having one singular base class.

For example you can extract different attack behavior into multiple classes (MagicAttack, MeleeAttack, etc.) that have the common Attack base class. This would then be composed into different entities where needed.

The primary gain of the Entity-Component-Model is ludicrous flexibility at the cost of added complexity. If you add this with a data driven method to generate the entities, you get the ability to create new entities without recompiling. But this only really makes sense when you have non programmers adding logic to the game.

To 2:

You can use inheritance for the process of how to get the components into the entities. It works fine, but defies primary gain of a Entity-Component-Model. This is the case, since the biggest power is gained when entity composition is done outside of the code.

What should you use? That is a hard problem, especially since we do not know what you are trying to apply it on. You can gain much by employing an Entity Component Model, but the added effort may not be worth the effort.

Answer 2

I don't think there is any reason for an entity to be a class in the first place. It could be represented by an index number unique to that entity. Components can then have a member named entity_id with that index. There is no need for any inheritance or classes to represent entities.

Components could and would possibly use classes and inheritance.

Using classes an inheritance is wasteful if it's not done to prevent code duplication or substantially improve your productivity in some manner. I would recommend using only what your project needs when it is needed as it is absolutely disastrous* to use a technique when it is not useful or avoid using one that is needed.

*Detrimental to productivity and if you're an indie with a very limited budget I would consider it to be a disaster.