-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scenes #255
Comments
Could you elaborate on your vision for "inline assets" and "stable ids when loaded from the disk"? |
Inline AssetsInline 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 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. |
Is the format intended to eventually be RON, outside of other scene/asset choices? |
There is no hard requirement for alignment with pre-existing file formats. Low-boilerplate, legible syntax that supports the features above is the priority. |
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. |
I left comments in #92 that I think are relevant here. |
Good call. I'm adding that as a sub-issue above. |
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 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
(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. |
This allows you to unload scenes. Refs: bevyengine#255
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 |
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 Actually what about replacing and pushing over scenes?Like amethyst's Game States, although I don't like the way they are replaced. Returning
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 |
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 |
So to attempt to define more of what a scene is, as there seems to be some confusion about the terminology here: A scene file is a file that defines how to spawn a set of entities with components in an ECS world, and have them as "ready to go" as possible (i.e. no special code to patch up data loaded from a specific file). |
I'll claim that it's possible to implement this within an |
@kabergstrom but scenes are also a struct that holds data for the game state, like main menu etc. Aren't they? |
@cart would have to fill in with his intention for the issue, but the definition in Godot for scenes and prefabs in Unity does not include any extra state outside of the data being spawned into the World (ECS world in bevy's case). |
This allows you to unload scenes. Refs: bevyengine#255
This allows you to unload scenes. Refs: bevyengine#255
This allows you to unload scenes. Refs: bevyengine#255
This allows you to unload scenes. Refs: #255
@WesterWest Re: what kabergstrom said -
Yeah, while in the Godot editor, you can instance scenes inside other scenes, and they show up with a little scene button you can click to go edit the scene file they are defined in, at run-time they just get added to the SceneTree as nodes. Any Node can have any number of children, and can be added as a child of any other node. Any Node can also be saved as a Scene which will include all of its children, and when you instance a PackedScene in code, you get a reference to its root Node which you can then add to the SceneTree wherever you want. I think the reason this is hard to relate to Bevy is that Entities don't have built-in references to their parent or children, and such associations have to essentially be added to the world as Components. Therefore, "removing" a Scene requires somehow remembering all of the Entities that were added as part of that Scene, thus holding on to a Scene handle at run-time, blurring the line between Scenes and Nodes that Godot has. |
@Waridley, do scenes in Godot also include systems? Right now the scenes in Bevy feel more like what other engines I've worked with call prefabs, which just work with components and entities. I think this is a good abstraction to keep since addressing systems takes a bit more architectural thinking as I'll explain below. Scenes as prefabs would allow for the sort of 'scenes within scenes' that you're talking about, but I still don't see how to resolve the system management problem. I actually think that creating a good scenes api would look more like the following:
My reasoning is this would hold more true to Bevy's design philosophy of being pluggable and modular, and make for a clearer API. Right now it feels that the system part of the ECS is tied too closely with the execution context itself. The ECS in Bevy is great, but users might want to sub in their own ECS depending on their needs. Similarly, writing a one size fits all scene manager could be very difficult and would tie very closely with the built in ECS. Rather than trying to tie these all together, the dispatcher class would allow control over the systems and what is running or not, but it disconnects that from the core engine. If dispatcher is made into a trait, then users could write their own dispatchers using other ECSs as long as some built in If the dispatcher is separated from the scene manager, again, it allows for a straightforward, well designed scene manager to be created, but one that can be subbed out if needed. I think that overall, splitting these concerns will make the overall api cleaner and easier to write by making clearer separation of concerns while also making the overall library more flexible. |
@chrisburnor In Godot, I think the closest thing to the concept of "systems" is the handful of "servers" that handle the most performance-critical stuff ( |
I am contemplating making a somewhat similar sort of scripting system, but I think at least one benefit Bevy or any ECS-centric engine would have over Godot is that scripts can be added as components, so you can just iterate over all of the scripts, instead of iterating over all of the Entities and checking for a null pointer. Also I feel like it would be a little easier to extend the scripting system to add custom callback functions by making a system that calls the function on every script. |
@Waridley official scripting is a non-goal for bevy at this point. That being said, those ideas do sound cool and I'm sure some people would be interested. But I would want it to be a third party plugin (at least for now). |
@cart Oh yeah, I meant for my own use. If I did decide to release it as a plugin, I would definitely make it a separate, unofficial crate. |
Is it unthinkable to just activate systems when scenes that require them are loaded, and then leave them running when the scene is removed? If the system has a query such that it only acts on components from that specific scene, it should be pretty much a noop. Or does that lead to poor performance too quickly? I can imagine that unnecessary systems can cause problems for advanced system scheduling, but maybe it's worth investigating. |
This allows you to unload scenes. Refs: bevyengine#255
I just started a discussion on this (#654) for a more in depth discussion than I think we can do in a single issue. |
Re stable ids: What about treating asset ids as interned paths to the assets? You wouldvtheb serialize something like |
The current bevy/crates/bevy_asset/src/handle.rs Line 24 in 4a08370
|
oops accidentally closed this via shortcut :) |
I believe |
|
I'm not sure 'static is a requirement here. We already use "stateful" / seeded serializers for scenes so we can include the TypeRegistry. The AssetServer is also thread-safe and cloneable, so using it for serialization should be fine.
Its not a full solve (and im not sure anything is for dynamic scenarios), but if someone wants to use "anonymous" asset handles in scenes, they can declare a const Handle and use that during loading. We do that for inlined pipelines / shaders not loaded by the asset server: bevy/crates/bevy_ui/src/render/mod.rs Line 21 in 4a08370
|
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.
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
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.
The text was updated successfully, but these errors were encountered: