Vision

TL;DR: Think Valve's Hammer editor not Unity-but-Rust.

Bevy's fabled editor has been the subject of much debate and frustration over the years, but to actually come together and build it, the team needs to align on a vision for its future. What is an editor? Why are we building it? What will change? Why do people think that this will push Bevy from a mere "framework" to a "real game engine"?

Bevy's current strengths are simple but compelling:

  • delightful ECS-based architecture: fast, flexible and frankly pleasant
  • absurdly flexible: remove anything you want, and grab great new things from the ecosystem
  • Rust all the way down, making refactoring, building, testing, distribution and improving things upstream painless

In the context of an "editor" though, the current "code-only" approach has several critical limitations that make it infeasible for all but the smallest and most technical of commercial gamedev teams:

  • artists (illustrators, animators, sound effects, music) and designers (gameplay, systems, level) are entirely reliant on more technical team members to integrate and test their work in the game
  • authoring game-specific content (custom materials, levels, designed content like items) requires custom tooling
  • Bevy developers are left to piece together their own testing and debugging workflow
  • Rust's compile times make some iteration-heavy tasks (like adjusting UI or tweaking lighting) painfully slow
  • authoring some forms of content (primarily levels and UI) is painfully slow, even for programmers

The Bevy Editor isn't designed to supplant Rust, or to be an all-in-one game making app with everything from a tilemap editor to an IDE baked in. Instead, it is a place to manage projects, an empowering frontend for artists, a scaffold for the custom tools each game needs, and a home for the visual tools needed to debug and test Bevy games. Users will author their assets and code in their favorite applications, import it into the Bevy editor to perform any Bevy- or game-specific modifications and then use the editor to rapidly tweak, test and debug their games.

Over time, game devs will customize Bevy's editor to meet their needs: both of their project and their role, adding community-created extensions, customizing the workspaces they need for each task, and even writing their own extensions to meet the needs of their game.

Now, let's build this together!

Roadmap

Making an editor is a huge project! How do we even know where to begin?

Like usual, we're starting by building something small. While we won't be adopting any of the existing prototypes directly to avoid drowning in a new sprawling code-base, please look to them aggressively for inspiration on both features and implementations.

The stages contained below are a flexible, coarse resolution roadmap to give newcomers and onlookers a sense of the overall plan and progress. If you'd like to add items to this roadmap, open a PR and ping @alice-i-cecile as needed for dispute resolution. Try to keep each stage small, simple, and easily accomplished. We can easily add more stages, but trying to jump ahead to a complex feature risks killing all momentum. For actionable, well-scoped items, please open issues instead.

As you complete tasks, check them off here! The tasks don't need to be done well to be considered completed here: the Bevy community is very good at cleaning up loose strings as we work.

Feel free to tackle any listed item in any order: foundations and primitives can often be built out well before the features that need them are in place. This list is not "all of the features that the editor will have": other stages will follow as these features are added. It's best not to plan too far in advance!

Stage 0: Hello Project

  • make a repo
  • add a README
  • add a CONTRIBUTING.md
  • add a basic Bevy project
  • define the broad plan for what we're doing
  • define basic constraints for how we're building the editor
  • define a shared vision for what the editor is (and is not)

Stage 1: Standalone Scene Editor

  • undo-redo abstraction
  • can load scenes from disk using a native file picking widget
  • can display scenes in a viewer
    • 2D
    • 3D
  • simple camera controller
    • 2D
    • 3D
  • gizmos can be toggled
    • UI outlines
    • lights
    • AABBs
  • the list of entities and their components is shown in the inspector
    • supports hierarchy via a folding tree view
  • existing component values can be modified using a graphical interface
  • resources can be inspected, showing their values and allowing modification
  • loaded assets can be inspected, providing basic information about them
  • scenes can be saved back to disk

Stage 2: Editor-Game Interaction

  • provide the editor with access to the game's code, allowing it to correctly initialize objects
    • game-specific rendering techniques display correctly in the editor's scene editing
  • users can press a button in the editor, launching the game from the very beginning
  • users can press a button in the editor, and their game will run, loading the currently active scene
  • asset hotreloading, allowing changes in the asset file to be reflected in the editor and game views
  • components that reference assets can be changed to load a new asset via a file dialog
  • components can be added and removed, including components specific to the user's game
  • entities can be spawned and despawned via a GUI
  • entity hierarchies can be spawned and despawned via a GUI
    • manually
    • by composing scene files
  • distinct editor and game views that can be run simultaneously
  • live edit resource and component data in the editor view while the game is running

Stage 3: UI/UX Foundations

  • tooltips
  • hotkeys
  • primitive widgets
    • text entry
    • numeric entry
    • radio buttons
    • dropdown
    • checkboxes
    • slider
    • color selector
    • image preview
    • file path entry
    • progress bar
    • audio playback widget
  • editor UI foundations
    • resizable panes
    • scrollable tool detail panels
    • toolbar
    • Blender-style workspaces
    • context menus
    • command palette
  • dedicated hotkeys and controls for the most common operations:
    • manipulating camera
    • modifying transforms
    • toggling visibility
    • adding and removing entities
    • saving the project
    • opening the command palette

Stage 4: Fundamental Features

  • preferences
    • hotkey rebinding
    • camera controls
    • preferred language
  • scene object picking: click on objects in the scene to select them in the inspector
  • entities can be looked up by name in the inspector
  • system stepping support
  • create new Bevy project
    • blank
    • from template
  • localization framework (first-party: English-only)
  • launch targets/profiles
    • launch a prebuilt binary (for non-technical users)
    • cargo workspace apps and examples (for developers using the editor from the codebase)
      • set feature flags
      • (stretch goal. maybe as part of a possible vscode integration) read/write .vscode/launch.json
    • option to launch with a default profile when the editor opens

Uncategorized work

There's a great deal of further feature work that needs to be done beyond the current milestones. They haven't been forgotten, and are listed in no particular order here:

  • editor extensions, for adding custom functionality
  • a central hub for hosting (and selling?) editor extensions and assets
  • performance overlays of all kinds
  • system graph visualizer
    • filter systems by data access
    • filter by system set
  • systems affecting the selected entity
  • Tracy-powered runtime profiling
  • investigate a separate process model using Bevy Remote Protocol
  • investigate code hot reloading and dynamic linking
  • animation graph editor
  • particle effects editor
  • tilemap support
  • edit the abstract syntax tree (AST) of the Bevy Scene Notation (.bsn) format
  • in-game dev console
  • MaterialX custom material creator
  • basic audio editing
  • graph visualization of component values
  • entity clustering with a memory usage breakdown
  • generated in-editor documentation for Component/Resource types
  • go to definition support that opens the relevant code in your IDE of choice
  • event diagnostics

While there are also important engine features that will unblock or improve various parts of the editor (relations! BSN!), this should not be tracked here: the emphasis is on user-facing goals, not any particular path.

Design Constraints

To help ensure that we're building an editor that's both useful to end users and feasible to maintain, we've developed a set of design constraints and goals. Please try to follow them when making and reviewing changes! As we're developing, initial prototypes may bend or break the rules: just be mindful of how we can move towards the final desirable end goal.

Below each bullet point, motivation is given.

Must

  • The Bevy editor must be a Bevy application.
    • This is essential both for dogfooding and to ease development: Bevy contributors all know how to write Bevy!
  • The Bevy editor must run on Windows, Mac and Linux.
    • These desktop platforms are the key targets, as they are used by professionals for in-depth creative work. Web is a stretch goal, mobile and console need substantially more design.

Should

  • Reusable code (camera controllers, inspectors, UI widgets...) should be cleanly separated into dedicated, documented libraries.
    • This keeps our repository clean, and allows users to steal our work to use in their own projects and tooling.
  • Widgets, styles, colors and interaction paradigms should be consistent across the editor.
    • This avoids duplication, makes changes easier and helps give the editor a cohesive look.
  • The editor should be distributed as an executable, either directly from the Bevy website or via Steam.
    • This makes it easier for non-technical users to install.
  • The editor should be configurable, and easily adapted to both different genres and specific games.
    • Every game needs a different set of features. We need to allow teams to expose or extend what they care about, and hide what they don't.
  • Industry-standard conventions for controls, UX and so on should be followed unless there's a good reason not to.
    • Learning a new tool is hard enough: please don't make it any harder.
    • When multiple competing standards exist (or the standards are bad), we should offer preset control schemes that map directly to familiar tools.
  • The Bevy editor should be stable, and recover from crashes in the game or the editor as gracefully as possible.
    • Losing work sucks a lot!
  • Iteration times should be kept fast, using whatever means make sense for a given workflow.
    • Compiling Rust is slow, and more iterations speeds up work and leads to a better result.
  • Version-controllable: assets and settings should be feasible to check into version control and be relatively robust to merge conflicts.
    • This makes sharing settings across teams easier, and reduces confusing and wasteful problems with consolodating changes.
  • Integrate nicely with other related Bevy initiatives, namely dev tools and the Bevy CLI.
    • We should avoid duplicating work and stepping on each others toes.

Should not

  • The editor is not an asset or code creation tool (certainly not in the default configuration). If an established tool does a good job authoring content, focus on importing its output, not reinventing Blender, VSCode, Asesprite, and Reaper.
    • We have limited resources, and this isn't a good use of them. Artists and professionals already know and prefer specialized tools.
  • The Bevy editor should not have a native look-and-feel, and should not use native menus.
    • This is a poor use of resources, leads to inconsistent aesthetics, and makes it harder to test and teach across platforms. Instead, focus on the useful behavior and design conventions.
    • File picking widgets are an exception: these are non-intrusive, good crates exist and are not central to the user experience.
  • End users should not have to install or update Rust.
    • This is a relatively challenging task for non-technical users, and should be handled transparently by the installer if it's absolutely needed.

Must not

  • Users must not have to write Rust code or use a terminal to perform core workflows of the editor.
    • Gamedev teams have critical non-technical members (artists and designers) that need to be able to use the editor.
  • 3rd party UI solutions are forbidden: bevy_ui and abstractions on top of it only.
    • Dogfooding and improving bevy_ui is a major goal. If something sucks, fix it upstream!
  • No scripting languages.
    • This targets a very niche audience: Rust is safer and easier to write than C++ and pure artists won't write Lua either. Prefer GUI controls, and then defer to node-based logic for highly complex art/design workflows.

Open questions

Some questions aren't decided yet, and are highly controversial!

  • Should the Bevy Editor live in the Bevy repository (tracking main) or its own (tracking latest)?
    • Arguments for tracking main
      • There's no need to duplicate project management and CI processes.
      • New changes to Bevy can be used immediately.
      • Emergent editor needs can be addressed and tested in a single PR, without needing to wait a cycle.
      • The editor serves as a great stress test for all of Bevy's systems.
      • The editor will never require painful, dedicated migration work, as it must be fixed in each PR.
      • The editor can be used to aid feature development and testing of Bevy itself.
      • Users tracking main will have a functional, if unstable editor for their games.
      • Pulling in 3rd party Bevy dependencies is a large maintenance burden and risk.
      • Functionality that's essential to the editor is often essential to end-users, and should be upstreamed anyways.
    • Arguments for tracking latest
      • Project management is easier: separate PR queues, issues, and permissions
      • We can use third-party Bevy dependencies, avoiding reinventing the wheel and exploding scope.
      • Updating the editor during each stabilization period is a great way to stress test the migration guide.
      • Users can use unstable versions of the editor in their real projects.