#Project Organization

1 messages · Page 1 of 1 (latest)

worldly sable
#

I'm having a bit of trouble organizing my bevy projects in terms of modules. I've read over the rust docs regarding modules to try and help. But, I don't really know the most 'ergonomic' way to organize a project. For example, the example bevy game "Alien Cake Addict" has a global "Game" struct that helps systems reason about the current 'player' in the game and also the current 'Camera' as well.

Right now I have main.rs being the runner for everything. So, I want to move stuff into it's own files and what-not for better organization. If I were to move the previously mentioned 'Game' structure into it's own file how would I best do that? My current solution is to have a lib.rs which has pub mod game_structure. So my options are to either have a file called game_structure.rs which makes the Game struct public. Or to have a folder called game_structure with mod.rs under it which does the same thing as game_structure.rs. But... I'm not sure what the potential 'tradeoffs' are and what the best way to actually organize a project is.

Any opinions or examples of project structure are much appreciated. I really just want to move away from putting everything into main.rs.

heavy obsidian
#

What I tend to do is separate by concept and create plugins for those concepts. So like, physics would be under src/physics/ and that would export a PhysicsPlugin which I can add to my App in main.rs

#

So maybe for you, create a src/core/ directory where you can export "core" concepts like the Game struct and such

#

And player and camera can go in src/player and src/camera (if you're using full on modules instead of crates, you may need to combine those or include a third crate for shared types to reduce dependency cycles)

worldly sable
#

Ah placing things into plugins will help a lot with modularization. doing src/core is something I'll try out. The one thing I don't really like is getting things like use crate player::Player. It just feels kind of redundant and weird to me? Maybe it's just a naming thing that weirds me out - or it's an idiomatic piece of rust that I haven't fully gotten used to... After all I think the standard library for rust follows sort of similar conventions (like std::clone::Clone). So maybe not that weird after all

heavy obsidian
#

Yeah I don't think it's too weird haha

#

For systems, though, you can remove some of the typical redundancy:

// BEFORE
use player::player_movement;
app.add_system(player_movement);

// AFTER
app.add_system(player::movement);
#

Here, we know movement relates to the player since it's in the player module

stone kindle
worldly sable
#

Oohhh very very flat

#

I like it

#

maybe keeping a simple structure like this is best until I need something more complex

worldly sable
grand zodiac
#

You don't need a lib.rs to do mod ... statements
Your project could look like this

- src/
  - game.rs
  - main.rs
  - player.rs

Then once you've outgrown that pattern you can do something like

- src/
  - game/
    - manager.rs
    - mod.rs
  - player/
    - components.rs
    - mod.rs
    - systems.rs
  - main.rs

Finally, for larger projects (> 10K LoC) you should consider using a cargo workspace, and breaking your project up into multiple crates. Can really help compile times.

worldly sable
# grand zodiac You don't need a lib.rs to do `mod ...` statements Your project could look like ...

The rust book says to avoid using the mod.rs pattern in favor of the other pattern they use which is to instead have a file and then a directory named the same thing as the file you make. For example I have a file called core.rs and a directory called core. Under core I have all the stuff I care about like game.rs, player.rs, etc. I think for me this feels a bit better since I don't have to have any mod.rs files which would (imo) eventually take up a lot of space

#

then in lib.rs I can just say pub mod core and in main.rs I have access to everything I need

#

but I haven't experimented with cargo workspaces yet