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 Read-Only Editor

  • 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
  • lists entities in the scene
    • supports hierarchy via a folding tree view
  • click entities in the list to select them.
  • components of selected entity are shown in the inspector with component values, including components specific to the user's game
  • resources can be inspected, showing their values
  • loaded assets can be inspected, providing basic information about them

Stage 2: Basic Editing Capabilities

  • undo-redo abstraction
  • entities can be added and removed
  • components and resources can be added, removed, and modified
  • scenes can be saved back to disk
  • interactive transform gizmo in the viewport
    • translation
    • scale
    • rotation

Stage 3: 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
  • 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 4: 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 5: 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.

Glossary

  • View: Provides a specific view of the data, displayed within designated layout Panes. Some common views include the 3D Viewport, Scene Tree, and Entity Inspector.
  • Pane: Rectangular sections dividing the window, each allocated to one or more Views.
  • Region: Rectangular sub-sections within Views, each serving a distinct purpose or function.
  • Workspace: A layout preset that organizes the window into Panes, each containing specific Views.

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.
    • Instead, the Bevy Editor is a scene creation tool with powerful Bevy-specific debugging capabilities, with limited asset-tweaking capabilities for quick and simple tasks.
  • 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.
  • The Bevy Editor is not a plugin for a third-party editor like Blender or LDTK. While tools like Blenvy can be very productive for a team making a specific game, they're not a replacement for the Bevy Editor.
    • The existence of a standalone Bevy Editor tool (even with relatively limited capabilities) is valuable for helping new users get comfortable with the idea of making games in Bevy and become a functional member of a team.
    • Each of these tools focuses on a single style of game: primarily 2D vs 3D.
    • Being able to see your scene as it appears in the game is a vital requirement for effective scene creation: third party tools will not have the appropriate level of integration and come with their own subtly different rendering engines.
    • These tools have their own specialized learning curve, and a huge quantity of unrelated functionality. This comes at a cost in terms of performance, learning curves and usability.
    • The editor components (cameras, transform gizmos, UI elements, inspector and more) are incredibly valuable for the Bevy ecosystem as a whole and will be reused in other tooling and Bevy projects.
    • While some functionality (primarily level editing) is shared, much of the more specialized functionality (the system graph visualizer and system stepping for example) is Bevy specific and requires tight integration.
    • Coupling Bevy's development to an external tool makes project management and the developer learning curve much more painful, and introduces a large amount of external risk as the projects we depend on can make serious breaking changes or go defunct without warning.

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.

Overview

  • Design Paradigms - The design philosophy of Bevy's editor.
  • General Patterns - More specific patterns applying to the user interface as a whole, things like writing styles/icons/colors.

These Guidelines are inspired by Blender's amazing Human Interface guidelines. Thanks!

Design Paradigms

Bevy is for Teams

Bevy (and especially its Editor) is a tool for cross-disciplinary teams to work together. Each user will have their own unique strengths and weaknesses and tasks to perform.

That means:

  1. Collaboration should be pleasant.
  2. The Editor must be customizable to meet the unique needs of each user and project.
  3. Art, audio, writing and design-centric workflows should require a minimal level of technical expertise.

Group tools by task into workspaces

Tools should be grouped together into customizable workspaces to reflect the needs of common tasks: creating a level, debugging and optimizing a game, writing dialog, and so on.

It's okay for tools to be duplicated across the default workspaces if they're needed by more than one workflow!

Redundant interaction paradigms for accessibility

  1. Anything that can be done via a mouse click can be done via a hotkey.
  2. Anything that can be found in a menu can be found in the command palette.
  3. Anything that can be configured via setting a menu option can be done by editing a config file.

To be completely clear: the same should be true in the opposite directions!

Non-Overlapping

The UI should enable you to always view all relevant information and tools at any given moment, you should never have to move a window out of your way, for that reason, as well as sticking with bevy's modular structure, Bevy uses a divided window layout we call Panes.

  1. Screens; the entire window enables you to configure workspaces using multiple editors.
  2. Panes; the container of an editor. Editors can each operate similar to a stand alone editor, like for modeling, painting or scripting. Editors can both follow Screen level user context ("Active" or "Selected") and offer local context browsing.
  3. Regions; every editor allows further subdivision to provide button/menu headers, toolbars, channel views, and what more is needed to serve its functionality.

Non-Blocking

The UI should stay responsive whenever possible. Tools and interface options should not block the user from using any other parts of Bevy Editor. When long-running blocking tasks are required, it should be clearly indicated and allow an immediate exit. Users don't like their workflow being interrupted!

Non-Modal

User input should remain as consistent and predictable as possible, do not change what inputs do on the fly without clear communication.

When input behavior changes (e.g. a special camera mode that overrides normal controls), the change in behavior should be temporary, and require continuous user input (typically pressing a key or holding a click) to remain active.

Select -> Operate

In Blender you first indicate which data you work on, and then what you want to do. The same applies for Bevy. Quote from Blender's guidelines: "This follows the non-modal principle; there's no active tool mode you need to set first to be able to use the tool on what you select after. This concept enables a fast and flexible work flow."

General Patterns

  • Try to ensure that the reading direction of information: data, is carried in the same direction as the user's language.
  • Until localization is available only consider Left-to-Right, Top-to_bottom reading directions.

Editors

  • Editor views such as 3D scene/2D scene, where exact coordinates matter, should have a grid background. In a 3d context this means the "ground" plane.

Best Practices

Keep the UI calm

  • Avoid strong changes in colors, big jumps in layouts, or popping elements on simple interactions.

  • Avoid strong accent colors for no reason. Using accent colors when you aren't trying to get the user's attention only creates visual noise and clutter that harms the user experience. The UI should be calm with slight contrasts unless there's good reason to do so. Getting this right early on will do good for long term editor-user communication.

  • If the design breaks away from Bevy Editor's design practices, the reasoning should be well thought-out and documented. Inconsistency should be reserved for drawing attention to elements that work in unique or surprising ways.

Workflow Oriented

When naming tools and UI elements, focus on actions not things. Prefer verbs over nouns.

Writing Style

Common Rules

  • Bevy uses American English.
  • Text should be clear and to the point.
  • Language should be targeted at the lowest level of technical expertise needed to clearly understand an explanation.
  • Entity, component, resource, system, event and asset are the critical technical vocabulary for all Bevy users to learn, no matter what their role is.
  • Avoid contractions, abbreviations and acronyms where possible.
  • Single character identifiers, like X/Y/Z etc. are always capitalized.

UI

  • Use MLA title case for UI labels.
  • Avoid redundancy. For example do not use Enable, Activate, Is, Use, or similar words for boolean properties, just a checkbox.

Pane Layout

Order of Importance

  • More important fields and tools should be given more visual prominence. This can be achieved with positioning, size, contrast or folding elements.
  • If every setting in a sub-panel is predicated on something being enabled, the toggle should be in the header.

Enums

  • If a enum is more than 3 items, it should be a drop down.

Sub-Panels

  • When you have closely related options you should group them into a sub-panel.
  • This allows for collapsing enabling a user to minimize noise from things they aren't using.

THIS SHOULD BE IMPROVED OVER TIME

  • These layout rules are not set in stone.
  • If you have an idea for improvement, make a PR so it can be discussed.