Bevy Editor

[cart]

Bevy should have an extensible visual editor capable of the following:

• Visualizing / editing scenes
• Visualizing / editing hierarchies
• Extensions
• Interacting with live app data

[johannesvollmer]

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?

[ashneverdawn]

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).

[johannesvollmer]

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.

[johannesvollmer]

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?

[johannesvollmer]

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

[zenMaya]

1. 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.

2. 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.

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.

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.

4. 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.

5. 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.

6. I would like to hear your opinions and feedback.

[ashneverdawn]

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.

[johannesvollmer]

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.

[johannesvollmer]

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

[qarmin]

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.

[zenMaya]

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?

[johannesvollmer]

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.

[zenMaya]

I do too. Sounds good, even though it will be a crazy amount of work

[ashneverdawn]

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.

[zenMaya]

first step is to agree on the workflow fsin the editor, then hierarchy and adding components to window

[johannesvollmer]

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?

[zenMaya]

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

[johannesvollmer]

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?

[zenMaya]

I don't think so. Scenes are RONs that can be changed live at runtime and bevy even has a "reflection" layer

[johannesvollmer]

Aah yes, how can I find out more about this reflection layer? Sounds nice

[zenMaya]

https://bevyengine.org/news/introducing-bevy/#properties

[andreasterrius]

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.

[johannesvollmer]

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.

[johannesvollmer]

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

[zenMaya]

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.

[johannesvollmer]

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?

[zenMaya]

as I think it's a good idea, here is a link github editor "forum"

[johannesvollmer]

Ok let's officially move this discussion there, why not :D

[johannesvollmer]

https://bevyengine.org/news/scaling-bevy/

Quick update, see #254

[Joe23232]

Why don't we fork Arsenal and like continue to build on top of it, the project was killed off.

This is a Blender extension that turns Blender into a game engine (like Armory). Wouldn't it be better to do this instead?

[memoryruins]

@Joe23232 Arsenal is in active development again! It is also beginning to use bevy really exciting ways https://github.com/katharostech/arsenal/issues/99. For some wonderful words about bevy/arsenal, check out #114.

[cart]

I want to avoid spreading misinformation and I'd like @zicklag to speak for themself (when they are ready), but there may or may not be developments according to the conversation in #828.

To re-iterate, lets assume nothing has changed until @zicklag has publicly announced changes.

[razaamir]

Who is zicklag

I’m raza

On Tue, Nov 10, 2020 at 7:58 AM Carter Anderson notifications@github.com wrote:

I want to avoid spreading misinformation and I'd like @zicklag https://github.com/zicklag to speak for themself (when they are ready), but there may or may not be developments according to the conversation in

828 https://github.com/bevyengine/bevy/issues/828.

To re-iterate, lets assume nothing has changed until @zicklag https://github.com/zicklag has publicly announced changes.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bevyengine/bevy/issues/85#issuecomment-724417567, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHGK5TCPLTBSPHOLJR3GFTTSPCT5HANCNFSM4PU7YATA .

-- Raza Amir

[Joe23232]

@memoryruins @cart

here is his email towards me. He will not be continuing the development.

Edit: I removed it.

[cart]

While I have no reason to distrust the authenticity of that email, it was still written in private with you as the intended audience. I'll let them announce the cancellation in their own words if/when they are ready.

[Joe23232]

it was written by Ziglag himself but yeah it is confirmed I just want to let you know.

[Joe23232]

One question in regards to the GUI game editor, is it going to be all bare bones or is it going to be something like Godot's game editor UI @cart ?

[zicklag]

Unfortunately it is true that we are cancelling Arsenal. There will be a blog post giving the full details very soon. I'll post it here as soon as it is ready.

[grantshandy]

Would the editor be written in the bevy game engine? Or would we use one of the other rust UI libraries like imgui, iced, GTK, etc.

[cart]

It will be built in the engine using Bevy UI. See the Introducing Bevy blog post for some rationale (I talk about it near the end).

[Joe23232]

Is it at all usable the Bevy UI?

[cart]

Usable: yes. Ideal: not yet. I'm planning on giving it some love once I wrap up the Scene system.

[Joe23232]

Can I give this a try, how do I build it for Windows? @cart

[cart]

You can learn how to build Bevy using the Getting Started Guide. There are UI examples here: https://github.com/bevyengine/bevy/tree/master/examples/ui.

[Joe23232]

I see, thanks mate :)

[Joe23232]

Where can I track the issue for Bevy UI?

[cart]

254

[Joe23232]

THanks

[Joe23232]

@cart

Usable: yes. Ideal: not yet. I'm planning on giving it some love once I wrap up the Scene system.

By the way lets say if the game editor UI is a lot more ready, would this mean it would reduce how much code the user has to type, right?

[cart]

Yup! Thats the goal. For future questions, can you ask them on the Bevy Discord? This issue tracker is for tracking progress and generating designs, not general Q&A.