One-off job pattern

[djeedai]

Motivational example

My game needs to load a configuration .json file toward the beginning of the game, then parse it and load other assets depending on what's inside the .json configuration. Many other things cannot happen before this is finished (think of it as a loading screen and preparing assets for what's next). I think that this is a reasonably common use case.

Because AssetServer is asynchronous in nature (see #3129), it's impossible in general to run the following in sequence:

let handle = asset_server.load("config.json");      // enqueue async loading job
let json_asset = json_assets.get(&handle).unwrap(); // panic! async loading not done yet in general
// use JSON...

Side note: I know I can use directly File::open() and workaround the issue by having a blocking load. However this is:

• bad practice: long operations like I/O should be async to prevent UI freeze
• impractical: this complicates a lot running on wasm, where File::open() doesn't work
• arguably bad design: two different codepaths for loading assets, one via AssetServer and one via direct loading, one of which Bevy knows about and the other it doesn't

Instead, it seems the recommended way according to the custom_asset.rs example is to have a system that polls for the loading state and eventually when the asset is loaded use it.

Generalization

The above asset loading pattern is not only quite a lot a boilerplate code to write, it seems that it will leave registered a system that forever will be ticked (or, as an optimization, has a RunCriteria that will get checked, but that's marginally better) each frame for the rest of the application lifetime.

More generally, it seems many one-off jobs like this leave behind them a system that is no longer of any use. This can be optimized I believe by having a dedicated State for the job or set of jobs, but the state itself is also implemented as a RunCriteria, so will still leave behind that check every frame forever.

I suspect that the rationale behind that design is that with a single global state enum (or a few of them), the number of per-frame checks is low. Nonetheless it's 1) non-zero; 2) as far as I know not really well documented as a pattern so may have limitations or drawbacks I don't know; 3) possibly moot since there's some talk about removing Stage completely (#1375, #2801) [EDIT: Stage but not State].

Problem statement

What is a recommended pattern for one-off jobs without impacting too much performance and cluttering the schedule graph? And ideally without having to write too much boilerplate too. Should/could we allow un-registering a system from the ECS scheduler?

[rparrett]

My recommendation would be to not worry about the performance impact of the scheduler checking the app's current state. You're going to want to use states in your app anyway, and the cost of this weighed against the rest of the logic in your app will be extremely small.

A bit of confusion regarding Stage and State is pretty natural, and I don't think that the plans/experiments around a stageless scheduler are super relevant here.

These links would be good starting points.

https://github.com/bevyengine/bevy/blob/main/examples/ecs/state.rs
https://bevy-cheatbook.github.io/programming/states.html

[djeedai]

Thanks for the answer. I fixed the original question; I know the difference between Stage and State, and I'm already using both, not sure why I mixed them. I've already read those links too.

Anyway the point is not only about performance, but also about the clarity of what is running when, and having meaningful states not only for the sake of working around some technical limitation. For example I just added another state value to my main state because I had to wait for some resource to load (because AssetServer is async; see #3129); there's no other good reason to have that value, and it makes reasoning more complex. Alternatively I could have added a "sub-state" (a state only used when another state has a particular value, e.g. what's the state of the main menu when the app state is MainMenu), but I'm not convinced that it's a good approach either.

In short, I'm still not convinced what's a sensible pattern to deal with all those one-off jobs that one might have in a game. ECS is very much oriented to deal with large number of objects by design, so it makes reasoning about this almost as an edge case I find.

[copygirl]

Once assets become entities, surely it'll be possible to use an observer to detect when an asset has finished loading and then run your code just once? Or is there already a mechanic to do something similar today?