Template
1
1
Fork
You've already forked sobevy
0
doomy's somewhat opinionated bevy starting template
  • Rust 100%
doomy 51db3ad2c1
Some checks failed
/ build-docs (push) Has been cancelled
cargo generate support
2025年06月13日 21:07:12 -04:00
.forgejo/workflows cargo generate support 2025年06月13日 21:07:12 -04:00
assets forgejo changes and doc updates 2025年06月12日 20:47:32 -04:00
src cargo generate support 2025年06月13日 21:07:12 -04:00
.gitignore init 2023年12月22日 07:22:11 -05:00
cargo-generate.toml cargo generate support 2025年06月13日 21:07:12 -04:00
Cargo.lock cargo generate support 2025年06月13日 21:07:12 -04:00
Cargo.toml cargo generate support 2025年06月13日 21:07:12 -04:00
Cargo.toml.template cargo generate support 2025年06月13日 21:07:12 -04:00
post-generate.rhai cargo generate support 2025年06月13日 21:07:12 -04:00
README.md cargo generate support 2025年06月13日 21:07:12 -04:00
README.md.template cargo generate support 2025年06月13日 21:07:12 -04:00

doomy's somewhat opinionated bevy template

Supports bevy v0.16. Made as I got tired of writing the boilerplate for the way I liked to structure projects.

To get started, use cargo generate and follow the prompts:

cargo generate --git https://codeberg.org/doomy/sobevy

Features

  • ron and 2d/3d assets ready to load
  • Loading states courtesy of bevy_asset_loader
  • Settings ron set up and ready for application use
  • Ready for Forgejo actions
    • Documentation building on main
  • wasm friendly
  • Scalable file structure
  • Input management ready to go with leafwing-input-manager

Structure

  • components
  • plugins (private system groups)
  • resources (and assets)

Couple of important points:

  • The project uses its own prelude. Our game types are so commonly needed that the pre-made folders are publicly exported in a prelude mod. You should use this often, because it saves a lot of trouble (use crate::prelude::*).
  • I postfix the type of thing that something is, except for components, e.g. "GameAsset", "MyResource", "AppState". Components do not follow this pattern because they are so frequently needed, and can be made obvious in systems without the additional keyword. I find Resources and States are slightly harder to intuit, even though they derive certain things. Idk. Theres some other reasons I can't articulate.
  • Most of the game logic resides in plugins. Most systems are meant to run in groups of some kind, so they're actually private functions within plugin files. The only thing that is exposed is the Plugin, which is then consumed by a PluginGroup.