Advanced pattern: entities-as-events about bevy-cheatbook HOT 5 OPEN

Ah yes, I have used this pattern myself, I just never thought of describing it as "entities as events" :D.

Spawn an entity to trigger something to be done, carrying the relevant data in components. Have a system watch for such entities and do the things.

Thanks for the detailed breakdown of advantages/disadvantages. This is very useful information.

from bevy-cheatbook.

1. Without some convenience wrappers, creating entities just for events can quickly get boilerplate-y, along with destroying them afterwards. This isn't so bad to fix with a number of helpers to produce and consume these special entities.

Very much agree. I'm curious if there are abstractions worth pulling out into a storage system.

2. Archetype fragmentation. Wouldn't this lead to a number of heterogeneous archetypes of which only a small number exist at a time? I'm not deeply familiar with the per-archetype overhead in bevy.

This is massively improved in Bevy if you opt into sparse set storage for most of your components used in this pattern, introduced in ECS v2 :) In my original use case (a TTRPG-like turn-based game), expressivity and development speed are much much more important than performance, so I probably won't bother toggling this behavior until the game releases.

3. The big one: debugging. Indirect message passing systems are a major pain to debug since you lose stack trace information as soon as the event is queued (or in this case, created and put into the world).

I definitely share your concerns here. I'm hopeful that we can get better tools for this in Bevy itself; the ability to reconstruct what's changed an entity / component is invaluable. Sliced (per component) diagrams of system organization would also be very useful.

from bevy-cheatbook.

This is a reasonable pattern for an ECS and could be nice as a backing layer for a system built on top of it for convenience. It may be worth looking at how other systems do events, such as EnTT's approach (which I believe is a more traditional C++ signal system). I have a few concerns:

1. Without some convenience wrappers, creating entities just for events can quickly get boilerplate-y, along with destroying them afterwards. This isn't so bad to fix with a number of helpers to produce and consume these special entities.

2. Archetype fragmentation. Wouldn't this lead to a number of heterogeneous archetypes of which only a small number exist at a time? I'm not deeply familiar with the per-archetype overhead in bevy.

3. The big one: debugging. Indirect message passing systems are a major pain to debug since you lose stack trace information as soon as the event is queued (or in this case, created and put into the world). If this approach is to become the norm, I recommend working out a way to trace the origins of events in a debug context to see where an offending event came from. In the past I've tacked this (expensively) by storing the complete stack trace at the moment the event was created, as a string, in the event itself. This might be a little tricky in a bevy context, but having that information is a debugging lifesaver.

from bevy-cheatbook.

Following up on the command processing delays listed in my first post, this issue is the place to follow for possible improvements :) This would improve this pattern's ergonomics dramatically.

from bevy-cheatbook.

@recatek Actually entt's author (@skypjack) advised me before for using entities as events. I am at the moment trying to leverage that. I really like the approach and this is one of the major reasons I chose entt because it is very well suited for this use case (Sparseset and it is designed as a generic flexible container rather than an esc system only), adding/removing components will be very fast. I like to think of this approach to be like TCP way of encapsulating packets adding more and more data to it as it goes through the link. IMHO it is more suited for high volume of events than signals, it will lead to less lookups.

from bevy-cheatbook.