Interactive Editor #72

LeifAndersen · 2023-11-12T19:59:19Z

rfcs/72-editor.md

alice-i-cecile · 2023-11-12T20:06:27Z

rfcs/72-editor.md

+
+1. it increases the barrier to entry for potential new developers;
+2. this forces scene designers to learn to create scenes with code; and
+3. developers must rebuild their project before seeing any changes they make.


The ";" make this really hard to read.

oops, those used to be multi-part clauses, I can change them to be independent sentences.

alice-i-cecile · 2023-11-12T20:07:07Z

rfcs/72-editor.md

+three major downsides:
+
+1. it increases the barrier to entry for potential new developers;
+2. this forces scene designers to learn to create scenes with code; and


I don't think this is the right way to frame it: it's not a learning curve problem. It's a "dramatically slower and more frustrating" problem.

this isn't a downside. Smaller projects would just use Blender (or any other editor) to create whole scenes, larger projects would need their own editor to begin with. I think some documentation efforts would solve hurdles for both, which is something that needs to be done editor or not.

alice-i-cecile · 2023-11-12T20:07:25Z

rfcs/72-editor.md

+Unlike most major game engines, Bevy lacks an interactive editor. This lack has
+three major downsides:
+
+1. it increases the barrier to entry for potential new developers;


I don't think that an editor will meaningfully improve this.

I think the point here should be to help new developers visualize the running content, something that bevy_inspector_egui already does well for instance

I think the target here should be not the coders, but art designers.
Allowing them to preview, and in the future edit the graphics in an interactive way is the way.

rfcs/72-editor.md

alice-i-cecile · 2023-11-12T20:08:29Z

rfcs/72-editor.md

+## Motivation
+
+Unlike most major game engines, Bevy lacks an interactive editor. This lack has
+three major downsides:


I think that "no good way to display visual elements like a schedule visualizer" is a key downside.

rfcs/72-editor.md

alice-i-cecile · 2023-11-12T20:10:11Z

rfcs/72-editor.md

+tools, this does require them to divert resources building those tools that they
+could have spent building the game.
+
+Bevy's plugin-heavy design poses several challenges to making a traditional


I don't think the following paragraphs in this section are helpful. The points that they're trying to make aren't clear.

rfcs/72-editor.md

alice-i-cecile · 2023-11-12T20:11:18Z

rfcs/72-editor.md

+Usage: bevy [OPTIONS] [COMMAND]
+
+...
+```


I think that the code block is imbalanced here.

rfcs/72-editor.md

alice-i-cecile · 2023-11-12T20:12:09Z

rfcs/72-editor.md

+work alongside it.
+
+Also, just like Cargo, the Bevy version used in a project does not need to match
+the version of `bevy` you have installed. You can upgrade and downgrade them


Suggested change

the version of `bevy` you have installed. You can upgrade and downgrade them

the version of the `bevy` CLI you have installed. You can upgrade and downgrade them

alice-i-cecile · 2023-11-12T20:13:29Z

rfcs/72-editor.md

+**The `bevy` command line interface is not stable. Do not use it in build
+scripts!**


Suggested change

**The `bevy` command line interface is not stable. Do not use it in build

scripts!**

**The `bevy` command line interface follows semver. Be careful when using it in build scripts!**

alice-i-cecile · 2023-11-12T20:14:18Z

rfcs/72-editor.md

+flappers/
+    README.md
+    Cargo.toml
+    LICENSE-Apache2.txt


We should default to dual MIT + Apache.

Is it a good idea to add a license file by default? The license should be explicitly defined by the owner, not by default using some tool.

I agree we shouldn't add license files in the template. I can see this turning into complaints when commits accidentally include unwanted licenses.

If you make the project creation a bit more interactive, then you could ask the user which kind of license, if any, should be added.
A bit like Rustup asks you which Rust version and modules should be installed.

Mmm...perhaps this is a bit unclear on my part. What I imagined was that licensing is separate from the template, but still provided as a (changeable) default. The process for new project construction that I'm imagining is:

Fill out template.

Add chosen license

Add version control

Add CI template

This is because the license you choose to release your project under is (imo, usually) a separate concern from which template you use to start your project. And since the cross product of all licenses and templates makes sense, they should be seperate flags.

So something like:

bevy new -l mit -l gplv2 -t cardgame my-project

I do think we should by default add a license (unless the user explicitly passes something like -l nolicense), even if its an 'all rights reserved' statement.

It should definitely not add any license by default. That is unacceptable.

Licensing a Bevy project is niche enough that I'd leave it out of bevy new entirely.
cargo new doesn't provide this functionality either.

Agreed on no license by default now.

Cargo doesn't, but these do:

Npm (Javascript) does.

Raco (Racket) does.

Leiningen (Clojure) does.

Bevy's existing template on github

Although notably these don't:

Sbt (Scala)

Pkg (Julia)

Godot

Another option is to create a LICENSE file and put text in it saying <INSERT LICENSE> as a default.

If we don't want to pick any particular license as a default, we can also just put something like <Insert License Here> as a default.

I would start without license and later on add a option to include license, because I still feel like the user should opt in for specifying the license, not the tool.

Also the vast majority of Bevy users will make closed source games, which normally is copyright, so no license by default fits the majority of use cases.

Godot, Unity and Unreal doesn't do that, and they should be our benchmark, not package managers, since Bevy is aiming to be a game editor.

alice-i-cecile · 2023-11-12T20:15:38Z

rfcs/72-editor.md

+The `editor` directory provides a sub-crate for the Bevy editor. Associating
+Bevy's editor with the project allows you to have multiple projects using
+different versions of Bevy in the same environment. The `bevy` command line tool
+delegates to this editor for any project specific actions. It also has the side


I think this last sentence would be clearer if split out into its own paragraph.

alice-i-cecile · 2023-11-12T20:16:19Z

rfcs/72-editor.md

+benefit of allowing you to more heavily tune the editor for your specific game
+while still having access to the full suite of tools Bevy provides.
+
+The final directories are for version control management and game publishing.


We should just name these directly. Easier to follow, and very useful for beginners.

alice-i-cecile · 2023-11-12T20:16:47Z

rfcs/72-editor.md

+```
+
+In general, assets come in three varieties: *code*, *data*, and *template*. Code
+assets are little more than Cargo crates, many can even be installed with the


Suggested change

assets are little more than Cargo crates, many can even be installed with the

assets are little more than Cargo crates, and many can even be installed with the

alice-i-cecile · 2023-11-12T20:16:54Z

rfcs/72-editor.md

+
+In general, assets come in three varieties: *code*, *data*, and *template*. Code
+assets are little more than Cargo crates, many can even be installed with the
+`cargo` command.


Suggested change

`cargo` command.

`cargo add` command.

alice-i-cecile · 2023-11-12T20:17:43Z

rfcs/72-editor.md

+`assets` directory. Frequently these assets are large, should not be added to
+the repository directly, or should be loaded at build time from an external
+source. Therefore, in addition to copying the assets into the project, data
+assets can also be references to an asset at an external location. **Note that


I don't understand this last sentence.

alice-i-cecile · 2023-11-12T20:18:01Z

rfcs/72-editor.md

+
+Data assets are overlaid onto the existing project, and usually go into the
+`assets` directory. Frequently these assets are large, should not be added to
+the repository directly, or should be loaded at build time from an external


I think we should consider just setting up git LFS by default?

alice-i-cecile · 2023-11-12T20:20:28Z

rfcs/72-editor.md

+Use `bevy build` to build your game:
+
+```
+bevy build <target>


I think target should be optional: the default should build for Mac / Linux / Windows. And then allow configuration of default build targets.

The default should be the current platform

What about build.rs and any sort of preprocessing/baking.
Would this be the command that does it?

As of right now it seems like a light wrapper around cargo build.
Worth noting, it should allow all of the arguments cargo build takes.
Possibly making default cargo build arguments a project configuration.

alice-i-cecile · 2023-11-12T20:21:32Z

rfcs/72-editor.md

+
+You can view all entities in your world, not just ones created with the
+manipulator. However, you are only guaranteed to be able to edit static
+entities, and entities created with the manipulator.


I don't understand the motivation here.

alice-i-cecile · 2023-11-12T20:22:10Z

rfcs/72-editor.md

+### Systems Manager
+
+In addition to the manipulator, Bevy provides developers with a view of all the
+systems their games uses. In addition to creating new systems, developers can


I don't think "add new systems from the editor" makes sense for an MVP.

alice-i-cecile · 2023-11-12T20:22:42Z

rfcs/72-editor.md

+### Localization, Accessibility, Porting, and Plugins
+
+Just like the rest of the Bevy engine, the editor can be extended using plugins.
+Some plugins are installed to the system, while others are added only to a


I don't understand this sentence.

alice-i-cecile · 2023-11-12T20:23:21Z

rfcs/72-editor.md

+* New project construction
+* Asset management
+* Distributable packaging
+* Credential/secrets management


IMO publishing can be cut from an MVP.

alice-i-cecile · 2023-11-12T20:23:35Z

rfcs/72-editor.md

+* CLI Interface
+* Window Interface
+* New project construction
+* Asset management


I don't think this is required for an MVP.

alice-i-cecile · 2023-11-12T20:23:49Z

rfcs/72-editor.md

+* Credential/secrets management
+* Scene/Entity manipulator (with possible component editing dispatch).
+* Systems list
+* Plugin architecture


It's not clear what you mean here.

alice-i-cecile · 2023-11-12T20:24:34Z

rfcs/72-editor.md

+* Distributable packaging
+* Credential/secrets management
+* Scene/Entity manipulator (with possible component editing dispatch).
+* Systems list


Wildly useful, but I'm not sure it's particularly required for an MVP. I don't think it's likely to impact architecture.

A system ordering graph would be nice, but that's post MVP, just noting it down

alice-i-cecile · 2023-11-12T20:24:50Z

rfcs/72-editor.md

+* Asset management
+* Distributable packaging
+* Credential/secrets management
+* Scene/Entity manipulator (with possible component editing dispatch).


I don't understand the parenthetical.

This should be what bevy_inspector_egui does currently, so exploration, filtering and editing component values.
By "dispatch" possibly suggesting a trait (object) with API for exposing the mutable values.
Does Bevy expose all the necessary interfaces for that or are they defined in the plugin crate?
Defining an API in Bevy would be a nice first step.

#62 probably related to this

alice-i-cecile · 2023-11-12T20:26:02Z

rfcs/72-editor.md

+
+### Project/System separation
+
+1. Create two crates: `bevy_editor` and `bevy_editor_command`, the first will be


Bikeshed: bevy_editor_command doesn't clearly explain what the crate does to me.

alice-i-cecile · 2023-11-12T20:27:10Z

rfcs/72-editor.md

+1. Simple command line argument parsing can be done with clap.
+2. Simple error handling can be provided with anyhow.
+3. There does not seem to be a standard pretty-output library for rust,
+   prettytable seems to be a start.
+   1. Options like crossterm might also fit the bill, but also seem like overkill.
+4. The manipulator/live viewing components can delegate to the window interface.


Suggested change

1. Simple command line argument parsing can be done with clap.

2. Simple error handling can be provided with anyhow.

3. There does not seem to be a standard pretty-output library for rust,

prettytable seems to be a start.

1. Options like crossterm might also fit the bill, but also seem like overkill.

4. The manipulator/live viewing components can delegate to the window interface.

1. Simple command line argument parsing can be done with `clap`.

2. Simple error handling can be provided with `anyhow`.

3. There does not seem to be a standard pretty-output library for rust,

`prettytable` seems to be a start.

1. Options like `crossterm` might also fit the bill, but also seem like overkill.

4. The manipulator/live viewing components can delegate to the window interface.

alice-i-cecile · 2023-11-12T20:27:40Z

rfcs/72-editor.md

+   by the a separate `bevy_editor` window.
+3. The `bevy_editor_command` window must seamlessly transition to the
+   `bevy_editor` window, as if opening a project.
+4. The ui should be made using bevy components.


Suggested change

4. The ui should be made using bevy components.

4. The editor's UI should be made using `bevy_ui`.

alice-i-cecile · 2023-11-12T20:28:20Z

rfcs/72-editor.md

+The rest of this section will be a sketch out the rough implementation for each
+of these features.
+
+### Project/System separation


We should probably mention that "these crates live in the bevyengine/bevy repo" somewhere in this section.

rfcs/72-editor.md

alice-i-cecile · 2023-11-12T20:28:41Z

rfcs/72-editor.md

+### Asset management
+
+1. Template management can be done using terra.
+2. Downloading static assets can be managed by reqwest.


Suggested change

2. Downloading static assets can be managed by reqwest.

2. Downloading static assets can be managed by `reqwest`.

alice-i-cecile · 2023-11-12T20:29:02Z

rfcs/72-editor.md

+
+1. Template management can be done using terra.
+2. Downloading static assets can be managed by reqwest.
+3. Downloading code assets can be done with cargo.


Suggested change

3. Downloading code assets can be done with cargo.

3. Downloading code assets can be done with `cargo`.

alice-i-cecile · 2023-11-12T20:29:10Z

rfcs/72-editor.md

+1. Template management can be done using terra.
+2. Downloading static assets can be managed by reqwest.
+3. Downloading code assets can be done with cargo.
+4. Downloading template assets can be done with libgit2.


Suggested change

4. Downloading template assets can be done with libgit2.

4. Downloading template assets can be done with `libgit2`.

Maybe gitoxide is a better fit for this, one less wrapped C library. Makes builds more predictable and stable on different platforms.

alice-i-cecile · 2023-11-12T20:29:36Z

rfcs/72-editor.md

+2. Downloading static assets can be managed by reqwest.
+3. Downloading code assets can be done with cargo.
+4. Downloading template assets can be done with libgit2.
+5. Template assets should use `directories` to store system wide.


Not fully clear what this sentence means.

alice-i-cecile · 2023-11-12T20:30:01Z

rfcs/72-editor.md

+   secrets.
+2. For now, only for uploading to itch.io in CI builds.
+
+### Scene/Entity manipulator (with possible component editing dispatch).


Paranthetical is unclear.

alice-i-cecile · 2023-11-12T20:30:09Z

rfcs/72-editor.md

+
+### Scene/Entity manipulator (with possible component editing dispatch).
+
+1. Can use rfc 62 as its data model.


Definitely needs a link.

alice-i-cecile · 2023-11-12T20:30:45Z

rfcs/72-editor.md

+      component types.
+4. The scene viewer should place all objects in a scene at their initial
+   position.
+5. A play button lets users run any given scene with the world's systems.


This is a major feature: I would like to see this split out into its own section.

Would this require defining how states and scenes are bound together?

alice-i-cecile · 2023-11-12T20:32:44Z

rfcs/72-editor.md

+2. Implementing most of these features can go faster when it assumes the other
+   features are build along side it. For example, the metadata used for the
+   entity manipulator can also be used for systems browser.
+3. Making these features as plug-ins helps us make sure the plugin system is


Generally speaking, there's some ambiguity between "plugins in the sense of the Plugin trait" and "plugins in the sense of editor extensions". Unless these are intended to be strictly equivalent (which should be clarified), we should pick a different name.

alice-i-cecile · 2023-11-12T20:33:40Z

rfcs/72-editor.md

+3. Making these features as plug-ins helps us make sure the plugin system is
+   appropriately powerful.
+
+## Rationale and alternatives


I think that each of these questions should get their own subsection with FAQ style headings. Currently, they're a bit too terse to properly understand.

alice-i-cecile · 2023-11-12T20:33:58Z

rfcs/72-editor.md

+3. Making these features as plug-ins helps us make sure the plugin system is
+   appropriately powerful.
+
+## Rationale and alternatives


"Why should we use bevy_ui" is an important rationale

afonsolage

I did a first pass and overall it seems to be focusing more on Bevy Editor command line aspect than visual Bevy Editor itself.

While I agree with most of the features here, it still require users to know and feel comfortable with command line tools (which most designers aren't).

So this RFC should focus on bevy command line tool or expand and give more details on visual editor itself, which can become pretty huge and conflict with others non-approved RFCs

afonsolage · 2023-11-12T20:50:39Z

rfcs/72-editor.md

+`bevy` tool.
+
+Bevy's editor can be used graphically, or as a command line tool. This document
+covers the command line usage, but running `bevy edit` in a project will open


I do believe just running bevy show default to open the editor, just like most programs does. If some argument is given, then bevy acts a normal command line tool.

When you use vscode, godot, helix, blender and many more apps, the default, no argument, behavior is to open the editor itself.

IMO running bevy should open the editor with no selected project. bevy edit opens the project in the current folder.

afonsolage · 2023-11-12T20:51:28Z

rfcs/72-editor.md

+flappers/
+    README.md
+    Cargo.toml
+    LICENSE-Apache2.txt


Is it a good idea to add a license file by default? The license should be explicitly defined by the owner, not by default using some tool.

afonsolage · 2023-11-12T20:52:10Z

rfcs/72-editor.md

+    target/
+        ...


Suggested change

target/

...

Target folder is added by cargo when building, Bevy should do this.

Yeah, I think we can cut this.

afonsolage · 2023-11-12T20:52:41Z

rfcs/72-editor.md

+    .github/
+        workflows/


Suggested change

.github/

workflows/

I don't think we should add something specific to github by default.

We could make that part of one of the templates. Then the user can get a default workflow for their CI, if a template for that exists.

See: #72 (comment)

afonsolage · 2023-11-12T20:54:50Z

rfcs/72-editor.md

+    tests/
+        ...


Suggested change

tests/

...

We shouldn't bother the user with this folder, it is used for integration tests, most users won't touch it.

Shrug, this seems like a thing that is decided by the template, not this tool. Although we can debate about if it should be in the default template, I could go either way.

afonsolage · 2023-11-12T20:58:50Z

rfcs/72-editor.md

+Use `bevy build` to build your game:
+
+```
+bevy build <target>


The default should be the current platform

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

cart · 2023-11-12T21:54:17Z

rfcs/72-editor.md

@@ -0,0 +1,508 @@
+# Feature Name: `editor-foundation`


First: I'm stoked that you're thinking about these things and there are a lot of good ideas here!

As a general comment, I think this RFC bites off more complexity than it should, in too many disparate areas, in not enough detail. So many of these things will be dictated by details that haven't yet been established. It feels like putting the cart before the horse. I think each of these categories deserves one or more RFCs, and each RFC should cover more details and more "design thoughts / justifications". I think the path forward is picking one of these areas that interests you, diving deep, and driving the scenario to completion. Another path forward is to omit any prescriptive details and we have an RFC whose purpose is just "agreeing on a small core list of things that need to be done for an editor MVP", but thats not really our design bottleneck right now. We need to sort out what specific scenarios look like.

Default Project Structure: this will largely be determined by the editor data model (which has not yet been established). If we roll with hot-reloading / dynamic linking, that will require a very different project structure than statically referencing. This deserves its own RFC, and should be covered only after contending with these details.

Bevy Assets: This definitely deserves to be broken into one or more RFC design that (together) cover in detail the end-to-end "asset repository" scenario. What will a repository "be" functionally (what protocol will it speak)? What will the manifest format look like and how will it be consumed (aka what is an asset)? "Code assets" will need to play into the Default Project Structure scenario (either cover this after (1), or make sure it covers the range of possible paths). Where will "downloaded code asset" code go? How will it be built? Do we distinguish between editor plugins, app plugins, and libraries? Is adding assets repeatable? Are users allowed to edit them? Are they stored adjacent to user assets (also plays into (1))?

Bevy Build: Introducing a separate build command has massive implications for how people develop games in Bevy (lots of pros and lots of cons). This deserves way more than a couple of lines, both to describe what it does internally, why it does it that way, and plenty of rationale justifying its existence relative to cargo. One of the justifications for it is "bundling with all needed assets" (which I do agree with). But there are a ton of details there that have not yet been established. Will this be used for "dev" scenarios or just "final deployments"? If it is used for dev scenarios, will it try to avoid "re-doing" work (ex: copying expensive folders, rebuilding assets). Bevy Asset V2 doesn't yet have a CLI (but it will). How will this command relate to it? Do we need both apis? Why? One major justification for a separate build command is automatic cargo feature management. That deserves coverage and mentioning.

Scene and Entity Manipulator: We need something shaped roughly like this, but this deserves way more coverage than it is given before we can decide on what these systems are and how they relate to each other (ex: what is editable and when).

Another path forward is to omit any prescriptive details and we have an RFC whose purpose is just "agreeing on a small core list of things that need to be done for an editor MVP",

That's much closer to what I was going for.

but thats not really our design bottleneck right now. We need to sort out what specific scenarios look like.

Ah, I see.

By scenarios, do you mean user stories?

That's much closer to what I was going for.

I'm happy to roll with this path, but I'm relatively certain that as soon as we eliminate the "design details" we will trivially be in consensus. Ex: "yes we definitely want a bevy cli, an asset repo, a visual editor with a scene editor and entity inspector, a standard project structure, and plugin support". I think our time is probably better spent discussing what each of these things looks like in detail.

By scenarios, do you mean user stories?

Kind of. From my perspective, "scenario" is a nebulous term that applies to either user stories or "feature areas". In this case, I used "scenario" to mean "specific implementable feature areas" like "bevy asset repos", "default project structure", "bevy build", "scene and entity manipulator", etc. "User stories" can cross cut through many of these "scenarios".

tim-blackbird · 2023-11-12T22:35:22Z

rfcs/72-editor.md

+The easiest way to get started with Bevy's editor by downloading it with Cargo:
+
+```
+$ cargo install bevy


Using bevy here is not possible because the bevy crate already exists.

Suggested change

$ cargo install bevy

$ cargo install bevy_cli

The actual binary being named bevy is good though :)

Crates.io seems to let you have a binary and library crate have the same name. For example I just tested:

https://crates.io/crates/leiftestlibbinsplit

You can run cargo install leiftestlibbinsplit and run the executable and it runs just fine. And you can also make a new project and run cargo add leiftestlibbinsplit, and now you can use leiftestlibbinsplit::* in your project.

Am I missing something?

Sorry for the late reply and not being more specific.
It's possible to have a library and binary in the same crate but I don't think that's an option for Bevy. It would require syncing the release of a new version of Bevy's cli to a release of Bevy as a whole. We technically could do this but I figure this will cause us trouble sooner or later, particularly with breaking changes/semver.

In any case I don't think having 2 things with the same name is good. This will create unnecessary confusion.

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

djeedai · 2023-12-24T13:48:14Z

rfcs/72-editor.md

+code goes in the `src` directory, likewise tests go in `tests`. Project builds
+go into the `target` directory.
+
+The `editor` directory provides a sub-crate for the Bevy editor. Associating


I don't understand this entire paragraph, sorry. What does associating mean here, how is that related with Bevy versions, and why is there a crate involved? I'm clueless. 🤔

Initial draft for editor rfc

de6ee87