bevy
bevy copied to clipboard
bevyengine
Bevy Editor
Bevy should have an extensible visual editor capable of the following:
- Visualizing / editing scenes
- Visualizing / editing hierarchies
- Extensions
- Interacting with live app data
I'd like to participate in the UX design of the editor, especially the overall interaction principles. Is there already something in progress concerning the editor? Perhaps some code or design ideas?
Could this take the form of a plugin?(or plugins) Personally, I love the idea of being able to take the editor (or parts of it) and include it directly inside my game as a debug tool that I can toggle with F1 (for example).
Yeah why not! Thinking further in this direction, the editor could even be a set of plugins which may be included by end-users in their own products. For example if a game includes a level editor, the "3D Gizmos" and "File Save UI" plugin, which are used by the editor, could be reused by the game.
What are the most essential features that the scene editor must provide in order to be valuable? When I use a game engine editor UI, the most important feature for me is that I don't have to trial-and-error all the numbers: for example, the exact position of a chair in the scene. Therefore, a "Gizmo" plugin should probably be included, which enables me to place objects in the scene. Colors in materials and float properties in my components should probably also be visualized instead of only textual, but this would probably be a separate plugin, right?
An external camera, which can be used to view the scene without running the game, or take a different perspective while running the game, is also an important part to place objects I guess, which could be implemented as a separate plugin
-
Every component like scene camera with gizmos could have a window (as in a ui box, that can be separated and moved from and within the editor main window). That you can place wherever inside the editor window.
-
In my opinion I don't like having an text editor included (like Godot), it is too hard to include all the features and keybindings that users need. I propose a good documentation on how to use external text editors with bevy, since rust lsp backend is fairly good.
-
a) Editor could use bevy ui library, but that would require adding many features. Saying that it would provide bevy with great UI library that could be used not only to develop games.
b) Second option is to use already rust-implemented UI framework like gtk-rs or rust-qt. That would allow the editor to be seamlessly integrated into desktop environments and would require much less development of the UI components and behavior.
c) Last option is to use webview based UI, that has a really fast development time, easy to extend, but slow and non-rusty.
-
Implementation of the editor could be that in order to use it, all you need to do is add the editor to your application. Editor would then render. All configuration would be done from your source code.
-
There should be a simple format to store project configuration so editor can edit the configuration and in code you can simply do
App::new().load_config(path). I suggest RON or other readable format. Other option is to have standard syntax of main that the editor could configure on the fly as rust code addition and removal. -
I would like to hear your opinions and feedback.
3. a) Editor could use bevy ui library, but that would require adding many features. Saying that it would provide bevy with great UI library that could be used not only to develop games.
I think I remember reading that this is the current plan or at least part of the vision for Bevy. (At least for any official editor) And I agree with it. Game ui is more important than most people give it credit for, and the positive feedback loop is definitely key to developing a good one.
ui box, that can be separated and moved from and within the editor main window). That you can place wherever inside the editor window.
Is detaching windows possible with the current rust libraries? If not, only moving (plus adding and removing) editor plugins within a single window looks like an acceptable starting point to me.
I propose a good documentation on how to use external text editors with bevy
Yeah, that's also what I had in mind. I think we should not approach this topic by thinking about how we can copy Godot/Unity/Unreal, but instead try to find out which features are actually important (for example: 3D scene view with gizmos, but no 3D modeling or text editing). There are plenty of existing tools that people would prefer for modeling and coding anyways, I guess.
Actually, now that I think of it, the "moving objects around in 3D space" should already be possible by inputting gltf instead of hardcoding the positions - what advantage does the editor have compared to a popular 3D modeling suite? It's mostly the entity/components properties, I guess, not the spatial positioning
Editor for me and probably a lot of other people is must have feature, so this should be number one in priority list.
Godot Engine already use Control nodes(used mainly by game to build UI) to built engine(with some additional elements), and from what I've seen, it helped to detect regressions much faster.
I think that Bevy should take as much as possible from Godot, since its UI is really good.
Actually, now that I think of it, the "moving objects around in 3D space" should already be possible by inputting gltf instead of hardcoding the positions - what advantage does the editor have compared to a popular 3D modeling suite? It's mostly the entity/components properties, I guess, not the spatial positioning
well, not everything has to be exact. We have to have a simple way that is intuitive to arrange objects in scene. It can be only position, scale, rotation not something really advanced, but it should make it possible to to build levels inside. Also @cart mentioned that gltf is not going to be the format of saving scenes for bevy and only is going to be supported as less featureful alternative. Since that, editor should allow "good enough™" 3D scene arrangement.
if you want @johannesvollmer , we can create some mockups together and talk it through. But we need @cart decision what framework for ui we are going to use
Is detaching windows possible with the current rust libraries? If not, only moving (plus adding and removing) editor plugins within a single window looks like an acceptable starting point to me.
winit supports multiple windows, that should be enough, right?
winit supports multiple windows, that should be enough, right?
Yesss I guess we won't need more
we need @cart decision what framework for ui we are going to use
He said that the bevy ui should be used for the editor, I'm sure that this is the way to go
At the bottom of the blog post: https://bevyengine.org/news/introducing-bevy/
I agree with all the reasons why it should be done in bevy.
I suggest this be developed and released in small incremental steps.
Perhaps the first step could be to create a heirarchy/inspector window to view what entities exist and what components are attached to them. It could be read only for the first iteration.
first step is to agree on the workflow fsin the editor, then hierarchy and adding components to window
The workflow is also the part that is the most painful in other editors, and needs improvement - does the editor even need to know what a 'project' is or is it enough to just open scene files in an editor?
I had the suggestion that it is simply a bundle added to the application and rendered then. But it can also take form of standalone app that creates the project etc. similar to godot
It could be composed of same scene files as scenes within the editor
The bundle is an interesting question. How does it handle a file save? Will it save dynamically generated content?
The bundle approach is nice for debugging but might be difficult to pull off for scene editing, which will probably need another, separate approach, right?
I don't think so. Scenes are RONs that can be changed live at runtime and bevy even has a "reflection" layer
Aah yes, how can I find out more about this reflection layer? Sounds nice
I think having a sketch on how the UI should look like on the first iteration would be a good idea, or maybe screenshot of examples from other programs that we want to reference from.
Yes, in the standard design process, the layout is drafted and discussed in wireframes, to not get distracted by colors and icons. After that, a prototype is coded, still without icons and fancy colors, to examine the Usability and test whether the layout works. Only after agreeing on those traits, the color scheme and fonts and icons and shadows should be discussed. Otherwise you'd already be emotionally invested in your fancy design even though the fundamental layout might not work.
While it's certainly not necessary to strictly follow this standard process, I highly recommend to sketch out multiple different variants using wireframes instead of just implementing the first idea that comes to mind.
For each step (first wireframes and later look and feel) we should gather a collection of good and bad examples that try to solve the same problem (hierarchies, for example) first
I agree, we should probably move this discussion somewhere else until the proper community forum will be established. This thread is getting quite long for newcomers.
How about we use github, but collect our ideas in a separate repository? Everyone here has already got a user account. I feel like Discord is too chat-oriented which makes it difficult to store ideas persistently. Have you folks got some other ideas?
