#Project Structuring

22 messages · Page 1 of 1 (latest)

summer maple
#

Ive attached my current structure, im pretty confused and new to rust, is there some proper structure that i can use? how does one develope a big game with this kind of 1 file for everything logic i must be understanding it wrong..

marsh rivet
#

You would generally have many crate-level modules each consisting of submodules.

For example: you can have a module camera that is responsible for the camera movement, another module terrain, that defines structures and functions for interacting with your world, and have a submodule generator under it, that is used by the terrain module to generate the world data.

It's the same concept as using functions even if you only use them once. You don't use functions to reduce code repetition, you use functions to make your code easy to read, as instead of big blocks of code, you will have a descriptive name for what the block is doing. The block itself is somewhere else you can go to if you want to figure out how you're doing it.

As a beginner with no idea as to how your project may be structured you can start writing all the "miscellaneous" structs and systems into main.rs, which will get unwieldy fast, after which you will have an idea which structures and systems you can extract away into a module. You should also look at other projects to steal their organization ideas if you like them.

And when you have moved the code into a separate module, you can use a plugin that sets up everything necessary for the module to work.

Then, all you have to do in main (or a parent module) is app.add_plugin(TerrainPlugin::new(width, height)

summer maple
#

What i thought was using a system file that would import components and modify components accordingly

#

like a player pos x and y could be modified by lots of diffrent systems, so the logical thing would be

#

a components folder and systems folder right?

#

But i cannot untangle it with my current rust knowledge either i am understanding the rust wrong not sure

#

systems would be integrated with plugins i think? to export the system to main maybe

#

Im very lost basicaly.

vernal turtle
#

I don't have much experience with bevy but generally structuring your project around how it interacts with a framework is usually not that useful. when you're looking for code, knowing that it's related to a system or a component doesn't really narrow it down much. if you really wanted to look through components, opening up a component folder with 100 files in it isn't much better than doing Ctrl+F -> "#[derive(Component)]".

IMO just put everything in one big folder until you find what way you want it structured. especially if you're working by yourself, worrying about structure isn't that important because you'll know where any code is regardless of how structured your project is.

lethal scroll
#

It's a good idea to use plugins to group systems with similar concerns, yes - but you don't need to start out with that for now

#

Begin by separating your data (components, resources) and logic (systems, plugins)

#

Generally when it comes to file structure, you want one concern to one file - for example, handling a specific structure (a component), a group of structs (your errors), a group of systems with a similar purpose, etc...

lethal scroll
# summer maple But i cannot untangle it with my current rust knowledge either i am understandin...

Say you have a structure ```
src/
components/
echo.rs
mod.rs
test.rs
main.rs
systems.rs

And you wanted to write a system that does some work against two components in our crate, `Echo` and `Test`
Your `components/mod.rs` would look something like ```rs
pub mod echo;
pub mod test;

Alternatively something like ```rs
mod echo;
mod test;

pub use echo::;
pub use test::
;

Or however you prefer to expose these components publicly...
And near the top of `main.rs` is a `pub mod components;`
Anywhere in your crate now, such as a new system in `systems.rs` or perhaps a subdirectory, you can do ```rs
use crate::components::{Echo, Test}; // Alternatively use a wildcard!

fn some_system(query: Query<(Echo, Test)>) { .. }
#

Say you have a structure ```rs
src/
main.rs
states/
mod.rs
game.rs
main_menu.rs

Where each `game` and `main_menu` had `pub` components associated with their concerns. So long as those modules are `pub` in `states/mod.rs`, you could write a system in `game.rs` like ```rs
use super::main_menu::{Echo, Test};
#

The actual underlying file structure is less important than finding something that's easy for you to mentally track

#

And even large projects will generally start simple and grow into whatever structure works best for that project, considering the needs of its developers as it grows

#

Thankfully Rust makes refactoring these things somewhat less painful

#

The biggest thing I would try to emphasize though, is that systems are fundamentally free floating units of logic that request some data from the World and do some work on that data - they are not intrinsically tied to any one component, resource, or event, and most will end up working against multiple units of data.
So I have found that trying to structure my stuff so granularly like "one component and its related systems" ends up looking kinda like spaghetti with where I end up putting things. Meanwhile trying to use something so general as a bucket of "components" and a bucket of "systems" makes it hard to find the right thing as my project grows.

#

I personally prefer separating major concerns like states (menu, game), map, player, HUD, etc... and subdivide those as necessary - different menu/HUD elements, player's character controller, camera, actor, etc...
Where 98% of pub structs within these are components/events/resources, I usually just rs use crate::{map::*, player::*};
For example, in a different plugin concerned with camera

summer maple
#

i will re read what you said again throughly but also is mod.rs a requirement? or can i like use the file name,

lethal scroll
#

You could do either ```
states.rs
states/
game.rs
..

Or ```
states/
  mod.rs
  game.rs