[looki]

I don't think there is a fundamental difference. ECS is the application of relational databases in a dynamic real-time context with relatively modest amounts of data, but lots of sequential processing. Sparse sets work well in this context, but they are ultimately an implementation detail. There are other ECS implementations that don't make use of it but can still deal with large throughput.

[chrsig]

> ECS is the application of relational databases in a dynamic real-time context with relatively modest amounts of data, but lots of sequential processing.

This is probably the best explanation that I can imagine -- that they're not fundamentally different, just that ECS tends to make a sufficiently different set of design choices that it warrants some of it's own terminology.

I can't help but wonder what a more generalized take on ECS might look like, if it were to continue drawing from relational databases. For example, support for multiple indices to assist with different query patterns. Or triggers to abstract away cascading updates. Or perhaps materialized views to keep query patterns simple.

I've never had the opportunity to use an ECS system, especially in a performance sensitive context, so I don't have a good sense of where any pain points are in practice versus what my imagination can conjure up.

I also wonder what it might look like to use SQL to generate an optimal C++ representation while keeping the data definition high level.

Just idle musings - maybe one day I'll take the time to experiment.

[jayd16]

>Or triggers to abstract away cascading updates.

Triggers might be counter productive. Games usually have a fundamental concept of a game loop. Changes can be processed in the loop and side effects can be processed in the following iteration. Triggers would cause this processing to be unpredictable (or at least harder to predict). ECS provides a clean way to define the order in which systems are processed each loop. Triggers might disrupt this ordering.

Maybe that's still desired, maybe not. I just thought it would be interesting to mention.

[chrsig]

That's a great insight. I wonder if it'd be practical to defer them until after the causal operation was complete

say translating all positions, then calling all of the triggers for the positions component.

that'd keep everything in tight single purpose loops and preserve cache lines.

fair enough that it'd probably make execution order harder to predict, but also in theory it would be in the realm of possibility to generate a plan and print out the order that things would happen in.

(I'm not positing that this is actually worth doing or that the pros out weigh the cons -- just toying with the idea)

[meheleventyone]

A lot of game engines have the concept of messaging that tends to happen synchronously or with a delayed dispatch step which sounds very similar to triggers. The latter comes with a verification cost because the message might not be valid anymore.

The thing with the actual gameplay layer is your often processing mainly heterogeneous elements rather than homogeneous so all the worry and focus on cache is largely academic for most kinds of game.

[rubyskills]

Completely agree on the different design choices. Curious if the analogy of how different gui packages work might have some parallels. FLTK uses a "retained mode" paradigm where IMGUI uses immediate mode. More idle musings..

[k__]

I had the impression, a goal of ECS was parallel and not sequencial processing.

[jayd16]

Strict ordering and sequential layout allows you to efficiently split the work and process these systems in parallel (or with SIMD).