Variants of Entity Component Systems

Question

I've been reading up on these, and there seem to be two major variations which I'd like to understand better.

1. Entities should contain only data Components, which are processed by systems which contain the logic

2. Entities can contain data and behaviour components

What are the benefits of one over the other? Which scenario would be appropriate for which approach?

What about the other variations, such as message handeling entities/components?

For example, say I want to attach a certain AI behaviour to an entity, approach #2 would let me do that intuitively by simply adding it to the behaviours of the entity. With approach #1, I'm not sure how it would be done, possibly by attaching a data member specifying which AI to use?

Wouldn't the AI processing system turn into one big switch(AI) { case AI_XYZ : AI_XYZ(); ...}, as opposed to simply calling entity.AI(), or sending a message to the entity that tells it to update the AI...?

As with many things, there doesn't seem to be one "right" way to do this, trying them all doesn't seem feasible, I think most of the dis-/advantages wouldn't become apparent without implementing a sizable number of components and/or systems.

Personally, the message handling kind of components look appealing in a game context, simply being able to grab an entity and telling it to react to something, but I have no experience using such a system. I hope this question isn't too vague

Answer 1

Data-only components are good for high performance systems as you can store all the data together and increase cache coherence for that particular system, meaning it should run well on a single core or a separate processor (eg. in consoles like the PS3).

The disadvantages, to me at least, is that it's not easy to code in a style that works well with completely independent systems.

There are many different variations on the component-based theme; rather than repeat myself too much I'll direct you to a past answer of mine here. But in general you have a choice of:

• "Inboard vs. outboard" which was covered above
• static vs. dynamic composition, which gives you either high performance + simpler code versus flexibility and data-driven objects
• data on component vs data on entity, which is a choice of better encapsulation and reusability of components vs simpler collaboration between components on an entity.

Whether the end result requires switch statements or function calls is really about the language rather than the system you use. But generally speaking if your data is handled by systems external to the entity, you wouldn't have the entity look at its own data to decide which AI system to call - each AI system holds a reference to the data of the entities it handles and updates them during its own update() call, and that's the whole point - the external systems handle everything, and the entity in that case is just a loose association of things handled by systems.