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?

[bjorn3]

We already have scene files written in the ron format. Only if you are adding components that are not part of bevy itself do you need to compile the editor with those components added. I don't think this is avoidable. How would an editor know that the MyFancyTree component should result in a tree being rendered according to my own algorithm for generating trees if it doesn't have access to this algorithm?

[thraidh]

You could load all user code dynamically if it is compiled to a dynamic library or even WASM. Then those libs would register MyFancyTree and the editor would know what to do. That would also allow you to modify code while the editor is running and hot-reload it. The editor could even compile it for you, so you just change your code, the editor detects the changed source file, recompiles that crate/file/code fragment to the required thing (dylib/WASM/...) and reloads it automatically.

When a final productive build is made, all that code could be compiled natively into one big binary.

[bjorn3]

Dynamic linking only works if you are compiling with the exact same rustc version against the exact same libbevy_dylib.so as the editor. Doing this reliably is only possible by compiling the editor yourself too. As for wasm, that would be possible but not all code will work under wasm and you did have to define a plugin interface to allow passing data between the wasm world and the native world. It is possible but for now compiling the editor as part of the game itself rather than separately will be much easier.

[Pauan]

As for wasm, that would be possible but not all code will work under wasm and you did have to define a plugin interface to allow passing data between the wasm world and the native world. It is possible but for now compiling the editor as part of the game itself rather than separately will be much easier.

That is all possible, Bevy already compiles to Wasm, and Wasmtime exists, and Wasmer exists, and Tauri exists.

The Wasm ecosystem is fairly mature (especially with Rust, since Rust was one of the first languages to compile to Wasm, and Rust is used extensively in Wasm blockchains).

[bjorn3]

I'm not talking about compiling and running wasm at all. I know rust is in a good position for that. What I'm talking about is that wasm can't directly call bevy api's exported by the native half (in this case the editor itself), nor directly access the memory of the native half. You need to define an abi between the wasm plugin and the native host and then translate at the boundary between the wasm half and native half. Doing this is a lot of work as you need to do this for every single function. In addition you need to somehow define a way for bevy components to be serialized and deserialized when passing the boundary. And finally there are some components like many of the render components that contain things that can't be serialized like wgpu buffers. You will need to find a way to keep those components at the native half and only reference them by a handle.

[Pauan]

What I'm talking about is that wasm can't directly call bevy api's exported by the native half (in this case the editor itself), nor directly access the memory of the native half. You need to define an abi between the wasm plugin and the native host and then translate at the boundary between the wasm half and native half. Doing this is a lot of work as you need to do this for every single function. In addition you need to somehow define a way for bevy components to be serialized and deserialized when passing the boundary.

Yes, I know how Wasm works (I was a Rust Wasm Core team member, and I've helped out with the Wasm WG).

All of those issues have been solved or worked around in various ways, since Wasm<->JS has exactly those same problems, and we needed to solve those issues for Wasm<->JS, so we solved it.

All of the complicated busywork (including serialization and proxying) is automated with macros. There is no technical reason why Bevy can't use Wasm, as you said it would require some work, but everything requires work.

I don't necessarily think using Wasm is the best option, but I also don't think we should immediately dismiss it out of hand either.

[thraidh]

Dynamic linking only works if you are compiling with the exact same rustc version against the exact same libbevy_dylib.so as the editor. Doing this reliably is only possible by compiling the editor yourself too.

That means, dynamic linking is reliably possible if you compile the editor yourself once and then only recompile one custom game-specific code part, when that changes.
The other option would be to recompile the editor plus all the custom parts, whenever one of those parts changes.

Therefore editor needs to be compiled in all cases, but dynamic linking would probably be faster and can be done without restarting the editor.

I may be working with incomplete knowledge, so it might sound good, but might not work at all. It is probably easier for editor/bevy developers to make a monolithic editor, but it would probably result in a worse user experience.

I believe, as a library/tool maker we should tackle the complicated stuff to make it easier for the users. That does not mean, that there can't be a first version that is not as good as it could be.

[preland]

I will try to reiterate what I was trying to say earlier, as I don’t think I explained it very well earlier.

If I were to make the editor backend myself (which at this point I’m considering even though I suck at Rust string parsing), I would have it take a rust project file as input (like the folder that gets generated by cargo new insert-project-name). From there, it would look through the main.rs file to find objects and other data via string parsing (which Rust is uniquely good at doing, since it has very powerful string syntax, as well as good memory design; case in point the numerous macros that embed other languages within Rust). From this data, it would create instances of the objects with the same properties within the editor window.

For example, if you wanted to load a scene with a cube and a light in it, the editor would take the folder, parse the main.rs for objects, and would add the objects to the editor itself.

This would mean that the editor isn’t technically directly representing the scene, which is intentional, as this would take too much time. There could be some integration with rust-analyzer to address bugs , but that would be separate from the scene representation (ie. There can be errors in the code while still having the scene render properly coded parts).

When it comes time to “run” the application (similar to how most game engines have a “run” button) the editor would then initiate a compilation and then run the created artifact. The editor could even potentially run a “debug” version of the code with automatic breakpoints and resource allocation (much later idea that someone else would handle) when you “run” the game, and then when it comes time to export the project (I intentionally don’t say build, since the “run” command already does this) it could run in “release” mode.

To address some of the concerns listed above:

1. The editor would not prevent you from writing the project from scratch in any way. To reiterate, this implementation of the editor only modifies .rs files. No extra XML, YAML, or semi-obfuscated data files. Everything remains purely Rust at the end; turtles all the way down.
2. The editor would, in theory, allow someone to not have to touch the underlying source code at all. Now, this wouldn’t be encouraged, as the best the editor could ever possibly standalone be would be something like Scratch, but it would be possible. The most likely way this works is you can add/remove objects, edit the positions of said objects, add components to objects, etc. Anything that requires significant logic will also require coding. The main point of the editor is to make it easier to place objects in the game, and to understand how the end product looks without having to recompile every time you move a box a few units.
3. In the case that I do get around to making an editor in this way, it will probably be incredibly barebones, and will definitely have errors. Especially considering that my environment platform (Intel Mac with integrated graphics) is barely supported by Bevy as is, and has significant graphical bugs (at least it did- it might’ve been fixed by now). I’ll get working on it when I have time, but don’t expect it to really support displaying anything other than cubes and (only specific not-IntelMac buggy) light sources. If I’m feeling really productive, I might even make the camera movable 😂.

Either way, I just want there to be an editor for Bevy that just, works. No lag spikes and no continuous recompilation. UI design philosophy can wait for when we have something to actually apply it to.

[thraidh]

While that idea might fit your current use case, it has some flaws.

You want to parse main.rs for strings to locate entities and components and update those via the editor. You assume, that should be possible, because Rust is good at string parsing (when I think about a language good at string parsing I end up with Perl, because I'm that old), but you were a little light on details.

What if I don't instantiate my objects in main.rs, but in some other included source files? Will your parser follow every use directive?
What if I don't instantiate my objects directly, but instead I have a function cube(x,y,z,color), which can produce a lot of cubes in different locations with different colors? If your parser would understand that and be smart enough to modify the function calls, that would be amazing.
What if I want to have a 8k x 8k height field as a landscape and thousands of trees? Should that really live in main.rs as code?

All these things would not be necessary, if there was some scene file, that is just data and your main.rs just contains something like scene = load_scene_from_file("myscene.xyz"); scene.instantiate(...); where instantiate(...) would turn the scene description into actual entities and components.
The editor can load and modify that same file and you wouldn't even have to recompile your main.rs.

But even this would just be for the MVP editor for very simple use cases, because you also would not want all your stuff in one big scene file.

And then there is the case of custom components and how to handle and display those in the editor, but that is a different discussion.

[preland]

Those are some fair points. As for only parsing main.rs, this was only as a starting point for design, and I wouldn’t be against allowing objects declared in other .rs files being parsed. However, I would prefer to have most of the editor modifications within a single file. It may not be the best idea to have them in main.rs though, so perhaps it could be in its own file, such as an editor.rs?

As for the case of rendering objects via function instantiation, I personally wouldn’t do that. It could be an experimental setting, but it wouldn’t be on by default. This is similar to how Unity and other editors handle function instanced objects. I would like to note that the reason function instantiation is so common currently is not because it’s necessary, but because the lack of an editor makes it the only option to efficiently add large batches of objects.

As for having a data file that is parsed, I personally would prefer not to do so, the reason being that the project should still be capable of development without the editor. Adding a data file muddies this quite a bit in many ways. Plus, unless this data file is human-readable, it will be difficult to understand and change by hand. And as another issue, any errors introduced into the data file will be fairly difficult to debug as opposed to using a Rust file.

Remember that, as far as the editor is concerned, the .rs file IS a data file. It just so happens to read the file and write to it as if it were valid Rust.

[bjorn3]

As for having a data file that is parsed, I personally would prefer not to do so, the reason being that the project should still be capable of development without the editor. Adding a data file muddies this quite a bit in many ways. Plus, unless this data file is human-readable, it will be difficult to understand and change by hand. And as another issue, any errors introduced into the data file will be fairly difficult to debug as opposed to using a Rust file.

Bevy's scene files are in ron format, which is a text format with a similar data model to rust. It is possible to edit them by hand. See https://github.com/bevyengine/bevy/blob/main/assets/scenes/load_scene_example.scn.ron for an example. Am additional benefit of using scene files over rust source files is that it allows hot reloading. You can edit a scene file while your game is running and the changes will instantly be reflected back to the game without requiring any recompilation.

[thraidh]

As for the case of rendering objects via function instantiation, I personally wouldn’t do that.

If I would put instantiations into code it would be mostly for procedurally generated content, so there are good reasons to do that.

I would like to note that the reason function instantiation is so common currently is not because it’s necessary, but because the lack of an editor makes it the only option to efficiently add large batches of objects.

I read that as: to work with a large amount of objects, you either need functions or an editor.

As for having a data file that is parsed, I personally would prefer not to do so, the reason being that the project should still be capable of development without the editor.

Why do you want to modify object instantiations using a text editor instead of an editor that is made for that express purpose?

If you have just a cube and a light, that might even work, but if you run your game with 10000 trees and you want to modify one, you'd probably not even able to find it in your code and even if, you'd have to think really hard about how exactly you have to change its location, because you don't have visual feedback in your text editor.

An analogy might be to want to edit images using a text editor. That is actually possible, if you convert the image to XPM, but would you really want that? LibreOffice/OpenOffice/Microsoft Office documents are mostly just compressed XML, but you'd never want to edit that using a text editor, even if that is totally possible, just not feasible.

[bjorn3]

If you have just a cube and a light, that might even work, but if you run your game with 10000 trees and you want to modify one, you'd probably not even able to find it in your code and even if, you'd have to think really hard about how exactly you have to change its location, because you don't have visual feedback in your text editor.

I believe it is intended to be able to develop without requiring any editor other than a code editor. Also if you have very large scenes, you likely can't include them in the game executable anyway as code, but need to split them into separate asset files to allow lazily loading them only as necessary. If you split a secne out as separate asset, you have to use a pure data format to describe it rather than use rust source code.

[minecrawler]

@preland If that solution works for you, why don't you just go ahead and implement it? The Bevy Community has always been about creating an ecosystem of tools, PoCs and proposals.

However, I think your proposal is not going to scale for other people, who want to do data-driven development in teams consisting of people of different professions, have several big scenes with hundreds of thousands of entities in each, which are not just cubes and lights, and complex logic surrounding them. Hence we'll need to come up with a solution for them as well ;)

For the discussion surrounding the editor and requirements, we already have a big discussion here. Actually, I think it would make sense to discuss hot-reloading and other interesting topics there as well!

[djeedai]

Let's keep the discussion courteous and assume best intent. If @preland thinks editing .rs files is an avenue to explore they're welcome to discuss and try an implementation, even if you strongly disagree. I also think this is not the right path, but who knows, we might be wrong.

Edit: typo

[adam-arthur]

I'm curious why an editor is considered fundamental here.

A big differentiator and part of the reason to choose Bevy is due to it being code-first, without a ton of editor abstractions that make understanding a project more difficult. Especially if there are all kinds of custom metadata files. And using a visual editor tends to be non-ergonomic for people coming from a development background.

Certainly it would be great if any editor was only an optional addition over an existing Bevy codebase, but if it becomes the only supported way to edit Bevy projects, it will lessen one of the compelling differentiating factors. People who want a visual editing experience will likely lean towards Unity or Godot... Rust tends to be too technical of a language for that crowd.

If the editor is optional/not required, then no harm no foul 😄

[Pauan]

@adam-arthur I'm curious why an editor is considered fundamental here.

The purpose of an editor is to compose scenes. You load your assets into the editor, and then you can drag-and-drop them into the scene. Doing that with code for thousands of entities is a massive pain, but it's effortless with an editor.

This is incredibly useful for creating landscapes or modular buildings, or for designing levels, etc.

It's much easier to do this in a dedicated editor, instead of trying to hack it in Blender / Maya / etc.

An editor can be much higher performance (Blender cannot handle large scenes), it can have a better UI, and it can have more features. And the output of the editor can be easily run directly in Bevy. And everything you see in the editor matches with the game engine (lighting, materials, etc.)

Using an editor massively speeds up your workflow, that's the point of an editor. It's just 1 button press to instantly jump from the editor into your game, this creates a very fast development loop.

The editor doesn't replace your code... it complements your code. You still need to write Rust code, even with the editor.

[preland]

Yes, an editor would be optional— consider it to be like the “front-end” of the project, while the “backend” is still usable on its own.

While I do agree with the ergonomic and developmental benefits of code-only creation, it is difficult to justify from an artistic perspective. For example, would you want to paint an image of a landscape using only code? While it can be done, and there are some benefits to doing it so, the lack of immediate graphical feedback is an issue for most users, whether power or not.

The way I see it, using code should be the preferred way of editing a project. The editor is just a tool, or another way of looking at the project as a whole.

(P.S. An update on my current editor progress: I’ve been messing around with the example project that loads in a scene from a file. While I must admit it holds promise, there are some…. rather annoying issues with it. The main one I’m running into is that the current systems implementation limits the parameters you can use to either the full World, or to basically all the other params. This….. is problematic for many reasons, the biggest one being that it makes hot loading/editing a scene nearly impossible without going heavily against the grain of the preexisting codebase. If anyone else wants to mess with the example code for that project, someone above has a link for it [I don’t think the example is in the default branch btw]. I know that syntax matching the main file will be a very difficult task, but I think it will likely be the best way to go forward. If there are security concerns over modifying code algorithmically, the edited file could be a temporary file, similar to how apps like Microsoft Word handle their file editing).

[adam-arthur]

Business application UIs are developed entirely in code all the time, primarily. Usually working off a pre generated mockup of course.

HMR and other techniques are used such that you can edit the code and see the visual impact immediately. It doesn't mean developers are using drag and drop to code the UI.

I don't see a huge advantage to drag and drop vs having a visual REPL, similar to many existing application UI workflows.

In my case the game is 99% procedurally generated, so a scene editor doesn't really provide any value. But obviously that's just one specific case.

Just saying, the primary reason I chose Bevy was that it was code first, and doesn't come with all the design cruft and ad hoc abstractions that editor workflows tend to morph the engine towards.

But if code first is still supported and remains a first class citizen then I have no concerns

[djeedai]

A big differentiator and part of the reason to choose Bevy is due to it being code-first, without a ton of editor abstractions that make understanding a project more difficult.

I think you're conflating having an Editor to edit some assets with having a core "runtime" that drives the app and takes away customizing from the developers. Unity has an Editor that works for custom scripts, and there's close to zero abstraction on it. You can add properties and edit them in the Editor or by code, and it's essentially the same. However Unity also takes over all the core features (audio, built-in renderer, scene management, asset loading, etc.) under a runtime they call "Player" and which is mandatory and prevents customizing a lot of things. The fact the runtime exists is not directly related to the fact there's an Editor. This issue is not a discussion about a runtime, which I think there's relative consensus will be very slim if it ever exists for the reasons you invoked (although it might be useful for beginners). That doesn't change that there's immense value to an Editor; there's plenty of areas like VFX or Animation where working with code alone is reasonably impossible.

[hedgein]

Hello, I am a university student who's is aspiring to be a game dev and loves rust. I've been streaming Rust (and other game engines/coding languages!) for over a year now. I don't know if my two cents are valid here, but I for one will say that I deliciously have been wanting an editor just for the reasons Pauan describes, the benefits to the overall workflow would make me NOM NOM NOM. I would gobble that stuff up hahaha.

[lgsandbox]

Does anyone remember which open issue is currently gathering requirements for an editor? I remember seeing it a month or so ago but forgot to bookmark it.

[lgsandbox]

Found what I was looking for immediately after posting. It was a discussion, if anyone else is looking for the requirements collection for the editor it is here:

#7100

[godotc]

A game project edit and run in editor like loading a dynamic library/module/plugin, and link to the bevy core. Could be packged the core units and run in stand-alone mode.

A interactive scene to construct the world(map/level/scene-tree like other editor) and not to insert the startup system by coding.

A scripting language, debuger and universal assets format. Store the scenes, scripting and art resourcesfor high level develop (without recompile the rust source). Can split the core rs codes lib/feature and dynamic developments.

Some thoughts noted here.

[TristanAppDev]

Any news on this one?

Is there a way to contribute to the editor?

[rrtt2323]

https://github.com/rewin123/space_editor
Does this have potential?

[preland]

https://github.com/rewin123/space_editor Does this have potential?

I decided to look into it, and....

Yes, this is by far the best editor I've seen. It has almost everything done right, and the things it doesn't have right are either easily modifiable by the end user or just plainly unimplemented.

This one has my vote, even if it is admittedly far from production-ready.

[SSebigo]

Personally, the only thing holding me back from using Bevy is the lack of an editor.

I can understand the people that don't want an editor because they like doing everything, but the reality is that in the mainstream, teams are rarely just programmers, and you bet those non-programmers aren't going to learn Rust just for the fun of it.

Godot understood that pretty early into development. Very few people want to deal with code for "simple" things like UI, sounds, VFX, animation, especially with a compiled language.

I would advise just taking something like the project @rrtt2323 posted and build from there. Remove, add, modify what's needed to have the editor as fast as possible. And maybe take it from Godot, alphas, betas, RC releases are a good idea if you want feedback from the people building WITH Bevy and not building Bevy (huge difference).

[HarveyUmbra]

@SSebigo correct but Bevy is not Godot.
Bevy's goals are not Godot's goals.
Here is a comment from @cart where bevy's goals are roughly explained.
comment

One goal of Bevy is that the editor is written in the same programming language as the game programmer uses.
This goal brings many advantages, but it takes a long time until an engine is there.
I hope that your goals haven't changed between now.
Because these goals lead to a better engine in the long run.

[jrmoserbaltimore]

@SSebigo correct but Bevy is not Godot. Bevy's goals are not Godot's goals. Here is a comment from @cart where bevy's goals are roughly explained. comment

It looks like @cart recognized that game engines have tended to converge on the Unity/Unreal/Godot kind of thing for a reason. Bevy is quite different, being all-in on ECS, but the concept of an engine still has many similarities; I'd suggest the following on paper to figure out a rough design:

• Start by grabbing other engine features, designs, and workflows wholesale. What does Unity look like? Godot? Whatever you fancy, it doesn't matter, pick one and mash in the features you like from the others.
• Consider this editor in relationship to how Bevy works. It won't fit well with Bevy's design methodology.
• Start stripping features that make no sense, altering parts of the editor to fit in line with what Bevy does, basically tailor it to be something that started as Unity or Godot but was made into something completely different.
• Take a step back, drop any valuation of your own work and contributions, and decide if what you've come up with looks like it belongs here, or if you need to go back and start tearing it apart and putting it back together again. Nothing is sacred, and no work is wasted; throwing out six revisions of possible editor designs is just the path of learning that leads you to that more-perfect design.

This has the advantage of immediately assuming that highly-mature game development software—what is often called a "studio" because it's presented as an all-in-one package of tools you'll need for a particular task—have refined their user experience over time and so starting there, and then throwing out or heavily modifying the parts of that user experience that don't fit perfectly with Bevy, most probably ending in something that at a glance looks superficially like other editors, kind of operates like other editors overall, but is built around a completely different conceptual framework. Parts of the workflow, like scene editing or UI design tools, might come out looking similar (yeah, probably) because that's the best way anyone can think of right now to do some particular thing or another; other parts will probably be totally different because Unity is not Bevy and the way Unity does something won't make sense for Bevy.

And maybe take it from Godot, alphas, betas, RC releases are a good idea if you want feedback from the people building WITH Bevy and not building Bevy (huge difference).

That too to get the continuous feedback, but I think something non-functional and quick to slap together is the best starting point. You're of course going to throw that directly in the trash and rewrite from scratch.

Imagine you're a software developer in 1988 and your manager describes to you this brand new never-before-done idea of "Windows." What do you do?

You spend a week writing software to draw on the screen, draw a few windows collecting groups of icons, write a file browser, a small paint program, and a text editor, all with the same shape—similar menus, buttons in the same place—and windows that can be dragged and resized. Thing is most of the icons are totally non-functional, and the ones that work don't run programs but rather bring up built-in functions of your little "Windows" program. Barely any of it works, but you can browse your C:, draw some stuff with a brush and paint bucket, type some text and save it to disk with a file open/save dialog box, and move and resize the windows for each of these things.

You show it to your manager, they show it to the people who give you money, and suddenly you have millions of dollars coming your way to hire a team of programmers to make all that stuff happen for real, with APIs and drivers and separate programs that actually work, along with decent performance and good software architecture.

When you do this with groups of specialists, it's called a focus group. Write the dirty little strip of code that pretends to be a rickety and dysfunctional editor but really is practically nothing but some garbage slapped together to kind of look like one, ask people who want to use the engine and its editor if this looks good, and take feedback on what parts feel like they're the right workflow (but broken) and what they think is missing or just a stupid way of doing something. Once you've got something that they like, toss that out and write one that looks just like it but for real.

This approach pays huge dividends. You skip all the work of writing some kind of preview alpha kind-of-buggy concept that kind of actually works until you know what you should be writing.