Scenes

[cart]

This is a Focus Area tracking issue

Bevy Scenes currently do most of what we want, but they need a bit more work before they can be the foundation of Bevy state management. This focus area is also a requirement for the Bevy Editor.

• Asset Management: Inline assets, asset dependencies, stable ids when loaded from the disk
• Better Scene Format: Improve the legibility and ergonomics of scene files to make them easy to read and easy to compose by hand. We're shooting for something close to this.
• Enabling/Disabling Systems: Scenes should be able to toggle their required systems on and off when they are added / removed

Active Crates / Repos

No active crates or repos. Feel free to make one. Link to it in this issue and I'll add it here!

Sub Issues

• Improved Scene Format: Improved Scene Format #92

If you would like to discuss a particular topic, look for a pre-existing issue in this repo. If you can't find one, feel free to make one! Link to it in this issue and I'll add it to the index.

[kabergstrom]

Could you elaborate on your vision for "inline assets" and "stable ids when loaded from the disk"?

[cart]

Inline Assets

Inline assets would be cases like this in scene files:

Entity [
  Handle<Material>: Asset(
     Material(Color { r: 1.0, g: 0.0, b: 0.0, a: 1.0 })
  )
]

The Material asset would be automatically created when the scene is loaded and the asset's UUID would be assigned to the Entity's Handle component.

Godot, for example, handles them more like this (adapted to fit "potential future Bevy Scene syntax"):

assets: {
  ASSET_UUID:  Material(Color { r: 1.0, g: 0.0, b: 0.0, a: 1.0 })
},
entities: [
  Entity [
    Handle<Material>(ASSET_UUID)
  ]
]

The first approach makes composing UIs by hand nicer (but we could also do that by not using assets for colors in the UI, but thats another conversation).

The second approach makes assets re-usable within a scene file and is a bit more organized and explicit. And it would remove the need to define a special "inline" syntax.

Stable Ids Loaded from Disk

"Imported" assets are assigned a unique id, which is saved somewhere in the filesystem (either next to them or in a database file). This assignment could either be manual, during app startup, or in the editor.

(this is very much what atelier-assets already does).

In general I wanted to make sure this focus area included enough asset features to force us to make a decision about atelier-assets.

[Fishrock123]

Is the format intended to eventually be RON, outside of other scene/asset choices?

[cart]

There is no hard requirement for alignment with pre-existing file formats. Low-boilerplate, legible syntax that supports the features above is the priority.

[lachlansneff]

Atelier assets has a lot of great features, but if it's deemed to not quite fit into bevy, I'd be happy to continue pushing bevy_assets in the right direction.

[aclysma]

I left comments in #92 that I think are relevant here.

[cart]

Good call. I'm adding that as a sub-issue above.

[Ratysz]

The way I usually do scenes is have my scene stack be the top-level abstraction, with each scene holding it's own local state and sharing some sort of global state, passed as a &mut argument into most of their callback methods.

Scenes can be as small as a context menu (right-click dropdown list at cursor), or as big as the main game scene. The scene trait has multiple callbacks with default implementations, which allow a scene to opt in into having behavior in response to stack-level events (update, update whil top scene, draw, become top scene, stop being top scene...)

The global state contains hardware contexts and any other "singletons" the app needs - the main world and resources, and systems that run at all times. Local states contain scene-specific systems and resources; haven't had a reason to hold a subworld in a scene, but that's possible too.

Scene update callback returns a Transition enum which defines operations on the stack. With those, scenes can be popped, dropping them, or "deactivated", which runs a special callback (for de-regestering observers and the like), then moves them from the stack and into the stash. An "activate" transition can be used to later un-stash a scene and put it back onto the stack, running a different special callback. This allows churning heavy states in and out without having to fully reinitialize them.

Scene is a trait, but the scene stack does not contain trait objects - I took inspiration from enum_dispatch crate and wrote a variant of it's macro to let me easily define an enum of states that the app will be using (the main difference between the two macros is that mine supports more generics; I'm still not done plumbing in all the ones I want, though).

(As a side-side project, I've been slowly polishing this snippet to be released as a general-use crate; if there's urgent interest I can make the repo public, or give access.)

Perhaps something like this could be used for Bevy? The app could still be top-level struct with it's schedule, world and resources; the scene stack could be a field in it, global state for it's scenes being the world and resources of the app, with scenes' local states holding their own schedules. Bevy-provided systems would execute methods of the stack, running scenes' callbacks, at specific points in the global schedule. Perhaps it could/should be wrapped into a plugin.

This would pretty much solve #128 and #279, potentially #125.

[Cretezy]

I see scenes are a 2 part problem.

First, is scenes are a tree representation of entities. These have types, properties, optionally IDs, and more. And second, scenes are composable, so including scenes should be possible.

For this, using a HTML/JSX-like syntax makes a lot of sense, as that's already well understood, supports the requirements, and can support building UI as scenes in code in the future (with more widgets for example). A React-like rendered could be created for translating UI in the format into a live scene.

This could follow https://gist.github.com/Moxinilian/c45a1858eca7e918b5728ee5c117f649 and https://gist.github.com/cart/3e77d6537e1a0979a69de5c6749b6bcb syntax as a better scene format.

Additionally, compiled scenes is a must be compilable and includable in or outside binaries. Having a binary format that can be compiled using a macro would be a big win, as this would reduce reading/parsing time, which will be essential during production games

[zenMaya]

For this, using a HTML/JSX-like syntax makes a lot of sense, as that's already well understood, supports the requirements, and can support building UI as scenes in code in the future

Well there were some talks about this and XML is just ugly and nobody wants to write XML if they can. Also it's too verbose. indenting and bracket highlighting make it easy to read it without specifying closing tags with </tagname>

Actually what about replacing and pushing over scenes?

Like amethyst's Game States, although I don't like the way they are replaced. Returning Trans::type is clunky and sometimes unnecessary (for example when every time checking if state should be changed running if ~"every frame"), we could instead call a function replace_scene or a add_scene and remove_scene with the scene_id or scene_name as a parameter. This can be either:

• simply managed in the World as a resource struct SceneMachine's children
• or unmanaged in that World can hold scenes separately as similar to entities in a sense that scene can be added and removed from the world at will. And world will execute scene setup function when scene is loaded and scene itself is responsible for cleaning scenes from before from the World and can have the enabled bool to manage them

I'm not actually sure if the @Ratysz solution isn't better, but I didn't like it as it is the way for amethyst and thought maybe we could use a different approach

[Ratysz]

Oh, of course - it should be perfectly fine to somewhat invert control in the abstraction I described; the suggested way of integrating it into Bevy comes from that description alone.

It could indeed do without the callbacks returning a Transition - since a scene has access to the global world it could just write the changes it wants into it. The only thing it can't do that way is move or remove itself directly, that will likely have to be queued akin to Commands for entities, or passed as a parameter to next scene's initialization.