Scenes and System Management #654
Replies: 7 comments 21 replies
-
Glad we have another person interested in making Bevy Scenes awesome! Once I wrap up the asset system rework, I'm pivoting my focus to scenes, so now is a great time to have these discussions.
SceneSpawner now has a despawn method
I think this is an idea worth exploring, but I'm not yet convinced it is the best path forward. I agree that we probably want some way to switch between what systems are running, but whether or not Scenes are "just data" or also "system selectors" is an open question imo. Both approaches have value. The "just data" approach is likely easier to reason about. Its certainly simpler, and I think it fits the "Data | System" separation that ECS encourages. I want to experiment with both approaches before making a decision.
This seems like it would get really hairy really fast. My gut reaction is that a more binary
This isn't true? A scene is not a collection of Assets. It is a collection of entities with components that can be added to a world.
Again, scenes currently dont load collections of Assets, they load collections of entities + components. Assuming you meant components, I think having Bundles, Scenes, and Prefabs is way too many choices. If some future Scene design is capable of spawning entities with components, then I think it should probably just replace the existing Scene system.
On my local asset_rework branch I've already given Scenes their own World. I think worlds are the right runtime representation of collections of components. Doing it during the asset system rework enabled me to load GLTF files as Scenes. I also think being able to add Resources from Scenes is a worthwhile experiment. At the very least, I want to support in-line assets. I think scenes should be able to embed assets directly. Supporting all Resources gets a little interesting because they are global, which means multiple scenes adding the same resource will produce conflicts. Thanks again for the interest. I'm definitely curious to hear what the community thinks now that they've had some time to build Bevy projects / learn what they want. Just to guide the discussion a bit, I want to consider "Scenes" and "State Machines / System Management" two separate requirements that might have a common solution. We need to survey the whole design space before deciding that a combined approach is the right call. |
Beta Was this translation helpful? Give feedback.
-
That's a helpful reference point, as are the other comments and clarifications. My survey of the rust game engine ecosystem can be summarized as follows: Low Level Game Engines without ECS builtThis category includes a lot of the well known and popular Rust game engines: ggez, tetra, coffee, rg3d, etc. These libraries focus on graphics, event management, audio, ui and other low level parts of the game, but leave game architecture up to the developer and don't include an ECS built in. Most provide one or more Game Engines with ECS Built InRight now this seems to only be Amethyst, Oxygen and Bevy. Oxygen's ECS is heavily based on Specs, while Amethyst has now migrated over to Legion. Both ECS kits have a They also both have a ObservationsThere isn't a lot to go compare to, but a few observations do come out of this:
Suggestions/TakeawaysThis suggests that we could decouple the conversation about system management even from game state management. I spent a good chunk of time digging through the Bevy examples yesterday and one approach could be as follows (though each of these suggestions can be taken independently)
The more I think about it, the more I like this approach compared to my first suggestion. The plugin idea could be implemented today without any core API changes and merged in as an additional module, but would still allow users to implement their own, alternative approach if they wanted. The first idea, requires only minimal refactoring compared to my original proposal and still provides a simple, easy to reason about way to manage systems. |
Beta Was this translation helpful? Give feedback.
-
I think this might be very useful. I am assuming the following cases |
Beta Was this translation helpful? Give feedback.
-
@cart If glTF files are loaded as Scenes but Scenes cannot be merged, how do you imagine loading a single model glTF and using it in Bevy? A glTF file could contain an entire scene (minus Bevy system components - just the hierarchy, lights, cameras, animations, transforms, meshes and materials) or a single model. It sounds to me like the current Bevy Scene is only different from a Bundle in that it gets its own World? Both are very similar to a prefab - a possibly hierarchical collection of entities and components. Maybe a Bundle is necessarily only one top-level entity whereas a Scene contains 0 or more top-level entities hence if more than 1 it needs its own World. Is that the distinction you see @cart? What do you expect to happen when two Scenes are loaded? Scenes commonly contain cameras, and lights. If loading a Scene has no way of merging with an existing Scene, you necessarily can end up with multiple cameras. How should that be handled? With a merge step one could say that the Scene being merged into takes precedent and its camera should be used while the one in the new Scene should not be spawned. Or vice versa where the existing camera is despawned and the new one spawned. Can a Scene/World have its origin set so that they can be placed in space? How does a player interact with two Scenes/Worlds being loaded at once? |
Beta Was this translation helpful? Give feedback.
-
Just some food for thought from a Unity perspective - I've found that scene management in version control is generally hard. As soon as you have a couple of branches with changes to the same scene file they become very difficult to read / merge by eye (hundreds of lines of changes and interleaving across unrelated objects) I've seen a couple of folks around the place propose the serialization structure of scenes on disk as directories, with one small file per entity (rather than a god file for the whole scene). That way deletions or additions of single objects don't offset every unrelated subsequent line in the file, and common merge conflicts such as "move entity in one branch, delete entity in another" are much easier to resolve. This would probably make them more difficult to edit by hand though (i.e. without the help of an editor) 🤔 |
Beta Was this translation helpful? Give feedback.
-
Maybe we could add a run, run_once, and inactive states to the stages? That way instead of pushing and popping systems we can run or skip system groups with an abstraction that already exists. A bonus is that a startup system could be a run_once stage in front of on_start then reused by setting back from inactive to run once if needed again for reloading. |
Beta Was this translation helpful? Give feedback.
-
I haven't gotten that good of a chance to try out the Schedule v2 rewrite yet, but it seems like it addresses a lot of the use cases mentioned in this ticket. Also, I'm worried that coupling scenes with schedules/states/systems will make it difficult to spawn and de-spawn multiple scenes if they can all arbitrarily change what systems are running. I'm personally also on team Scenes are "just data", since that way the |
Beta Was this translation helpful? Give feedback.
-
This is meant to start a more in depth discussion of Scenes than was possible in the linked issue and more durable and shareable than the discord channel. Hopefully it can bring a good discussion that will lead to a design which can then be implemented, likely as a series of independent pull requests.
Background
Scenes are a very powerful tool in game design for modularizing game architecture. It can be used for:
Problem
Right now Bevy Scenes:
Requirements
To address these opportunities and problems I suggest the following requirements
Proposal
To address these requirements, I propose the following class/module changes
This is meant as a starting point, so I'm curious what the community thinks here. Much of this based on my experience with other ECS and game engines in rust, so feedback on how those have worked well or poorly by other community members would be welcome input.
Beta Was this translation helpful? Give feedback.
All reactions