Editor Modularity and a Plugin / Extension Framework

[alice-i-cecile]

Like most high-intensity tools, Bevy's game engine will require a high degree of customizability. The variety of games made (from visual novels to platformers to factory builders to 3D open world games) will have very distinct workflows: necessitating the addition of some niche features and rendering other features nearly obsolete.

Rather than attempting to capture every possible use case in the editor through configuration, I propose that we make extensions ("plugins" is already used for something else in Bevy) a core part of the editor's architecture, as you see in programs like VSCode. Ideally, I think it makes sense to build the editor's core functionality through these extensions as well, as you see in Factorio's mods, maintaining a single workflow to modify the editor. This encourages modularity, will help us develop the API as we build the editor, and ensure that core functionality can be interacted with, modified and toggled just as easily as other.

As I understand it, there are two proposed architectures for this:

1. Dynamic loading, likely supported by something akin to [hotpatch].
2. Interprocess communication: a small core Bevy process with an internal API, that talks to each extension which runs in a separate process.

Pros of dynamic loading

1. Ability to modify other plugins directly, changing their behavior. This is probably actually an anti-feature.
2. Better performance due to reduced overhead.
3. Doesn't require us to develop an explicit API. Probably also an anti-feature.

Pros of interprocess communication

1. Allows a proper security model.
2. Ability to write plugins in other languages.
3. Better segmentation of bugs: a panic in one extension doesn't bring down the whole editor.
4. Shared memory can help us regain performance if needed.
5. Performance is likely to be GPU or disk I/O bound, rather than CPU-bound, reducing the performance benefits of dynamic loading.
6. Better separation of concerns.
7. Doesn't break things and force recompiles every single time the ABI changes.

I think IPC is the clear winner here.

[IngmarBitter]

Bevy is using plugins already in other places where they are not implemented as a separate process. There the decision was to stay in process. Probably because we should not push solutions up to another level of complexity if a less complicated solution will do the trick.

1. Security model. Why is that needed here when it was not needed for other bevy plugins?
2. Write in other languages. Everywhere else bevy is trying hard to use native rust and native rust crates. Why deviate here?
3. Better segmentation of bugs/panics. Why handle that differently here from the rest of bevy? That definitely makes things more complicated and adds to the learning curve.
4. Dynamic loading is faster. As stated maybe not a big difference but still faster.
5. Shared memory can help regain performance. That is another step up in complexity. Not a good idea according to the KISS principle.
6. Better separation of concerns. Why is that? A separate plugin already isolates its concerns. If it is in process or out of process does not change that the semantics of the separation.
7. ABI changes cause recompiles. How often has that happened in the past? I would expect not more than once a month? Needing an extra compile at that rate is quite insignificant.

I'd vote for the most simple solution.

[cart]

There are good points on both sides here. IPC solves a lot of the problems inherent to "in-process" / dynamically linked plugins. But it also creates new problems (cpu overhead and code complexity).

I would prefer it if the Bevy Editor was just a "normal" Bevy App that uses normal Bevy Plugins. This keeps the complexity of the system low, the barrier to contribution low, and the performance high. If the current Bevy Plugin approach by itself isn't a suitable solution for editor extensions, I think it makes sense to solve that problem generically so that it can feed back into other Bevy Apps. Maybe that means adding WASM App Plugin support. Maybe it means sorting out dynamic plugin loading (which we already have partial support for ... but only when the plugin is compiled on the same machine / toolchain as the editor ... and I'm not even sure it still works).

IPC feels a bit like a "special case" solution. It might work for the Bevy Editor by exposing specific pieces of functionality, but I would feel less comfortable asking all Bevy users to solve their problems that way in their apps as it "punts" the problem to user-code.

Whatever solution we choose should follow the current "Bevy App Model" imo. Anything else feels like a compromise / forces people to rewrite things when they want them to be "dynamic".

In the early days of the editor, I think it makes sense to use "compiled in" plugins. Bevy Plugins are my ideal extension model (from an api perspective), they require no additional architectural changes, and we can start writing code now. Any future "dynamically loadeded" solution should support an interface that is as close to the current Plugins as possible (ideally identical). So if/when we need to support dynamic scenarios (and/or sandboxing), it shouldn't be a significant change to port things over.

The "compiled in" approach also encourages a "source first" approach (kind of like crates.io). This encourages open development, but it comes at the cost of making it hard to create monetized proprietary products. In the short term this is probably a good thing as the market for that is pretty small and open development means we can all learn from each other. I think its been a good thing for the crates.io ecosystem. But long term I think it makes sense to support developers that want to sell products.

[Protowalker]

Dynamic loading is inherently much more unsafe than IPC, so that's something to consider.
Personally I'm in the camp of IPC primarily because I think a standard API for editor extensions will help foster a more standardized experience

[cart]

Yeah I think well-defined / stable apis are important for the editor. But IPC isn't the only way to do that, nor is it the only way to achieve safety (ex: a semantically versioned C ABI implemented by WASM plugins)

[alice-i-cecile]

So, broadly speaking, my personal vision for the Bevy Editor is:

1. A separate crate that can be installed as a stand-alone application.
2. It uses bevy as a dependency (to handle internal logic and render a UI), then uses the inputs from the GUI to generate bevy code, which you can then inspect and modify.
3. This is more commonly used by less technical and more visual team members: folks creating scenes for a 3D world, editing levels, designing UIs, quickly iterating on mechanics, adding dialogue, working with a scripting language etc. I would expect, on larger teams, core engine development to occur within a classical IDE.
4. This functionality can be extended and modified with a large, discoverable and only-lightly-vetted collection of community-provided tools (plugins / extensions).

To me, this imposes the following constraints:

1. Installing, using and tweaking the editor should not require the end user to write Rust code, or interact directly with the Rust toolchain. This restricts our ability to use simple solutions like "make it a standard Bevy app, then add extensions by manually editing the source code".
2. If we're eventually interested in supporting a third-party ecosystem (especially with the option for closed-source, paid extensions), we need to be more thoughtful about security model. Particularly when dealing with a less savvy and more business-oriented user base if this takes off in Serious Game Studios.

The existing plugin model, as I understand it, is just simple syntactic sugar. There's no scoping, no enforcement of separation of concerns, no current way to dynamically load them etc. For game-specific logic, you often want the level of power / customizability that comes with working with raw source files, and are willing to tolerate a higher level of vetting to avoid unintended behavior of all sorts. I don't think that's the case for extensions that modify the editor itself.

[cart]

Sounds like our visions are largely aligned. The vision you've outlined above is my "long term" vision. Theres a lot of work involved to make that happen. I think its the sort of thing that we should account for in our planning, but I'm not sure it needs to be a part of the MVP/initial release. Anything with a "sandboxed / dynamic" api is by definition a "layer on top". I don't see a reason to block progress outright on it. And theres no reason to dis-allow the "code first" plugin model, especially during the prototyping phase.

[alice-i-cecile]

I fully agree with that assessment. My feelings are that we should go from "pure code first", where you're editing a fork of the bevy_editor source files to tweak the editor during the prototyping stage, then move on to a safer, layered extension framework once we're expecting to have a proper marketplace and it's usable for less technical team members.

I think that this avoids the technical debt of trying to get something fancy with dynamic loading up off the ground right away, and then lets us solidify a good API for third-party extensions to work off of once the tool has a strong base.

The only hesitancy I have with this is that we'll likely want to refactor a good chunk of the core editor's functionality to take advantage of the extensions API once it's in place, but I think that's likely a lesser evil than trying to make an ill-defined API up-front and killing prototyping speed.