6 ms·
As far as I understand it this is about the ECS equivalent of an INNER JOIN, that is, some variation on "iterate over all entities that possess instances of com
by gmueckl 5y ago
As far as I understand it this is about the ECS equivalent of an INNER JOIN, that is, some variation on "iterate over all entities that possess instances of component A and B". Iterating over single component types in a system is trivial if they are separated into pools by types. When you have a system requiring more than one component, it isn't that easy to do better than iterating over all entities and checking whether they possess each required component. You can decide to maintain back references from components to their entities, but this means that you incur that management overhead pretty much globally. This essay says that doing away with entities altogether and just keeping direct links between your components is better. And it probably is when it comes to handling related components.
However, I believe (without having actually tried it) that this proposal has its own drawbacks. it's harder to thoroughly clean up all components that form a single entity. My suspicion is that it's easier to produce bugs like keeping e.g. a stray collision shape or sound source around while the other parts of an entity are removed. All you need for that to happen is an incomplete graph traversal.
- Kinrany 5y agoI think CGS boils down to smart links between components, which may include SQL-like automatic checks: deleting components that refer to deleted components or components owned by the deleted component.
- gmueckl 5y agoWhen this has to deal with a myriad of different component types individually while staying reasonably performant, this can easily become convoluted. This makes me believe that maintaining it becomes a bit of a error prone chore.