ECS project structure and planning

As my project grows I find the organisation of scripts gets a little messy.

I am curious how others handle ECS project structure e.g.
Are your Systems organised by Entity, Data, or something else?
Are your Systems organised by their timing within a frame?
Is there some sort of standard?

Also any recommendations on tools to help with project planning? Miro has tons of templates but none feel quite right for me so far.

The ECS best practice page has a table showing organisation by data type then System. Perhaps the standard?

 

I organize by type (components vs systems vs authoring) and then by feature. Although when it comes to personal preferences, mine tend to be unpopular, so take that with a grain of salt.

 

For me generally each feature exists in it's own assembly then broken up by Components, Systems, Authoring, Util, Simulation, etc

 

I also think that feature first is better then components, system etc and than features. It makes it easier to reuse it later or move to separate assembly or package.

 

Do you think the assemblies help compile times or is it more for the organisation benefit?

 

Yes it does help compile time if you change "top level" assembly. If assembly needs recompilation then all assemblies that reference it will need to recompile.

 

I've never done a proper test but I'd say my compile times are generally much faster than what I see people complaining about on the forums

 

I just added some, I think it does help compile times. And it revealed a rats nest of dependencies I didn't know were there.

 

That's actually one of the primary reasons I do it. It forces me to write very modular code and disallows any type of circular reference. The compile times are just an extra benefit.

I also like writing all my libraries in standalone projects with small test samples so I can quickly compile them and benchmark on different platforms very quickly (consoles etc.) This usually consists of just the feature library + my core library and that's it.

 

I generally organize my projects into packages, so that naturally forces each package to have its own group of systems, components and authoring components. When I'm not heavily relying on packages, I organize features into their own subdirectories so they can be easily packaged later if I choose.

 

Is there a way to ensure that as you are going what you are doing is package compliant? E.g. with the assembly definition you get instant feedback. E.g if you are creating a dependency you didn't notice via the Console error messages.

 

You can create assembly definitions for each subdirectory containing a pseudo-package. I sometimes do this, especially if I think I'll end up packaging it up later. I also have my namespace hierarchy generally follow my directory hierarchy.

 

I really like this idea of feature first but to what granularity do you go with this? Do you do it only for major features that are likely to be used across games or for all features in your game?

For example I have a fuel mechanic for spaceships that consists of half a dozen components and ForEach loops. It can all go in the same System file. It's a fairly small self contained feature, however I'm not likely to ever use it outside of the context of the current game.
Breaking it at this level, I'd have dozens of features like this and thus dozens of small assemblies. Don't know if that's a problem or not?

Or are you only referring to say major cross game features like pathfinding, physics, culling etc, and all game logic related to the current game still goes in the same assembly?