Replies: 32 comments 218 replies
-
InspectorWe need an accessible way to inspect the internal state of one or more entities within a scene. This will be the primary way a user edits the individual fields of components on entities.
|
Beta Was this translation helpful? Give feedback.
-
Project Structure and MetadataIn addition to code, a Bevy project inevitably will include non-code assets and areas on disk that are reserved for intermediate artifacts.
|
Beta Was this translation helpful? Give feedback.
-
Asset PreprocessingTODO |
Beta Was this translation helpful? Give feedback.
-
Final Build CapabilityUsers should be able to press a button on the UI and have the editor run all of the asset preprocessing and optimization for a specific target and compile an optimized binary to run the game and produce a directory or compressed archive of the whole game, ready for distribution on the target platform (or as close as we can get to it). |
Beta Was this translation helpful? Give feedback.
-
Distribution and LogisticsThe editor will likely be a binary. We can ask users to compile it themselves, and that may work for programmers, but may not bode well when working in multidisciplinary teams. Eventually, we'll need to deliver a precompiled binary for the platforms the editor supports, and we will need distribution channels for getting that binary in the hands of developers.
|
Beta Was this translation helpful? Give feedback.
-
Scene View and GizmosTODO |
Beta Was this translation helpful? Give feedback.
-
ExtensibilityTODO |
Beta Was this translation helpful? Give feedback.
-
Debug ToolingTODO |
Beta Was this translation helpful? Give feedback.
-
Level EditingBeing able to quickly and easily place game assets is a common need when working on content-driven games, especially with non-programmers. However, the needs of each game are quite unique: how much should the official editor provide, and how can it be customized? Providing level editing funcitonality is also a huge tooling task in its own right, and may be best left until well after the MVP. |
Beta Was this translation helpful? Give feedback.
-
Code Editor Integration (MVP Optional)We probably are not going to be rolling our own provided code editor, but errors/warnings in the debug console could optionally support "Jump to Error" capabilities for popular editors (i.e. VSCode, Lapce, or IntelliJ). |
Beta Was this translation helpful? Give feedback.
-
Source Control Integration (MVP Optional)Allowing users to use source control from the editor via a UI can be highly beneficial when working with non-programmers. Supporting git, git LFS, SVN, Perforce, or PlasticSCM workflows from inside the editor can really help improve multidisciplinary collaboration. |
Beta Was this translation helpful? Give feedback.
-
Editor InterfaceThe editor needs a Bevy UI-based interface! Ideally, the editor will support widgets and docking. Optional for an MVP release could also be windowing such that widgets can be dragged outside the main window (even onto other monitors). |
Beta Was this translation helpful? Give feedback.
-
New Project FunctionalityThere should be a tool to create a new skeleton project very simply. https://lib.rs/crates/cargo-bavy by @TimJentzsch and other discussion in #436 should be used for inspiration. |
Beta Was this translation helpful? Give feedback.
-
Generic Node EditorI would be really nice for the editor to have a native graphical node editor that can be repurposed by multiple things (audio stuff, graphics pipeline stuff, scenes, archetypes), but that can also be used by third parties (I would LOVE to be able to build a node editor for Big Brain logic!) (this might seem like a big and post-MVP issue, but I think it touches on so many core systems that it could be treated as a building block for a lot of the other essential features mentioned above) |
Beta Was this translation helpful? Give feedback.
-
Documentation IntegrationThere should be easy links to both non-technical (i.e. game designer/general user facing) and technical (i.e. programmer facing) documentation. Unity provides a button in the header of every component that opens, in a browser, the corresponding documentation page on how to use the component (for designers), and the API reference page (for programmers). I think this is great learning experience and promotes guided experimentation, especially as the engine gets more and more complex. Ideally every version of the engine should also be shipped with a full copy of the engine API docs and book for fast local access. |
Beta Was this translation helpful? Give feedback.
-
Undo/RedoFor any interactive UIs it's really important to support undo/redo operations. To support it correctly, we need to make sure we have a framework for it in place as soon as possible to make sure every UI interaction uses it. |
Beta Was this translation helpful? Give feedback.
-
Editor LayoutThe editor is probably going to want a consistent layout in order to be both convenient to use and extensible. It would also be best if this layout is nailed from the get-go. I would vouch for a Visual Studio-like interface, in which individual windows (such as one for the inspector, one for the editor, etc) could be tiled and scaled, as well as stacked on top of each other as tabs. IIRC this is also similar to how vim's "windows" work. This layout would allow trivially adding new features while allowing users to customize the interface. This is also highly similar to how unity works iirc, but unity additionally has toolbars and such that I'm not so sure are necessary. |
Beta Was this translation helpful? Give feedback.
-
Editor-Game Interaction ModelWe need to have at least a general idea of how the game and editor processes should interact together. This should give us a good direction to lay a strong foundation. We need to answer at least the following questions:
|
Beta Was this translation helpful? Give feedback.
-
Content BrowserI think there should be a content browser that shows the folder structure and assets of the project folder. |
Beta Was this translation helpful? Give feedback.
-
The editor should remain an option, not a prerequisiteNor the initial entry point for new users. Bevy is one of the few game engines that give the freedom to think about a game as a regular program and not one big messy asset made in an editing application.
I would see it very organic to have an editor be bunch of plugins that you link into your game, you can choose the parts that you need and throw/replace features that make you sick. That should keep the project be called a "programmers game engine" which is cool and in no way making it less popular. |
Beta Was this translation helpful? Give feedback.
-
InternationalizationIt seems to me that internationalization (i18n) would be a very important part of any UI/editor. How is Bevy currently dealing with i18n? Could ICU4X be usable for Bevy? If i18n is not integrated from the beginning then it might be difficult to implement later. |
Beta Was this translation helpful? Give feedback.
-
Engine-Host-EditorThe current situation with Bevy is that it is being used as a library. Most of the extensibility issues that have been raised come down to the fact that you need a host application with EGUI and the ability to create an editor-out-of-the-box on top of it. An important issue is whether the host supports hot-reloading for plugins (which gameplay assembly can be) and how it stores data between sessions. In any case, I suggest the following scheme: The host itself is not required to be well.. "Editor" (like a level editor), it can only provide basic engine layer maintenance functionality and hook plugins, run simulation, and feedback engine state via EGUI. Maybe project-files management. The editor, in turn, can vary greatly, depending on the game you are making. Are you considering making out-of-box-editor as plugin for the host? I also strongly support the idea of unified Node-Graph-Framework, that can be base for custom graph-based needs. This is something that any modern editor need in guts. Maybe something like this?: https://github.com/setzer22/egui_node_graph |
Beta Was this translation helpful? Give feedback.
-
Provides Bevy Plugin to help developers build their own custom editorsIt is practically impossible to make editors for all kinds of games, and the best way is to provide powerful bevy plugins for developers to build their own custom editors. Includes mod editor and in-game editor. |
Beta Was this translation helpful? Give feedback.
-
Restrictions on User CodeI know the ideal is to place no restrictions on users of the editor, but don't think it is realistic to expect for anything that's possible with code-only Bevy to automatically get an awesome visual UI when you attach the editor to it. Maybe it's doable with highly reflective languages that have powerful and safe(ish) ways to introspect and edit data and sometimes even functions at runtime - but not in Rust. Not without active help from the user code itself, at least. I think an important part of the design is to determine what is reasonable to demand from user code, and what isn't. For example (I'm not necessarily saying it is! This is just to give an example!):
|
Beta Was this translation helpful? Give feedback.
-
Package ManagerHaving a graphical interface for managing packages (and by extension plugins) seems like it could be a solid requirement. Didn't see a post on it yet so thought I would put it up for discussion. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Evolutionary approach"Build libraries, not frameworks" - old programming maxim. Reading the comments here, I can see that a lot of people have different ideas about the requirements for the editor. Some people will want to heavily customize the editor for their needs, while others are more interested in a pre-built, out-of-the-box solution. This is entirely expected, I think - there's never going to be one single solution that satisfies everyone. I think that the best way to approach this is to avoid making the editor a monolith. Instead, the editor can be built incrementally from modules using a bottom-up approach. There are a few key components that will be common to everyone (more on this below). Once those components are implemented, people can start using them in their own editors even before the rest of the "official" editor is complete. Different approaches to editing can compete in the marketplace of ideas, and the best of these incorporated into the "official" editor. At the core of the editor, there are several critical pieces that provide the foundation, these include data binding, property editing, and undo / redo. These all fall within the realm of "state management". Data binding is the part of framework that allows mutations within the editor to be propagated to the live preview of the game. For mutations of entities and components, this is simple, since these properties are typically polled every frame. However, many of the assets being edited will be generators, templates or prototypes. For example, editing the properties of a particle system might not have any effect on particles that have already spawned - instead (depending on the design of the particle framework), a signal may be required to re-initialize the particle system each time the particle parameters are mutated. So the data-binding system provides a way to notify the game engine when a specific resource has been changed. It's up to the engine, then, to decide which parts of the 3d view need to be re-initialized. The data binding framework will often be coupled to an asset loading system - that is, when an object in memory is modified, the asset system will be notified that the object in memory is changed from the one on disk. However, a game may have more than one asset loader (for example, you might have one loader for large binary blobs and another for JSON-encoded game data.) These same signals also drive the "save" functionality - editing an asset in memory does not automatically update the copy on disk, nor would you want it to (artists sometimes change their minds and quit without saving, or revert to saved). Thus, we need to know when assets are "dirty" so that the save button can be enabled, and then flush the modified ones to disk. Property editing is an extensible framework for dynamically building a user-interface from the properties of a reflected struct. This needs to allow both standard built-in types, as well as custom types that are specific to a particular game. It should be possible to register plugins that handle editing of these custom types. It also needs to support nested types (arrays and structs). The reflection metadata needs to be extensible for these custom data types. For example, in an asset system, you may have resource ids that represent different loadable assets. The editor will provide a "resource chooser" ui that allows you to browse the available resources and select one. However, a resource key property might only be compatible with specific asset types - you can't store the resource key for a skinned actor model in a slot intended for an inventory item, or a terrain patch. The reflection metadata will specify this, but only the resource chooser ui knows how to interpret this reflected data. Undo / Redo is fairly simple, but needs to be done early because every other part of the system (that is, any part that is capable of mutating data) depends on it. Undo stack entries are simply a struct that has a label (so that you can display a button such as "Undo Delete") and a closure which undoes the effect of the mutation. A more advanced form allows a "coalescing key" so that many small user edits can be combined into a single undo action (there are various different approaches for this). There are probably a few other core components I haven't thought of. However, just these elements alone are enough to get people started building their own editors. |
Beta Was this translation helpful? Give feedback.
-
Evolutionary approach, V2I've learned a lot in the last month since I posted the previous item, and my thoughts on editor requirements have evolved quite a bit. This is mainly a result of working on a daily basis with bevy_ui. The general consensus seems to be that the editor will be based on bevy_ui, and that bevy_ui needs a lot of improvement before this can happen. Fair enough; however what I'd like to know is what the plans are for evolving bevy_ui, whether or not there is an active discussion / requirements gathering on this. As previously stated, I'm more interested in writing my own editor than using someone else's, but I need a good toolkit to do that. The current state of bevy_ui is much like the HTML DOM. In fact, building UIs in Bevy is not that different from building UIs on the web by manually creating DOM elements and linking them together using parent / child relationships, and then manually subscribing to events. However, no one working in the web space actually does it this way anymore, because the developer experience is horrible; The DX of working with bevy_ui is in a similar state. Building large, complex UIs in bevy_ui is extremely labor-intensive at present. The web evolved over the last 20 years through a sequence of paradigm shifts, from jQuery to Ember to React to Solid / Swift / Vue and so on. None of these innovations focused on making the DOM better, but rather building a reactive layer on top of the DOM, one which encompassed not only rendering, but event handling and state updates as well. Doing something similar in the Bevy engine seems like the obvious approach: Bevy UI nodes as they exist today become the low-level DOM nodes in this architecture, but the artist designing the UI doesn't concern themselves with objects at that level, they are working with higher, more abstract UI components. There are several competing Bevy UI frameworks that take this approach. I'm working on one, but there are others as well, and they all have some good ideas. However, none of these are in what I would call a "finished" state, and I don't think this space is mature enough yet to be able to pick a winner. At this point, I think that the best thing that we can do in the short term is to make bevy_ui be a better DOM, to make it easier to build these higher-level frameworks. That includes more options for 2d rendering (things like ninepatch images, clipping rounded corners, and so on), and event bubbling (like bevy_mod_picking does). The latter is important for making aggregate ui components that can be plugged in and re-used, because the aggregate component can handle all of the events coming from its children. Also, I think that being able to query by traits (like bevy-trait-query) is a critical building block for building large, rich component libraries - without it, you have to register two or three systems for each individual type of widget. With trait query, you can have a single system (or two) that handles bubbled events and dispatches them to the correct widget logic for state updates. I know reactivity is a hot topic, which a lot of people have asked for, but it's also a hard problem to solve in ECS and Rust. Reactive frameworks in JS depend heavily on getters / setters and |
Beta Was this translation helpful? Give feedback.
-
Accessibility (a11y)Any application in 2023 should be designed with accessibility features in mind. There's a previous comment here which mentions non-programmer artists and designers, but I mean specifically assistive technologies for people who require them — screen readers, etc. I know that Bevy has this in mind in general, which is aweome (https://bevyengine.org/news/bevy-0-10/#accesskit-integration-into-bevy-ui). I just want to make sure this support is explicit as an Editor requirement. (I know the situation isn't great on Linux. Working to improve that!) |
Beta Was this translation helpful? Give feedback.
-
Crashes, data, gaudy databases, savefiles, oh my... VCS?One of the arguments for a seperate-process architecture is crash resilience. I'm not a big fan of the approach in general, least of all as an MVP requirement, or as the only way to do things, let me talk a bit about another way to provide data safety and integrity that would also enable doing other desirable things. tl;dr: As the old adage goes, a game is a database with gaudy user interface. Let's lean into that, even more than we already do. "Crash-only software" is a funny name but an actual design principle, the gist of it is that you accept that crashes are ultimately unavoidable because even flawless software crashes when someone trips over the power cord and the only way to make sure that no data is lost is to aggressively ACID everything you care about, and for good measure replace all your shutdown procedures with sending yourself The neat part is that relational databases generally provide ACID guarantees, and we're already relational, anyway: Components are tables, Entities are foreign keys. Another thing database folks have long since figured out is migrations: This has obvious use during development where component types might be introduced, altered, or deleted. It's also important for players, breaking save files isn't exactly a thing that makes a gamedev popular. It's also what the vast majority of games do in one way or the other, even if not necessarily that formally. What I propose more concretely (arguing against my former self) is to move towards keeping component type definitions outside of Rust code, and not even in a single file listing all the component used, but as a series of database migrations, somewhat like this. The concrete types the game will use can be easily and quickly inferred by applying all schema changes one after the other, that can be done by a macro. This avoids having multiple, possibly conflicting, sources of truth. Coming back to the editor: It enables an easy way to make things more flexible before a fully generic editor supporting plugins and everything is done, by allowing editor users to stub out components themselves, say create a The game, too, not knowing (yet) what to do with that strange All of that requires (at most) infrastructure for run-time dynamic components, but it doesn't require separate processes, plugins, or generally anything that IMO would be quite out of scope for an MVP Editor. ...lastly, having infrastructure in place to ACID the ECS, things like recording game state update-by-update, then playing it back, going forwards and backwards as you like become quite easy, and that kind of thing is very useful for debugging (even though your performance might tank and your SSD might begin to smoke). Oh. As to "whether to actually use an off the shelf database for this": It's probably a good idea to throw SQLite at things like game save files and editor project files, at least in the beginning, or even as default. Engineering ACID is not exactly trivial and SQLite is going to be fast and lean enough for pretty much everyone. Specifically for the editor pijul would be a candidate: It's ACID and a VCS, making clones, rollbacks etc, very efficient (and it's written in Rust). It should be performant enough to have one patch per undo step without breaking a sweat provided bevy commits patches directly instead of having pijul do diffs to generate information bevy already has. Also it's a VCS. I know I know also not necessarily MVP territory. |
Beta Was this translation helpful? Give feedback.
-
Thus far there has been a sizable amount of ground work laid both within first and third-party crates to enable a general Bevy editor, but there hasn't been a cohesive collection of requirements to get us to an actual deliverable editor.
Each sub-thread in this discussion should be a high level and generally actionable (though not necessarily immediately so) requirement for what members of the community think are either required for a general purpose editor, or would be very nice to have. Try to keep this scoped to what a minimum viable product would have to avoid scope creeping the discussion, though large pie-in-the-sky ideas are fine too so long as there's a solid plan to get there.
Beta Was this translation helpful? Give feedback.
All reactions