2
\$\begingroup\$

Currently looking and reading about entity component systems, and just wanted to ask about who 'owns' or where the components are registered.

I would have thought that each entity has a collection of all the components associated with that entity. Then from a scene/level ypu could iterate through each entity associated with the scene and then each component for updates/renders/input handling etc.

A couple of examples I've been reading however seem to register the components against the scene, grouped by the entity type. So in this case, registering a component on the entity actually passes the component to the scene, where its stored against the component type and entity id.

Is this a performance thing? As scene would then just be able to iterate over all components (even though its a double loop, 1 over each type and then over each component of type). Or is it that the scene can easily load all components of a given type?

\$\endgroup\$

1 Answer 1

8
\$\begingroup\$

In an actual ECS, entities are just IDs, they don't own the components. Components are usually registered into a container that represents the scene/world the game is currently in.

The reason is indeed performance. When you have all the components in the same place and organize them back-to-back in memory, you can reduce CPU cache misses. It sounds like over-optimization, but it actually amounts to a lot of performance saves since you will be applying it over your entire codebase. This is basically AOS (array of structs) vs SOA (struct of arrays) discussion, just with different terms.

In the component architectures of some popular engines such as Unity (with MonoBehaviours, not DOTS), components are owned by the entities. People often mislabel these architectures as ECS, but they are not. In my opinion, it is better to call them component architectures instead of ECS for clarity.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ The architecture style used in Unity is usually called "Composition over Inheritance". But that wording is specifically to differentiate it over OOP architectures where every kind of entity is exactly one class and shared logic is implemented by having two classes inherit from a base class containing the shared functionality. Perhaps a good name that stands on its own and contrasts with ECS would be to call it "Behavior Composition". Or perhaps "Entity - Behavior". \$\endgroup\$
    – Philipp
    Commented Aug 17, 2023 at 10:09
  • 4
    \$\begingroup\$ It may be worth mentioning the Archetype pattern here (where groups of entities with the same set of components have their data stored together, separate from entities with different component mixes, for fast iteration by systems that use more than one component type without random holes in the arrays forcing branching). Neither flat SoA arrays nor archetypes are required for something to be an ECS. But ECS does lend itself to this kind of Data Oriented Design as an optimization for throughput for large numbers of entities, so it's common to use them together. \$\endgroup\$
    – DMGregory
    Commented Aug 17, 2023 at 11:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .