Bevy's Fifth Birthday: The Editor

Hey! Rin here, I'm a contributor to Bevy and primarily help by coordinating the editor's design. Its been a little over a year since I started working on Bevy in my free time, particularly the Editor.

Following Cart’s call for Bevy contributors to make their own blog posts for Bevy's Birthday, I see it fitting for me to go over all the work that's been poured into the editor over this year by the design team and what our goals are for the editor.

Why?

Bevy is a highly modular, code first, entirely Rust based game engine. So, why an editor? The simple truth is their are aspects of game development that code is not conducive to the final product or developer experience, such as level design. The lack of an editor is a consistent push back against using Bevy, especially for artists in teams. While the code first approach of Bevy wont be replaced by the editor, instead using it to supplement the approach, its undeniable that a editor in the modern game development world is necessary.

Who am I?

I wanna start us off with a little background about myself. First, I'm not a professional programmer, nor a professional designer, nor anything you'd assume necessary for becoming an engine/editor developer. I've always had an interest in programming and web design, but I never went to a school for either programming or design. Instead, I am an Aircraft Mechanic.

I do what I do with Bevy entirely in my free time. A little over a year ago, I started diving into Rust after years of trying (and mostly failing) to learn and use Javascript/Typescript for personal projects. After a while, I heard of Bevy and decided I'd make an attempt at using it to make a small toy project, nothing special. That quickly turned into dreams of a game of magic, multiplayer, and expansive environments.

Unfortunately, I hit a wall. I couldn't make scenes from the code alone, so while my motivation was burning hot I looked around. Soon, I found the editor-dev channel in the Bevy discord. I then asked a simple question "What's the current state of editor progress among bevy?"

Next thing I knew I was coming in everyday with ideas, problems, and a drive to get something made even when we were seemingly blocked by features bevy didn't have yet, like BSN or better UI like the headless widgets. A year later we have come so much farther and I truly believe we are on the right path.

Design Philosophy

When researching for the design of the editor, and making its various widgets such as the buttons/sliders/menus, I came across Blender's design philosophy. What Blender lives by can be summed up as "Respect the user", a philosophy I feel truly resonates with Bevy both in a practical sense and a moral sense.

The philosophy has 3 core pillars:

• Non-Overlapping

  • Keep things within their bounds as much as possible.

• Non-Blocking

  • Don't block the user from other parts of the editor when doing something.

• Non-Modal

  • Things should remain consistent as possible. Don't change what a button does without clear communication.

Combining these pillars with Bevy’s design goals, we narrowed down what the editor is and isn’t.

What Bevy's Editor Isn't.

When trying to understand Bevy's goals with the Editor you first need to understand what the editor isn't.

The Editor is not a asset creation platform.

It’s not a batteries included experience offering every tool every game could need. Bevy as an open source project in its infancy is both incapable of and unwilling to reinvent the wheel for every single thing. We are not Unreal or Unity. There is no reason for Bevy to make tools for things that are better achieved by already existing tools. We aren't gonna make modeling software when Blender exists, or make a pixel art creator when dozens already do it better.

The Editor is not a replacement for a IDE.

Again we are not Unreal or Unity, we aren't going to force people to use the editor nor are we going to make you code your games from within it. One of the great decisions of Bevy is to be 100% Rust. We do not have nor ever will have a custom programming language.

The Editor is not for editing live game state.

We have a separate tool for this called the Inspector, a bevy_ui native solution in the same vein as bevy_inspector_egui. While BSN and hot reloading/hot patching will allow some level of live editing from the editor, the editor itself has no knowledge of your live game.

What Are Bevy's Goals with the Editor?

Now that you know what the Editor isn't, its time to dive into what we plan for it to be. While we have many goals and sub-goals and things we want to do and support through the editor the core tenet of the editor is "Make the hard parts of Bevy easy".

When people use Bevy the current big complaints are "too much work for simple UI", "too much work for simple scenes", "difficulty knowing where stuff is till you run your game", "slow iteration loop on tweaking scenes". As you might notice, the common thread is scenes. While BSN does a great deal to support and solve these issue there's still the underlying lack of visual control, which brings us to bevy first and most important goal of the editor.

The Editor creates/edits scenes.

In particular it edits BSN asset files. While BSN can be written by hand the editor will be the primary tool to do so.

The Editor helps visualize the higher concepts.

A struggle I and many others have is mentally reasoning about the order of our systems, observers, events. In that vein much of the research and innovation going into the editor, not involving scenes, is that of communicating these details that are hard to internalize from a code perspective.

The Editor is modular/extensible.

While the editor is minimal it is still bevy and bevy is built off the core principal of modularity/extensibility, using the same plugin system bevy uses for games/3rd party tooling/and the engine itself. You will not be constrained to the tools we make. In that same vein you can completely trash parts of the editor. Don't like the 2d scene view? you can replace it.

The Editor helps you create and manage your projects.

A visual extension of the great work of the bevy_cli team, the editor will help in using templates as well as managing both your rust tooling and projects.

The Editor Design and its Evolution

Now that we've covered the important context I can finally dive into what we've been doing this year. When I first joined the project there were already a couple mock ups and attempts going, the Bevy leadership had decided to take a hands off approach to let the community experiment via the bevy_editor_prototypes repo and it was around this time I rolled in. There are a lot of design iterations to go over so I wont be covering all of them, either cause they dead ended or because their influence on the final design didn't persist for whatever reason.

The bevy_editor_prototypes Repository

Early on the Bevy maintainers created a repo for people to experiment with. It was a fairly hands off space for the community to collaborate on experiments without the same rigors of the main repo. It was chaotic, however it has produced tangible results, both in catching bugs and adding new functionality to the main repo. Its here that our designs are slowly becoming implemented, tested, and refined. Being a space of experimentation its not something someone should be trying to use for their game, that time will come when we create the editor on the main Bevy repo.

Choosing the Layout system

The first thing I pushed for was defining our layout system, many of the mock ups were assuming a Godot like layout or a Unity layout, in my opinion we were looking too much like the already existing engines. I believe the layout system should reflect Bevy's core principal of modularity and extensibility. When I think of a truly modular layout system my mind draws back to Blender's layout system.

For those who don't know or don't use Blender. Blender uses a layout system that uses a couple rules to operate, these rules can be boiled down to:

• All panes are interchangeable within the layout

• The current pane's type is displayed via an icon in the top left of each area's header

• The area's are resized by the borders

• Areas do not overlap

• The top bar of the window holds preset layouts of the panes

• Creation and destruction of panes is done via dragging from corners

Of course many people had issues with this design, in particular the lack of clear communication on creating/destroying areas and that many people will want to work on different scenes simultaneously, such as a player model, and a environment. So we worked together to create a merge between the classical tabs style and the Blender style. This lead to the first community built editor design in a Figma doc, with the first big design coming from Iglak.

As you can see there's still a lot of influence from other engines here, I believe Godot was the primary influence.

So how did we tackle solving the issues we had with the Blender style layout? First was the multiple assets at once problem, looking around at other engines and other software in general we came across a common use of Tabs.

Similar to a web browser window's tabs these tabs take up the same area, in the initial design tabs only existed for the scene view and I personally detested tabs for the space waste that comes with them, often costing valuable vertical space, however I couldn't deny their usefulness in this case and put the space loss issue to the side for a moment. As we iterated we made tabs exist for all pane areas and a high level tabs for the whole layout so entire workflows can be expressed, similar to how blender has preset layouts.

To make things a bit easier to see I've pulled all the non layout items out of the design.

So. What really describes our layout design accurately? A bunch of web browsers inside a tiling window manager.

Styling The Editor

Once we had figured out the general layout system, it quickly became clear it was time to do the most annoying part of any design. Bike-shed the colors/fonts/rounding/etc.

Thankfully, we got some guidance from Cart about colors and fonts and the general feel/vibes Bevy should have from Alice.

We got our starting point from the Bevy website for both font and coloring. We spent a long time discussing these aspects, both from branding perspectives, accessibility perspectives, and meeting our goals.

While these colors might change overtime to fit our accessibility goals and standards I think the slight blue gray we’ve taken to with the strong blue accent has been a wonderful color combination, combined with the roundness of everything we have quite a fun take on what is often a artistically minimal design.

Once most of the team were in agreement on the styling, I did my best to work with the brilliant Talin who stepped up with their extensive UI experience to begin the task of turning the design into actual reusable widgets. This birthed the headless widgets crate as well as what we have dubbed the Feathers UI theme, and now is working to convert everything to BSN using Carts branch. I can't wait to see it finalized and utilized!

So, what was used to describe the goal? Modern, Clean, Playful, Delightful, Minimal, Noise Free. Personally I believe we've made something that fits all of that.

The Launcher

While we were waiting between mostly finishing the editor design and BSN to drop, I began researching how we can handle the complex issue of making sure the editor knows about all the components/resources/systems a project has.

Two schools of thought came from this research, make the editor as a plugin within the game's compilation and disguise it via a launcher executable or make the editor a pre-compiled binary that parses the project data and gathers everything that's needed. Seeing the issues a pre-compiled bin will have I believed the plugin method was a suitable solution and began work on the Launcher. Taking inspiration from Unity and Godot, I designed a launcher and got a few others to toss ideas in to, quickly gaining a consensus on the direction. This design targets the project management, the rust install process, and even downloading assets.

Having consensus I took it upon myself to do a prototype, though this prototype is now overdue for a rewrite to use BSN and redesign to use feathers. I used the opportunity to explore solutions for things like state management and the settings system. I am proud of the results of the work and it showed how we can learn from the simpler parts of the editor work to inform how we tackle the larger issues.

What's Next?

Now that we are entering another year for Bevy, I look forward to what the designers can do! what can we work on while other people work to implement our designs?

I believe our next steps are focusing the system ordering visualizer, I have some ideas particularly a node graph pane, just imagine those possibilities ;). And on the workflows of the editor, we haven't spent much time working on interaction details, much to Talin’s dismay, which we probably should've a little. The Inspector in its current form doesn't make use of Feathers and I would love to see it take on a style similar to the editor.

I can't wait to see what everyone comes up with this year!

P.S. This my first time writing a post like this, hope you enjoyed :)
And special thanks to Hadalade for making the cute bevy construction birds!