>>106910629
>So is my understanding correct that the entity is not 'decorated' with components, in the sense a class would inherit a specific base class or set of base classes, but rather it just points to an instance of each component?
Entities can't point to anything because they're just IDs.
A "world" class keeps all entities and points to their components for coherency.
The components are stored in a "storage", so for example, we have HealthStorage that stores all Health components.
We can easily represent the component with a dictionary, where the key is the ID and the value is health points, e.g.
{1: 100.0, 2: 84.0, 5: 12.5}
This is easier to reason with, but ideally you're supposed to use a data structure that is tightly packed, so a sized array [100.0, 84.0, 5.2] with perhaps a matching helper array that tells you which entry belongs to which entity id.
The advantage here, as opposed to moving through pointers, is that when you're iterating over all values you can read them very quickly from contigious memory.
A HealthRegenerationSystem does not need to know who owns the Health component, all it has to do is look at one array, transform every value, and it's already done.
Other systems may want to know whether a specific entity has a component, at which point you can just query "world", instead.
>>106911059
>But you often get a systems that only work on single component, and that just makes the split feel redundant.
If you feel that way, then your components are probably not atomized enough.
For example, I can have a component "Plant" and a component "PlantGrowth". I could easily combine them, since all plants are supposed to grow, but this way I can also remove the component entirely when a plant is fully grown to avoid querying over them.
I now also know that a plant without a PlantGrowth component is probably a fully grown plant.
