Two-entity queries / relational queries

[droqen]

I've run into a few situations where cross-entity queries (specifically across two related entities) could have been useful. I haven't given this enough thought for it to be a real proposal, but a couple issues have come to light that seem like they could potentially be solved by some form of multi-entity query. Potentially.

See issue #299: In theory we could have some form of query that looks for a relationship like parent outline() != child outline() and changes the value of the child's outline when that relationship becomes true. In this way the recursive relationship falls more in line with our existing ECS query-using paradigm.

If I run into more situations where I'd like this I'll bring them up.

[philpax]

This post by Sander Mertens, the author of flecs, is very relevant.

Being able to model database-like queries against the ECS, and be updated when they change, could be very powerful - but it's also very likely to require a database level of engineering to implement efficiently and ergonomically.

Do you have a list of example queries? It might be a useful exercise to try to design a basic mechanism that could be extended to cover more types of queries in the future.

[droqen]

One thing we're missing right off the bat is even being able to run a query with conditions beyond has_component so an extremely useful first step that doesn't rely on custom conditions could use our already-existing parent/child structure like this:

query(component()).requires_parent_with(component()). . . .

Ultimately I don't think I'd want to be constrained to the pre-existing parent/child components though due to the overlap in behaviours (e.g. if I wanted to be a 'transform child' of another entity but not some other type of child).

I'll try to post a more real example when I get back into my project tomorrow.

[droqen]

Currently spawning a clientside 'visual model' of a serverside 'physical object', I want to connect these two and using the parent/child structure seems to make the most sense to me. I am not currently running into any issues, and do not really expect to within the scope of this particular entity relationship on this project, but I do find it strange that the parent/child relationship is a singular generic type of 'hint' which other components must take advantage of.

In theory a situation may arise in the future where I want an object to be the "transform child" of one parent, and "some other type of child" of another parent. I am capable of using one or two EntityId components to connect two entities as necessary, but this could be generalized in a useful way. I'll come back here as I encounter further in-practice examples.

[droqen]

(Actually in this particular example I don't even want or need the 'visual model' to be the transform child - I just want it to despawn when the parent is despawned recursively. There are no issues in this case: I just don't add the local_to_parent component. But what if I wanted, for example, a transform child that wasn't despawned with its parent? Or a child that would be recursively despawned with either of two parents...?)

[droqen]

The current way of defining relationships is awkward, but also that awkwardness is not particularly avoidable... Whenever I bring my ideas into real code, I can find ways around the need for such an elaborate structure. But it is not as pretty as I would like! and not as readable. maybe that's just life, though. I'll continue to try and maintain a focus on concrete practical problems, and see what I can get done.

If interested, see my relationships package where I attempted to define a general-purpose relationship solution via ECS: https://github.com/droqen/23-08Blue/tree/main/03_packthis/relationships

It was successful, but I'm not sure what if anything it achieved.