I hit a specific problematic case that got me thinking more about this.
So if you destroy an entity if it has a child but that child isn’t also in LinkedEntityGroup, that child won’t be destroyed.
The transform system is just fine with this though, it will handle the hierarchy correctly.
It seems like ECS is begging for some more structure around entity relationships and integrity checking.
You have LinkedEntityGroup which is an entity only context. You have other cases like Child that have more context but it’s still very nebulous. What makes up a child? It’s whatever the people implementing the relation decide it is, it’s completely arbitrary and most important not discoverable outside of just observing behaviour.
I think it should be entirely optional but I’d love to see some way to define relations and constraints. Some type of framework for that and some abstracting out the common bits.
Maybe something like an internal array with offsets for the type of relation as a base implementation. Since actual linkage seems useful to abstract out. Potentially easier to use, less boilerplate, and gives more context to the entity debugger.
The type of relation would be extensible as would the integrity logic. Basically completely arbitrary. Just having the framework would be hugely helpful I think.
Child is SystemState. You should never modify it and the only reason it is not internal that I can tell is because it is a useful property to read. However, you can modify the LinkedEntityGroup directly.
While I get where you are coming from, DOTS defines relations and constraints by archetypes, and each kind of relation or constraint is handled by independent systems that you can compose together with the correct archetype. I personally don’t want that to change.
What I would like to see is a better way of figuring out what LinkedEntityGroup an entity belongs to.
Not all relations are defined by archetype though. And there is no way to enforce integrity. IMO you need the latter as an option. And since the former is a thing then a solution has to allow for arbitrary types of relations.
The relation itself you could abstract out in a way that solves for resolving both ends of a has/belongs to relationship. And at the same time remove the need to define a new component type for every type of relation.