Component Graph System (2017)
github.com
github.com
Call me out if I'm wrong, but I don't know of any high-performance ECS framework that actually does this. Most frameworks maintain sorted collections of components with no gaps. For instance, if I want all entries with X,Y,Z, then I iterate those three arrays starting at their X,Y, Z section, and the order of components in that section of the arrays matches exactly (meaning we can just iterate through them all).
This library seems like a really neat concept, but I think the ECS concepts that it's critiquing aren't actually used in many production-quality frameworks. Call me out if I'm just missing context here.
Also, I'd love more details on how CGS is able to always iterate on flat vectors with no gaps. The only way I've seen to accomplish this is to do a decent amount of work curating components into multiple orderings, so if CGS is avoiding that, I am equal parts skeptical and very very excited (since that would be super useful!)
EnTT is a header-only, tiny and easy to use library for game programming and much more written in modern C++. Among others, it's used in Minecraft by Mojang, ...
The fact that even this caliber of implementation has to handle multi-component cases by doing super careful curation of components is what makes me skeptical that CGS would be able to solve this situation more efficiently/easily. I would be very happy to be proven wrong here, though.
commonly used in game programming
The idea is that everything in your game - like Players, NPCs, Bullets - are Entities. Entities are simply an ID. That's their only property. Nothing else.
But there are Components - they have the data. For example, you might have a `PositionComponent` that has an `X Position` and `Y position` property. And maybe a `MassComponent` that has a property `Mass`. Somewhere in the framework (like a database table), a given Component will be related to a given Entity ID. The Entity therefore becomes a "bag of Components" through the relations.
Finally there are Systems. They do stuff with the data. One system might be `GravitySystem`. It doesn't care directly about `Entity`s, but can query the relations. It might ask for anything that has BOTH a `PositionComponent` and a `MassComponent` (it doesn't know which Entity it is for - it only gets the Components). It takes any `PositionComponent`s it gets and applies gravity: `component.y += gravity`.
The effect is that you can mix and match Components in weird and wonderful ways without having to hard-code behavior and rules for certain entities. You can obviously achieve this with other architectures too - but that's the primary goal of this one.
Making it performant was one of the big problems initially, and it seems like the `Component Graph System` this thread is about trying to answer "how do systems efficiently process components?"... But I don't really get how it answers that actually.
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.
Well, that's what ECS gets rid of and mainly benefits from that. Doesn't returning it back mean going back to OOP? What's the point then?
You don't want to lose compile-time type checking and intellisense, and you want to keep most of the performance benefits. But you want to be able to add data types without recompiling.
Wasn't the flatness of ECS supposed to be a useful feature that simplifies things like iteration and searches?
To me this is the most interesting part. Game logic needs components with references to other entities and components anyway. And if there's some way of identifying components, you no longer need entities to have identities.
And you can still apply all the optimizations as long as you treat some components as "entity" components. But only when you want to exchange simplicity for performance.