Bevy Editor Project Structure

[recatek]

Wanted to put these down on paper since I haven't found much discussion on this elsewhere and it seems relatively open. I think the best approach to start up with is a mashup of what cargo does and what Godot does. Note that this is primarily for use with the editor and neither prescriptive nor required for those who prefer an editor-free framework approach.

bevy.toml

• This is the project's root file. The directory with this file is the root directory of the editor project, and all other directories and asset paths, as far as the editor is concerned, are relative to this location.
• It contains the project name, project content version, general project settings (Godot uses this to configure autoloads, plugins, the splash screen, etc.) and points to an optional icon for the project to use in a future Unity Hub/Godot Project Manager type meta-browser.
• The Godot equivalent to this is the project.godot file.
• This file is checked in to version control.

.bevy/config.toml

• Contains personal user settings (themes, views, etc.) for the editor for that project.
• Works like cargo's config.toml, including having a user-level override (see https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure).
• This file is not checked in to version control.

.bevyignore

• This is .gitignore, but for bevy.
• Can be used to denote assets that will not be loaded, displayed, analyzed, or otherwise touched by the editor in its asset view.
• See BurntSushi's ignore crate.
• These files are checked in to version control.

Anything I'm missing? This seems like it would provide baseline parity with other similar engines/systems.

[recatek]

Future considerations:

• Where do we store export/build presets, for a future analogue to this screen:

Does this go in the root project config or in separate file(s)? (Prior art: JetBrains IDEs store each build config as its own file, while Godot keeps a separate but singular export_presets.cfg file.)

[Atlas16A]

We wouldnt? Thats just basic rust targets, bevy would have templates it could pull from for more complex targets like web targets. Thats essentially what the bevy_cli does already. Templates the user makes could just be saved in a global data folder and online templates can be downloaded from a repo.

[recatek]

Code builds and content builds won't always be 1:1. You might want different content builds depending on target, like a demo build that only packages/exports certain assets. How would you see that working here?

[Atlas16A]

Wouldnt content builds also have code changes? seems like thered be alot of use of features etc no matter what?

[recatek]

Not necessarily. There are a few use cases where content and code aren't 1:1. I mentioned the demo assets example (you might want to keep the same code to simplify testing). You may also want different levels of fidelity for different shipping or playtest builds (e.g. skipping a navmesh or lighting bake for iteration speed on a daily playtest build). It's also common in large teams to package an editor executable for nontechnical artists/designers to work from with various content versions as they iterate on their side of the content.

[recatek]

My suggestion for this would be an expanded approach to what Godot does. I think what we should do is, for a given data asset export/package target config, aside from any built-in configuration, you can define arbitrary string tags that are similar to feature flags. So I could define "navmesh_cheap", "no_light_bake", etc. And then the editor exposes these tags as a hashset during the export process in a way that any tools interacting with the export/packaging system can access and act from. For example:

[Giorno-Giovanna-Dio]

Not strictly required, but extremely useful when:
• Editor features depend on engine APIs
• Multiple contributors open the same project months apart
• CI or automation touches the project

Cargo does this implicitly via Cargo.lock; an editor likely needs something explicit.

hope this helped

[recatek]

I put together a proof of concept of this structure (with some tweaks post-discussion) here:

https://github.com/recatek/demo_bevy_editor_structure