> For games that want this level of complex interaction between components, entity component systems are the way to go.
Entity component systems are still in a half-baked state, with everyone rolling their own slightly different conceptual model. They're solving a problem, but not solving it well.
One promising direction is getting rid of entities. Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components. Old writeup (not mine): https://github.com/kvark/froggy/wiki/Component-Graph-System
> One promising direction is getting rid of entities.
>
> Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components
You are essentially describing ECS here. In ECS, entities are nothing but a "handle" without any additional data, normally just an integer used to link common components together.
What op links actually describes a different issue than what is in the post.
What I got from the article, instead, is the following:
If entities could be IDs to which components are connected, or containers holding components. Either case has disadvantages.
If entities hold components, then iterating over components means iterating over entities, which slows down all systems. A rare type of component still degrades with adding entities.
If instead components link to entities, and you want multiple components to interact, then these interactions slow down the system because of multiple lookups that need to be done.
Author proposes to use a graph structure between components, getting rid of entities-component duality. Proposes to use pointers which allows calling into any component and process then all required components.
I am not entirely sure if this would solve all problems, but this seems to be the proposal. It seems setting up the graph dynamically would be quite the task, though. For example, I don't immediately see how to guard against cyclic behavior and too many calls into a single component etc.
> Author proposes to use a graph structure between components, getting rid of entities-component duality. Proposes to use pointers which allows calling into any component and process then all required components.
This is far from ideal, and is equivalent to a very naive implementation of ECS. Having the user have to use pointers is not ergonomic, and the random access of secondary components via those pointers destroys the caching benefits of data-oriented design. Having a memory pool don't automatically give optimal cache usage, only if you have very little data.
Most modern ECS frameworks solve the issues you mention by allowing systems that "query" more than one component at a time, not requiring a lookup. For example:
This is supported by lots of mainstream ECS libraries already. It doesn't require lookups inside the System's hot loop, doesn't require random memory access via pointers, and also doesn't require managing/cleaning up those pointers.
The nice thing about keeping Entities as opaque handlers is that a "System Iterator" is able to abstract away the issues mentioned and implementation becomes a mere detail. An ECS library could even use the implementation the GitHub wiki link suggested, since ECS is currently abstract enough to allow it, because of the opaque handlers.
Good to know. Just to be clear, I was not endorsing the article. As mentioned, I have doubts about using a graph structure of pointers for related reasons, most of all because I think handling relational paths will amount to more overhead than any ECS structure.
Nevertheless, I wanted to highlight that the quoted article clearly states that the proposal is not an ECS and is in fact superior to it.
> Good to know. Just to be clear, I was not endorsing the article. As mentioned, I have doubts about using a graph structure of pointers for related reasons, most of all because I think handling relational paths will amount to more overhead than any ECS structure.
I think this is more of a language paradigm problem. Game programming is very much tied up in C++ and C# for historical and performance reasons, ECS is a way to try and graft what is entirely natural in a more value-based language into OOP mechanics and C++/C# type systems.
ECS is so common and easy in lisps that it doesn't even warrant its own name.
Entity component systems are still in a half-baked state, with everyone rolling their own slightly different conceptual model. They're solving a problem, but not solving it well.
One promising direction is getting rid of entities. Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components. Old writeup (not mine): https://github.com/kvark/froggy/wiki/Component-Graph-System