HackMDBevy Editor Design Questions
This is a list of questions that must be answered as part of the editor design process. I've written this up as a result of some recent discussions I've had about editor progress, and my main goal is to demonstrate that The Editor Is Not Blocked On UI. f There is a tremendous amount of work that will go into the official Bevy editor that has nothing to do with how it looks. In fact the UI is the least of my concern.
When project leadership blesses an answer to one of these questions, I will write it here in a green box.
Answers that require refinement, upstreaming, or other significant work are listed in blue boxes.
Questions that have no official answer will be listed in yellow boxes.
Assumptions
The intended scope of these questions is the vanilla "MVP Editor" without any customization. This is the theoretical editor users will encounter when we publish a blog post saying "Hey Look! We have an Editor Now".
I'm also assuming the "Editor" will be a stand-alone graphical application built using bevy, as that seems like the broad consensus. Project leadership has expressed strongly that we will not use egui or other 'non Bevy-Native' tools to build the editor, so let's assume that as well.
Procedural Questions
Questions about the development process.
- Who "owns" the editor?
Forget about who holds the license to the code, who has responsibility and decision-making power? Without an SME-Editor or Editor Working Group, is Cart the only one who can make decisions about the editor? If that's the case, then I'd really like to see Cart spending time answering these questions.
At the risk of editorializing a bit too much, are we confident the existing SME system is a good fit for the editor?
No official answer.
- How stable should the editor be?
Are we going to try to design things that won't need to change or be replaced? Are we ok with ripping out and replacing large sections of the editor every so often, just like we do with the engine?
No official answer.
- Should the editor be part of the Bevy repository?
Making the editor part of the Bevy repository will make sure that we have more complex apps to test our changes with, and avoid unpleasant and tricky migration work. It also means that necessary changes to
However, it will also be very noisy in terms of PRs and issues, and make iterating on engine changes harder, as there will be more code to migrate and test with every change. This will also greatly increase the size of the Bevy repo (unless smarter strategies are used) as assets for localization, testing and UI are included.
The Editor will be part of the main bevy repo, helping it to be developed in line with bevy and more directly dog food it.
- Can the editor use third-party crates that depend on Bevy?
For example, it may be convenient to add bevy_inspector_egui or leafwing-input-manager.
These crates would be useful to help bootstrap the editor!
On the other hand, using crates in this way introduces a pretty severe maintenance pressure on the volunteer maintainers of the crates, and risks blocking our upgrades. Doing this would be incompatible with a codeveloped engine and editor (see above) because of circular dependencies.
They're also indicative of missing or broken features in Bevy itself, and probably shouldn't be papered over.
No official answer.
Scope Questions
Questions defining the size and scope of the MVP.
- What can the editor edit?
There's a broad consensus that the editor will author .bsn files.
Great, can it read or write any other files (other scene files like .gltf, what about .obj, .mesh, or .anim)?
No official answer.
- Should the editor have a code editor by default?
Editing code is a big part of writing games! However, writing good code editors is very hard, and we should expect that most of our programmers already have a working setup that they're happy with.
No; users should primarily use their preferred IDEs.
- Who is the editor for?
What are the primary categories (persona) of users that we initially want to support?
Do you need to be a programmer? Do you have to know rust? Do you need rustc, cargo, or the rust toolchain installed? Should artists be able to author files in the editor without having to set up the technical side of things? Will users need to know their way around the command line?
The editor is for game dev teams and non programming individuals. In game development programming is only one facit of the process, artists, level designers, etc all require an editor to work effectively.
- What are the most commmon and important tasks that users will want to do using the editor?
Furthermore, how do we know what users are going to want to do? How do we decide what is an important use-case and what is not? What is our process for making sure we serve these user-stories and workflows?
No official answer.
- What tools might users want or expect to have included in the editor?
We can do competitive analyses to see what sorts of tools other "Editor-like" apps provide: Blender, Maya, Unreal, Unity, Godot, even Flecs Explorer. This includes all tools users might expect from something called "The Bevy Editor", not necessarily just the ones we think we should ship in core MVP.
No official answer.
- What unique needs and opportunities does the Bevy Editor have that most other game engines do not?
What might we miss from just analyzing other editors? What can we use to differentiate Bevy from other engines? What sorts of new tools will we have to design to take advantage of these differences?
No official answer.
- What is the default set of tools we should ship to users?
Considering the answers above, what feature-set should we ship for the MVP editor? What is the roadmap to getting those features implemented?
No official answer.
- Will the Bevy Editor have its own custom scripting language?
Scripting languages are a popular solution when writing gameplay code, especially by technical artists and game designers. Advocates say that they're easier to learn, faster to compile and more productive for prototyping.
However, scripting languages seriously complicate the learning and maintenance process of Bevy. An integration is a huge amount of work to write and keep up-to-date, and many contributors are skeptical of the benefits and leery of the technical debt and performance costs of scripting languages in games.
No. However, we will support efforts to make third-party scripting integrations viable.
Asset-driven workflows and Rust hot-reloading will be prioritized as alternative solutions.
Infrastructure Questions
Questions about how to implement core features.
- How does Undo/Redo work?
Pretty much all software has support for undoing and redoing actions, but Bevy does not currently have built-in or blessed ecosystem crate that provides this. How are we going to implement this?
This is perhaps going to be one of the hardest aspects of the editor UX to get right, and deserves serious investigation as soon as possible.
No official answer.
- How do hot-keys and keybindings work?
Most complex 3d graphics software allows users to create custom keybindings and bind them to actions.
There are a few crates that support this sort of functionality (like leafwing-input-manager, which is planned for upstreaming).
Do we want to use one of these crates, or make something custom?
leafwing-input-manager will be upstreamed (learning from bevy-input-sequence), and the editor will use that.
Marked as partial answer; requires significant work.
- How do we approach localization?
People make games all over the world. If we want Bevy to succeed, we should take care not to leave behind people who are non-english-speaking or english-as-a-second-language. Rust has several localization solutions, which do we want to go with? Are there any languages we want to try to support? Can we pay for translations, or will we have to crowd-source them?
We will use fluent for localization.
Marked as partial answer; We have yet to see an example of how to use fluent with Bevy UI, especially as it relates to UI loaded from bsn files or defined using macros.
Prototypes must be able to demonstrate switching between localization languages at runtime.
- How do projects work?
Does the editor know about "projects" that contain a bevy rust codebase and possibly many scenes and asset files? How does it manage these? Can editor state exist above and between scenes, or is it focused on editing one scene at a time (in the same way that Photoshop is more or less focused on editing one image at a time, but lets you have multiple images open in different tabs)? What is the smallest self-contained context: A project, a scene, or an asset?
No official answer.
- How do we enable team collaboration?
Most games are made by multiple people, and that means they have to share project files.
Code and text-files (like bsn) can be checked into git but assets and binary blobs really shouldn't be.
How do we expect people to work on shared projects?
How do we anticipate them keeping their projects in version control?
Should we try to integrate with VC at all, or leave it up to users?
No official answer.
- How do per-user and per-project settings work?
Users will want to customize their editor:
- within their team
- across projects
- specific to their own preferences
How will these be managed, stored and possibly synchronized? This problem is surprisingly complex.
No official answer.
ECS Questions
Questions about how the editor will interface with the ECS.
- What does the editor know about your app?
Does it know about your components and their fields? What about resources? What about systems and schedules? How does it know what it knows?
What if some of your code has #cfg macros that change the components/resources/structs on different platforms, is the editor aware of that?
Do you have to run your app for the editor to inspect this data, or can it pull it from the source code?
What happens if you change your source code while editing scenes with the app?
What happens if you change a component, then open a bsn file that contains a definition using the old version?
No official answer.
- How do users edit components?
Components have a ton of different properties, and editing different types of components requires very different workflows.
For StandardMaterial you need an input for Handle<Image>, a Color picker, a way to select UvChannel, sliders for f32, a dropdown menu for AlphaMode, and even a way to input Affine2!
The Transform component also needs it's own input gizmo probably.
How do we know the correct graphical input to present for each of these types?
No official answer.
- How do users interact with non-graphical components?
We're all comfortable with interacting with moving shapes around the graphical viewport, but not all entities fit this pattern.
Some entities may not have a Transform and exist without a position.
Others, like lights, may have a Transform but nothing directly to draw.
How do we interact with these sorts of things?
No official answer.
- How doe users interact with the hierarchy?
The Bevy hierarchy is extremely important. How do we allow users to observer and modify it? When relations come along, how will users be able to interact with them?
No official answer.
- How do static scenes connect to code?
If the ECS is like Bevy's DOM and bsn is Bevy's html then is the editor bevy's version of a fancy WYSIWYG .html editor?
How do users add runtime objects like Observers to entities defined in scenes authored in the editor?
Is it possible to use the editor to design reactive components, or scenes with dynamic inputs?
No official answer.
Architectural Questions
Questions about the structure and organization of the editor.
- Should the Bevy Editor be embedded in the game, or standalone?
Being able to embed tools directly into your game is great for debugging and quickly hacking around.
However, stand-alone editors are easier to customize for artists and other non-programmer workflows, and are better suited to asset authoring.
We could also thread the needle, by creating reusable Bevy plugins that can be added to your game, while also using those same plugins in a standalone editor.
Tentatively, we're aiming for the best-of-both worlds approach, splitting off reusable components (primarily into bevy_dev_tools) and then adding them to the editor.
The standalone editor should interact with the game process via the Bevy Remote Protocol.
All this requires a technical prototype to ensure viability and nail down open questions around user experience, especially for non-programmers.
- How can users configure the Bevy editor to meet their needs?
Every project and every user will have different needs. Tilemap editing will be vital for some games and worthless to others for example.
Users should be able to add, configure and disable components, including third-party components. Ideally, this should be easily doable (on the standalone editor side) without requiring any code.
No official answer.
- How do users download / accquire the Bevy Editor?
Getting started with Bevy is a vital part of the user experience. Currently, users are told to install Rust, and then create a new project using Bevy in an IDE.
Will that still be the primary learning path? Will users need to download Rust to use the editor? Will users need to download Rust to run their game?
Will we ship precompiled binaries of the editor to users? If we choose to ship these, how will we build and distribute them? For what platforms?
No official answer.
- How does version compatibility work?
To call Bevy unstable would be somewhat of an understatement. How closely tied will the editor and runtime be, tightly-coupled or more of a version compatibility range? Will people have to install a new version of the editor every time bevy releases an update?
This question gets really deep when it comes to files authored across versions.
Is there a plan for bsn backwards compatibility?
Is there a plan for automatically fixing bsn scenes between releases? Can the editor edit bsn files from other versions?
No official answer.
- How should third-party developers integrate their tools into the editor?
In many engines (Unity for example) users can overwride things like the default inspector to substitute in their own custom functionality without having to recompile from source.
Can developers replace significant subsystems with their own impls? What does that API look like, and how stable is it? Do we want to expose core functionality as traits? Do plugins need to be able to overwride this functionality at runtime (likely using dynamic dispatch)?
TODO: Clarify the difference between compile-time and runtime extensibility in this question.
External extensions are not planned for the MVP. While this feature is extremely useful, for broad adoption, it probably won't help with professional teams, who tend to want to directly modify the editor and engine source code.
For the MVP, we plan to lean heavily on native Rust / Bevy functionality for getting things running and modifiable. Building general frameworks like an extension API without prototypical examples to build on is really hard.
