[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.