I was collaborating with a fellow developer, and we had a prolonged discussion about how we should and should not organize the file. We both agreed that it was important to keep the file organized, so we tried to come up with a system that both met our preferences. It wasn’t easy, and it’s not perfect, but it made me realize how this is sort of critical but not often discussed.
So how do you organize your project files? What systems work for you? What systems haven’t worked for you? What is your overarching goal in the structure?
my top tree separates the different types of assets in the project, i.e. /map for tiled files, /res for runtime assets such as textures and sounds, /vendors for external dependencies (libraries, tools and such) and /src + /inc for the source code
under each of these main categories, depending on the project scope i either “namespace” the files for small/medium scale (i.e. /res/player_idle.png, /res/player_walk.png, etc.) or create subfolders for a larger scale (i.e. /res/player/idle.png, /res/player/walk.png, etc.)
i do this not only for /res but for everything to be clear
a small project can have all the player code in one file but if it grows it can be beneficial to split it in multiple files
this segmentation allows for easy readability of the tree, clean organisation in team and avoids many merge conflicts by having a standardized naming scheme
Actually I think reading this has got me thinking that file structure is less of a personal/team based choice - but kind of more fit specifically to the tools you are working with.
To me /vendors reads as a dead-ringer for a c/++ codebase (or some git submodules setup) - but of course if you were to show that to someone working with Unity that’s what they’d point out their Plugins/Asset store folder is for. Similar concept, but the naming convention is very dependent on what’s being used. Or if you’ve got a language package manager like pip or npm, it usually buries things in a /.modules that hides itself on git and you are typically expected NOT to touch the files in.
I tend to idealize around keeping things separated by filetype. Usually in my head, at the start of the project I envision little scripts that help build out hardcoded references to game assets (like graphics, maps, sfx) that I can access as an object/dictionary with “safer” typing (I basically just want to set things up so the IDE autocomplete spoonfeeds me as much as possible, even if it means creating weird abstractions like that). It can be a good way to catch errors at compile time when you accidentally move things around and need to regenerate your asset manifests, and refactor things that reference it