Triggering events from game loops

[feelingsonice]

This is a topic worthy of discussion because it's occurred to me over and over again, and I think plenty of others have ran into it as well. By all means, it's an opinionated topic and have multiple solutions but I'm curious as to what people think the best practice is.

A common scenario in any game is to trigger a one time "event". E.g. timer timed out, some progress is completed, or you want to transition to another state. AFAIK, to goto solutions include sending a Bevy Event, triggering a one shot system, or transitioning to another state. In all cases the scenario involves a one-time action that should not be repeated for frames afterwards.

However, the systems for which these events are triggered from are often repeated every frame. Consider the following system where you check whether if an asset is done loading, and send out an event once loading completes:

fn await_asset_loading_complete(
    handle: Res<Handle<CustomAsset>>,
    custom_assets: ResMut<Assets<CustomAsset>>,
    mut event_writer: EventWriter<AssetLoadingDoneEvent>,
) {
    let custom_asset = custom_assets.get(&handle);
    if custom_asset.is_some() {
        event_writer.send(AssetLoadingDoneEvent);
    }
}

This works fine until you realize that there's no mechanism stopping it from repeatedly sending the same AssetLoadingDoneEvent. so there's a few solutions that come to mind:

1. Mutate the parameters somehow so subsequent calls don't trigger. In the above example, I could remove the asset so that subsequent custom_asset.is_some() evaluates to false. There are cases for which this approach works, but in this example, removing the loaded asset defeats the original purpose.
2. Keep a flag somewhere and flip it after the first send. This is fine except you'd have to do the extra work of keeping a flag somewhere to flip, not to mention the need to reset for subsequent work if needed.
3. Keep the system under some state and transition out of it when you're done. State transitions, in my testing, don't occur immediately and there could be an extra frame or two for which the system still runs after queuing the state change, not to mention you'd now have the verbosity of extra states you need to keep track of.

So I'm curious what the community thinks. Surely, this is a common thing everybody runs into, but AFAIK there's no canonical solution to. Each one of the three approaches above have its draw backs, and I don't know what the answer is.

[feelingsonice]

Going to tag @alice-i-cecile since she's been helping me on topics related to ECS :)

[alice-i-cecile]

So, you're ultimately trying to model a state machine here. You want to be in either A or B: the intermediate value where you're in A but B is pending doesn't make a lot of sense for your application, nor do you really want to reprocess events.

Like you said, you could use states here, but they're a bit heavy, and don't take effect immediately. apply_state_transitions can be inserted anywhere, but that's a bit clunky.

There are three patterns that I tend to use for this:

1. States, as discussed above.
2. Store a simple enum in a resource, and then guard your checking system with a custom run condition. Like states, but custom and lightweight!
3. Store a Local<bool> in your system, and use that to check if the work needs to be repeated. For example, you might have an event_already_sent: Local<bool> system parameter.

[feelingsonice]

I thought about using 2 and 3 here but the annoying thing is, again, having to reset it. In the example I gave, loading asset is a one time thing for the entire game, but there are other scenarios for which you need it to repeat.

In my previous life with Godot, the engine uses signals (events) frequent enough that there was a signal for everything. Timer timed out sent a signal, state changed sent a signal. Because the engine had been built with signals you didn't have to check a condition in the game loop, you'd just listen for the change of conditions.

I know we have event readers for native events, like there's an event for asset loaded, but it feels like there's not enough events. And I often have to dig around the library for it.

Anyways, aside from my rant, I was wondering if there is a Changed filter for resources? Or only for components?

Thanks again for the help btw.

[alice-i-cecile]

Yeah, I definitely sympathize! Signals are the sort of "reactive" paradigm that the UI and ECS wizards are looking into bringing to Bevy in some way or another.

As for change detection on resources: yes! Use is_changed (or is_added) method on the Res, ResMut, Mut or Ref smart pointer types that you get when requesting resources :)

[feelingsonice]

Does it work the same way events do? i.e. double buffered and persists between two frames?

[alice-i-cecile]

No: change detection is much more reliable than that. Check #1471 for an explanation!

[mockersf]

You need a "state machine" when you're going from something non event based (checking that an asset is loaded) to event based (sending an event).

In the specific case of the code example you gave, Bevy is already sending an event for you (AssetEvent) so you don't need that.