Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interactive Editor #72

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Interactive Editor #72

wants to merge 7 commits into from

Conversation

LeifAndersen
Copy link

@LeifAndersen LeifAndersen commented Nov 12, 2023

rfcs/72-editor.md Outdated Show resolved Hide resolved

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ";" make this really hard to read.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Outdated Show resolved Hide resolved
## Motivation

Unlike most major game engines, Bevy lacks an interactive editor. This lack has
three major downsides:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

rfcs/72-editor.md Outdated Show resolved Hide resolved
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Outdated Show resolved Hide resolved
Usage: bevy [OPTIONS] [COMMAND]

...
```
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the code block is imbalanced here.

rfcs/72-editor.md Outdated Show resolved Hide resolved
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +74 to +75
**The `bevy` command line interface is not stable. Do not use it in build
scripts!**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!**

flappers/
README.md
Cargo.toml
LICENSE-Apache2.txt
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should default to dual MIT + Apache.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. Fill out template.
  2. Add chosen license
  3. Add version control
  4. 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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed on no license by default now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cargo doesn't, but these do:

  1. Npm (Javascript) does.
  2. Raco (Racket) does.
  3. Leiningen (Clojure) does.
  4. Bevy's existing template on github

Although notably these don't:

  1. Sbt (Scala)
  2. Pkg (Julia)
  3. 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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

```

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`cargo` command.
`cargo add` command.

`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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this last sentence.


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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Use `bevy build` to build your game:

```
bevy build <target>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default should be the current platform

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the motivation here.

### 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

### 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this sentence.

* New project construction
* Asset management
* Distributable packaging
* Credential/secrets management
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO publishing can be cut from an MVP.

* CLI Interface
* Window Interface
* New project construction
* Asset management
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear what you mean here.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the parenthetical.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#62 probably related to this


### Project/System separation

1. Create two crates: `bevy_editor` and `bevy_editor_command`, the first will be
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +349 to +354
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
4. The ui should be made using bevy components.
4. The editor's UI should be made using `bevy_ui`.

The rest of this section will be a sketch out the rough implementation for each
of these features.

### Project/System separation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

rfcs/72-editor.md Outdated Show resolved Hide resolved
### Asset management

1. Template management can be done using terra.
2. Downloading static assets can be managed by reqwest.
Copy link
Member

@alice-i-cecile alice-i-cecile Nov 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not fully clear what this sentence means.

secrets.
2. For now, only for uploading to itch.io in CI builds.

### Scene/Entity manipulator (with possible component editing dispatch).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Paranthetical is unclear.


### Scene/Entity manipulator (with possible component editing dispatch).

1. Can use rfc 62 as its data model.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely needs a link.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

3. Making these features as plug-ins helps us make sure the plugin system is
appropriately powerful.

## Rationale and alternatives
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

3. Making these features as plug-ins helps us make sure the plugin system is
appropriately powerful.

## Rationale and alternatives
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Why should we use bevy_ui" is an important rationale

Copy link

@afonsolage afonsolage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

`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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +110 to +111
target/
...

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
target/
...

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think we can cut this.

Comment on lines +118 to +119
.github/
workflows/

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.github/
workflows/

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

Copy link

@Weasy666 Weasy666 Nov 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +108 to +109
tests/
...

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
tests/
...

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Use `bevy build` to build your game:

```
bevy build <target>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default should be the current platform

LeifAndersen and others added 2 commits November 12, 2023 16:46
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
@@ -0,0 +1,508 @@
# Feature Name: `editor-foundation`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

  1. 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.
  2. 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))?
  3. 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.
  4. 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).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

@cart cart Nov 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

The easiest way to get started with Bevy's editor by downloading it with Cargo:

```
$ cargo install bevy

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

@tim-blackbird tim-blackbird Dec 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

LeifAndersen and others added 4 commits November 12, 2023 19:23
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants