what is the best way to go about project file structure?

[pastel holly]

hello there, apologies if this has been answered before or if there are good resources out there.

I am having a hard time wrapping my head around the best practice for formatting my project. while I love rust/bevy and what it offers I have found a lot of conflicting answers regarding the best practice of organizing my files/modules.

I learned OOP with Java in school and so that has set my base understanding for the way you organize a project, but I feel like that is not idiomatic when creating a rust/bevy project.

what are your thoughts on the best way to go about organizing a project?
what pitfalls have you found?
etc.

thanks!

edit: wow just saw all the great answers, thanks everyone!

[wise kiln]

Basic advice is start simple, and order your modules by domain logic

Use one plugin per high-level module, and group all your related resources / systems / components together

Don't try and split things out by like components.rs and systems.rs; this way leads to madness and lots of jumping around

[real mountain]

What's also helped me is by creating bundles, then implementing systems on those bundles (or just single components). That way it's really easy to see from the plugin what the systems do. Eg:

app.add_system(PlayerMovementAction::input) // convert input to events
  .add_system(PlayerAbilityAction::input)
  .add_system(PlayerMovementAction::movement) // convert events into movement (will handle network-generated events when I add them as well)
  .add_system(Caster::update) // do other game logicy stuff
  .add_system(Health::apply_changes)

[blissful wedge]

I also learned java first in school, and one thing I would say that is different (in gamedev generally, but also in Bevy/rust) is that there is not a need to split files nearly as much. So in java I have 1 file 1 class, whereas in rust I can have a single file that's 6000 lines long. It's all based on feeling, what makes sense at the time, and when do I start to get frustrated at finding something when it's mixed together with other stuff. Often when starting I don't know what makes sense to put where but it starts to pop out at me just by noticing where I spend my time in the editor.

[sand osprey]

I've found that with VS Code its easier to split files more, then I can just Ctrl+P to get directly to the system that I want from anywhere. I've settled on a structure that breaks things up by module like Alice suggested (except I do find it better to break out the components into a separate file), and then has:

input_plugin/
  |-- systems/
  |   |-- mod.rs
  |   |-- system_x.rs
  |-- components.rs
  |-- events.rs
  |-- mod.rs  # the plugin lives in here

I just have a bunch of those plugins. I'd say experiment though and see what works for you for most of these things its easy enough to refactor unless the project is mammoth

[dreamy estuary]

note: Alice specifically recommended not splitting between components and systems like that

[sand osprey]

Yeah I saw that. I think there is a whole lot of personal preference here 🤷

My own thoughts here are that for big enough projects splitting components and systems mirrors the split of the ECS into data + operations on the data, but I think the best way is whatever works for you

[pure dagger]

This might be from a very different background, but I tend to split late, and sometimes I might split out something like “systems” or “controllers” if I have plenty of those, but don’t yet have a feeling of what the project will look like. But that means that, for me, having a file like systems.rs is a signal I could think about architecture more (but: avoid architecture astronautics 👩🏻‍🚀 - unless it’s for fun and like them, I mean, you do you).

[leaden rover]

i usually start by grouping things based on what they do (so like in a pong game all the code that handles the ball goes on one file, all the code that handles the paddles goes in another, and so on for scoring, etc.)

which also makes for nice naming bc i end up with code like

.add_system(ball::bounce)

and it's very clear what that system does and what it relates to

also when a module is multiple files there are two ways to do it

a/
- mod.rs
- b.rs
- c.rs

a.rs
a/
- b.rs
- c.rs

both of these create a module a with child modules b and c
i tend to prefer the latter method because it's a lot easier to keep track of all the files when they have distinct names (more than two mod.rs files gets a bit annoying)

[pastel holly]

thank you, this was one of my issues I faced when trying to split things this way. I’ll give the domain logic method a try, sounds promising and easy to understand as the project gets bigger 😄

[main flower]

random thought. you can see, from a system, all the components it cares about. But you can’t see, from a component, all the systems that care about it

not sure what that implies

[fickle heron]

Hey, sorry to comment on an old, resolved issue, but this is the best discussion I've seen on the topic, and I thought it'd be better than to post a new question that retreads the same ground.

Breaking up the code into logical units/plugins sounds appealing, but how do you reuse code across plugins?

For example, say I have a plugin for drones and a plugin for towers (in a tower defense game where the towers shoot the drones), and I want to use the Velocity component for the towers' bullets and the drones. Where should that go?