Why not develop without an Editor?

[johannesvollmer]

To achieve a suitable user experience, we should take the perspective of the user in a specific scenario trying to a achieve a goal (which is for example developing a game or app). This enables us to implement the features that are actually important for users.

As a first step, I think it will help to brainstorm some of the most annoying aspects of game development when done without an editor, of course from the viewpoint of the game developer. The point of this issue is to gather as much pain points as possible. I suggest that the priorization of those points should be done as a second step.

As a starting point, we can focus on the following properties of user experience:

• effectivity (can make games at all),
• efficiency (can make games quickly), and
• satisfaction (minimize annoyances, or even make it fun).

So let's go:

What are the most problematic aspects of developing games or apps without a visual Editor?

[johannesvollmer]

When placing objects in a scene, I don't like to fiddle with the x/y/z numbers

[zenMaya]

• hard for newcomers
• setting up scenes in text format without seeing immediate result
• adding components that I need in code, when I don't know their names
• setting properties of components
• lack of visual feedback
• hard for artists to interact with the game development cycle
• learning a new format of scene files

[johannesvollmer]

When debugging the game, I don't want to insert println calls but instead inspect component properties in an explorative way while the game is running

[johannesvollmer]

• hard for newcomers
• hard for artists to interact with the game development cycle

Can you elaborate on that? What exactly makes it hard? :)

[zenMaya]

hard for newcomers

newcomers don't know how to setup a cube inside code. For example in amethyst this takes ~50 lines of code, in bevy ~20, which is not ideal. We need to have a simple way to setup a basic project. We need a way to show people visual feedback when they start.

hard for artists to interact with the game development cycle

Some people in the game development cycle aren't familiar with all concepts of programming, or even need to. So they should have a way to create scenes and add assets without forcing them to learn Rust and all bevy concepts

[johannesvollmer]

With any text file, I need to lookup all the possible settings that are valid for that text file, whereas in a visual editor, I can explore all the possible settings (bonus points: no syntax errors possible)

[johannesvollmer]

setting properties of components

This is possible with the text format and does not strictly require a visual interface - how does the editor make this better?

• slider instead of digits
• checkboxes instead of booleans
• drag and drop instead of typing identifiers?
• more...?

[dejaime]

With any text file, I need to lookup all the possible settings that are valid for that text file, whereas in a visual editor, I can explore all the possible settings (bonus points: no syntax errors possible)

Some would say good code completion could solve that pretty well. Many beginners have used Monogame successfully, and I guess that proves it is possible not to have an editor. Still, I'd prefer using a visual editor for games that do not have either dead-simple or procedural level-design. I'd also rather not rely on text editor + hot-reload. With an editor, I can move my camera around freely, select one or multiple objects and move them across the map without having to know all VSCode/Vim tricks for smart selection and incrementing X position, and then not really seeing where they landed because I didn't code the camera movement controls yet. I would simply fall back to something like Tiled or Blender to author levels, but that means making and maintaining export plugins.

Ironically enough, the closest I have used to an editor for ECS game engines is the Unity Editor with Dots. The experience was so bad I gave up on most of it, using it only to place doodads and static colliders. So this presents the interesting challenge of using ECS on a visual editor.

What I miss the most when not using visual editors (most important first):

• Level editor
• UI editor
• Easily changing components and their values/parameters for quick experimentation (with or without hot-reload)
• Editor Tools scripting
• Profiling
• Asset viewer
• Debugger

[dejaime]

I was recently reminded of HIDE. It is a CastleDB editor. Might be a relevant case study.

[Foobin]

I am aware that what I am about to say may be somewhat controversial, but as someone who has just dipped their toes into bevy and rust in general, I would like to throw my two cents into the pot. The first part comes across quite negative, I'm afraid.

I really dislike game engine editors.

I have used Unity quite a bit to make small projects, and have played around in Godot. They are both very, very heavily editor driven engines. This is done out of very noble reasons I imagine, as many people who have no formal programming education struggle to make games. However, and this is what I while try to explain, these editors tend to fall short of the line. Of the following statements, I would ask you to consider which one best describes the editor driven experience of the other game engines you have used:

• The editor makes development easier
• The editor makes development faster
• The editor makes development dumber

I find, that in order to accommodate the needs of beginners, these engines have editors that for better or worse 'guess' what the typical person will make. When you take all those tools and glue them together, I have found that you typically end up with the following:

1. To create their own implementations of existing systems, the user is forced to learn how to expand the editor. This is easily the worst aspect of developing for Unity. It is full of opaque layers of abstraction that can make it really, really hard to figure out what is going on and how to get it to do something else. A good example of this is their material/shader management (including compute shaders). Vulkan and DirectX 12 give you incredibly powerful control over how memory is managed on the GPU and in the PCIe bus. Unity yanks that control away from you. But hey, this way anyone can make an asset flip first person shooter with PBR shaders and lots of bloom in under a month.

It's already difficult enough to learn how the engine works. Having to learn the ins and outs of the editor as well is annoying.

__2. It is very difficult to understand what a generic engine editor is doing or what it is capable of.__ The Unity editor is huge. It contains tools to build scenes, manage hierarchies, create, manage and preview materials, profile your game, modify component properties, animate things, create UIs, create scripted events, sculpt terrains, create particle systems, version control your source, preview your assets, control how your assets are imported.... (and lots more)_ From a programmers perspective, you spend most of your development time in Unity asking yourself whether you are doing something the 'right' way or not. From using APIs and frameworks we learn that libraries typically prescribe a best practice way of interacting them: there are rules that must be followed, configurations that must be set, etc. for them to work predictably. Does the editor already have the feature you are looking to create? If so, does it cater to your needs? If not, can you create your own? If you do have to create your own, what way are you supposed to implement it?

I think the primary issue is that editors typically don't have a strong focus. In fact I'd argue the exact opposite: engine editors typically have little to no focus whatsoever. What does a compiler do? It compiles source code into machine code. What does an image editor do? It offers tools to modify pixels on a large grid. What does a browser do? It allows you to navigate and render web pages. What does a game engine editor do? Make game development seems very vague.

There is one specific feature in Godot and Unity I would like to touch on briefly. When you place an asset such as an image or a model into the project folder, the editor automatically generates a kind of "import profile" that it uses to load it into your game. I cannot describe how unfathomably frustrating this feature is. Unity seems to apply the profile when it loads the asset, Godot seems to do it immediately on disk. Both suck. In Unity, as far as I know, it is not possible to modify an asset in code before passing it to the engine (*not possible nicely, at least. It is possible, but it involves moving away from the normal Unity workflow). In Godot, whenever you save an asset, it doesn't automatically refresh the imported ones (for instance, when you modify a model, the editor doesn't update it's children). In both cases, the only way to discern what is actually going on is to either read the source code, or play around until the black box reveals its guts.

When you build your game in Unity, what actually gets included with your game? Obviously not the editor (right?), but some things you do in the editor need to be included with the game. Stuff like those infernal import profiles (in Unity), components (fair enough), performance profiles, level data, prefabs, scripted events... It is difficult to understand what your final build actually contains. Just what exactly is being included? This is very different from application development, where I can see all my libraries, all my sources, all my resources, all my configurations. You have suddenly gone from the world of rust, where everything is very nice and explicit, to the implicit world of the editor.

3. The editor is good at making games that I don't want to make. What a scene is, according to the Unity manual:

Scenes contain the environments and menus of your game. Think of each unique Scene file as a unique level. In each Scene, you place your environments, obstacles, and decorations, essentially designing and building your game in pieces.

What a scene is, according to the Godot manual:

A scene is composed of a group of nodes organized hierarchically (in tree fashion).

For the folks who want to build games that don't have distinct levels, the 'scene' is just an annoying concept that the editor tries to force down those developers' throats (What's the point of having scenes if your game only has one?). Another example is the Unity light mapper, which only works in the editor. If you have procedural levels, it's impossible to bake them in the background at runtime (at any quality level). If you want the best graphics, it's static levels only.

---

I've spoken and ranted quite a bit (sorry Unity, I'll probably use you all the same), but if any of what I've said has resonated with you then mission accomplished. What I think the best direction for Bevy to go is to embrace the Unix Philosophy. Instead of building an enormous editor that tries to do everything, we should instead build tools that help people with different aspects of game development. We can build scene management applications, animation utilities, profilers etc., but as separate, individual projects. That way I, as the developer, can pick and choose what I want to use and (perhaps most importantly) can easily create my own substitutes, all without learning how to use some editor framework thing.

Without asking, I think that artists, level designers and would also prefer this, because they would be working with slimmer tools that are suited to the specific task at hand (such as building levels, not 'making it easier to make games'). The programmers can still work in the existing bevy/rust environment, loading the assets created by the rest of the team. For example, I could add a hotkey to reload all assets, so that my level designer colleague could immediately view his changes in the game after saving them in an external level editor. You could even add a crate to do this automatically (if the dev teams wants it).

Create one tool for the job. Nobody wants a hammer with a screwdriver at one end (unless of course you do). Instead of making development stupider, let's instead make better resources that help people learn. Good tutorials and helpful forums for example. It is okay to look a bit intimidating, as long as you give good hugs :)

[johannesvollmer]

Yes, I agree especially with Unity forcing you to obey some scene done religion even if you generate things procedurally. If you do something procedurally, you'll have troubles in Unity, not only with scene files, but with the editor in general.

It feels like in Unity, scenes are first-class citizens, and code is not anymore.

[Foobin]

I should add that I agree with @WesterWest on every point. He has given the primary reasons why people usually try to build editors. However, I think that each and every one of those problems is best solved with better tools and learning resources, not with a single editor.

[mnivoliez]

Hello, sorry for butting in out of nowhere, but I would like to add some opinion and experience (how short they may be).

I mostly agree with what @dejaime said and I would like to emphasis more about some of the points. As a game developer, when building games I want mostly two things thirst:

• setting up level
• create behaviour Those two point are essentials because I want to test quickly my mechanics. From there, a level editor becomes an essential part to prototype quickly a level and eventually even propose it to other people. For the behaviour part, while the "logic" can easily stay in code, I believe that tweaking value should still be in an editor because I do not want to recompile all everything only because my character 's jump is now 7 meter instead of 3.

All this pose the concern of components that should be interactible with in a visual manner and even be here by default. For the interaction part, it makes me think about the way Unreal Engine propose the display variables in the editor with some the macro "UProperty".

I also agree with @Foobin about not making an enormous editor. Another option could be to make a sort of app containing editor parts as plugin. Unreal is doing this a little in this way. Each part of the editor could be it's on "tool" assemble together in the same editor.

Sorry if I sound a little confusing, in short: I think an editor should answer the need express in the workflow of a game designer: making a level, create basic behaviour, tweaking value, test, rinse and repeat.

[Skareeg]

I must admit that I agree very heavily with @Foobin. One of the things I love about tinkering with projects like Amethyst and Bevy are the fact that I can create highly procedural games and apps very easily.

If an Editor is implemented, I must insist that it is optional. I don't want to have to do like I am doing in the Unreal Engine and have to create a whole Scene/Level and GameObjects to live in them through the editor. Nothing against scene graphs and editors, as many games are highly static in nature, but I would like to start with code first most of the time. Many of my favorite games and projects are built with dynamically created worlds. The pieces themselves may be static, of course, but the level is not. If the editor was split into tools that can build the individual assets out, it would give us maximal flexibility in how we design our games.

I will say that Godot's ability to "instance" scenes into an existing one essentially acts as a very powerful prefab system that I actually kinda like. So at the very least, this is something we should keep in mind if we are going to a scene based building system.

[johannesvollmer]

Yes, I have made the same experience with unity

[ygypt]

I know this is an old thread, but I'd like to step in and say that my experience with editors is very mixed.

I also dislike how Unity handles things, having spent time working on a fighting game profesionally in Unity, we had replaced nearly all of the Unity tools with custom tooling, ran our own update logic, and managed skeletons in our own code.. Unity was essentially just a graphics library by the end of development.

That being said, Godot's editor has been a very pleasant experience for me. Unlike how @Foobin seemed to imply, scenes in Godot do not necesarily represent a "scene" (single level or cutscene) like the name might imply. Scenes are just a collection of Nodes that can be instanced at any point like a prefab. This allows you to create complex objects, by composing them ahead of time. It's a fantastic editor for what Godot does, and what Godot does is object-oriented scene trees. For that, it is opinionated, but the Godot Foundation is very open about this. If you don't want to interface with a scene tree you probably shouldn't pick godot for the project.

Bevy has a unique opportunity here to create an editor that doesnt provide any functionality that you can't also get from bare rust.

It is impossible to create something as big as an editor without opinion, so it will not fit every use case, and for that reason it should be designed with beginners in mind, just as Godot is, but unlike Godot, you should still have the agency to cargo add bevy and get rollin however you want, to make your own editor even. This will create an aftermarket for unofficial editors that cater to particular use-cases, while the official one sticks to an easy-to-use general purpose use-case, which isn't something you see with the other Big 3.

I'll add one more thing, although I'm sure it's already been said before: Godot's editor is famously running on the Godot engine and made out of Godot Control nodes (UI widgets). Bevy should certainly follow suit