Hey guys, my folder structure sucks. Like it sucks hard.
I’m looking for a better approach for organizing folders.
Anyone willing to share some insight on the folder structures they’re using, ideally in a non trivial and mature project (ie: realistic pragmatic folder structures used in real projects)?
Inside Simian it’s namespace based so Simian is the root namespace and so on. Finding your way around without conflicts is then trivial.
i’m so jealous. Would you be willing to share a snapshot of some of those subfolders?
Is the rest of it as clear and well organized?
Edited: yep. Actually took several years to trim the fat to pure and calm efficiency. But it is simple. The project can be maintained like this indefinitely as well (as it is a huge project actually).
I keep third party well contained within it’s own folders. Data is for runtime data that the game will need that isn’t necessarily art, code or audio - such as scriptable objects, asset data, materials, profiles, volumes, scenes, you know… the other runtime stuff.
Temp recognises that most projects will have temp working files, and so I can just safely delete this or not ship with it, or mess with it. Every project will need a Temp folder so you may as well track it and make it official. Stuff inside temp should not have any dependencies though so make sure you keep tabs.
Keeping a project clean is a daily task, like the house or whatever, it’s just something you should never let become disorganised because you will harm project development pretty much right away.
Where do you put prefabs, etc - are those art or data?
More details! 
I’m trying to get ideas on real world stuff that works but is still clean. We must dig deeper.
Prefabs go in data of course, because they’re often instantiated. Some folders inside Data are actually special folders, that is, the editor in the background keeps an asset populated with the links to these prefabs, so that I can reach any asset I want. I didn’t want to use Unity’s addressable because it’s nowhere near production ready IMHO yet.
There is also a classic Internal folder inside Data which contains runtime stuff we will always need that artists should not be fiddling with, specific stuff the game needs and will always be present.
Basically just group by file type or purpose inside Data. It’s runtime accessible and easy for us to port to addressables or other scheme later. Data means game data.
The rules in general for organising is: if it can be made flatter, keep it flatter, don’t nest unless forced to. You will be able to recognise when you need to go deeper when it becomes a bit too hard to find a specific type inside.
So audio source files are in the Audio folder but at runtime if I have prefabs, they will be prefabs, with audio in data. The source files for that stay in audio though. Audio and Art are good candidates for separation from runtime data because they’re a surface area other teams or staff or people can touch.
Having strong rules and rationale for organising means you can build editor tooling that works with that, that can depend on certain art folders or filenames being preprocessed in a certain way or having an auto populated list of data you can access at editor, at runtime, things that just keep work less for you by way of consistency.
Oh, and if any 3rd party asset litters my root folder, it’s dead to me. Really, I’ll actually remove the asset, no matter how good it is, or how special people think their creation is… I will nuke it.
Any asset author using harcoded paths doesn’t get my support now and forever. It’s that simple, I won’t negotiate. It’s my business, my game, my project, so if they want a glowing recommendation from me… don’t dictate where things go.
Unity and asset store does NOT get to dictate how my game is laid out in the root. It all starts in the root. The moment you let asset store or anything shit on your organisation is the moment you might as well give up controlling quality in your game.
I will admit. This is exactly my experience. Broken windows and all. Once I had a bunch of 3rd party crap that forced compromises, I slowly stopped policing everything and it all went downhill from there.
I realize my answer here is very superficial – just art projects, not entire game – but maybe it can help somebody :
Kind of along the lines of you asking, “but where do prefabs go?”, in the same way when dealing with art assets I have the fbx’s which need to go along with some texture files. So, I used to try to couple fbx’s along with all the dependencies in the same place. Like a bug-out bag. But this can easily get cluttered, so I later moved to keeping things structured by file type and by pipeline phase status, and making dependency connections by name structure.
So I make my folder hierarchies before I even start the work now, in the planning phase. Since I am studying a reference and figuring out exactly how I’m going to make it, it is perfectly natural then to layout my folder structure at the same time. and settle on naming conventions. End result is, when I need to find something, rather than clicking clicking clicking I just type, "textures > working > dude > face > light brown var ; and then “fbx > working > dude > face” .
I use “working” the same as what hippocoder is calling “temp” I think. This way I keep the “delivery” folders clean. One rule about that : don’t put nothing in delivery or final untiil you are literally delivering. Once you break that rule… chaos. Pure chaos.
In some programming circles “final” is kind of a joke, because you end up with “Final_Final__3” after a while.
exactly. haha, yeah for me that is how I end up with a mess everytime. Not until recently reorganizing my project that I made it a rule: don’t touch delivery until I am literally delivering.
Anyone else have any other examples?
@hippocoder would you care to share any shots of the more dirty interior folders?
@AndersMalmgren - how about you, you have a serious and mature project, and you are obsessed with organization. You must have some serious thoughts on folder organization
Yeah, it’s a shame. This is the kind of thing I really want to read as well, more so than speculative’s about technology and whatnot. Very useful, acctionable knowledge.
Clearly I should have titled this thread “UNREAL VS UNITY FOLDER STRUCTURE” or “how to achieve photorealistic folder structures in unity” or something.
I don’t have more dirty interior folders, it just applies the same less is more logic, with “only add another folder if absolutely forced to do so”.
Well here’s mine. Pretty close to what hippo has, and I follow the same logic as hippo. If I can’t move the asset to my 3rd Party folder, then it’s removed.
Huh… Didn’t know that we can paste an image here and it gets automatically uploaded and added.
Interesting. I love the clean folder icons @Rotary-Heart .
Again, this just fills me with folder envy.
Anyone willing to show any of their namespaces in those code directories?
This is identical to my setup, aside from me calling my “3rd Party” folder the exact same thing but without the space.
It’s important to note, however, that it’s not just folder structure that’s important. With all the built in search features Unity has for finding things, clear naming conventions for things is important, like making sure you have, say, particle textures include their blending mode and whatnot in the name themselves. By doing this, you essentially get a tag search, so you can type “particle additive spark rod” and get a list of particles that are, obviously, additive, for a spark effect, and rod shaped.
I see so many packages and projects that ignore this and it’s amazing, because I can’t help but imagine it makes finding things in large projects an absolute nightmare.
I normally have a setup similar to @hippocoder except that I keep our folder with an “_” at the beginning so it appears at the top of my tree, and do the same for any subfolders I want to be at the top.
So I end up with
“_GameDevCouple”
Plugins
Resources
Scripts
Scenes
etc
Inside of “_GameDevCouple” I keep my own folders such as “scripts” “scenes” “art” etc
This is mostly so we dont have to scroll a lot in the project view as I keep my project view super tiny
That way I can seperate easily anything from asset store or github projects from my own assets and scripts. Some assets spit crap into horrible directory structures and break if you move them, so this allows them to continue doing that without it getting in the way.
We also have namespaces to ensure from within code everything is organised in terms of access.
We also prefix everything with indentifiers to make it easy to search stuff.
So a material for car 1 that is flashing would be:
mat_Car1_Flashing
Model for same car would be
model_Car1
Then it becomes easy to search for assets anywhere and know what to type to get good filtering
I’m not in the front of my game dev computer, so I can’t make a screenshot, but I can describe how I work:
I keep a “_” folder, where my stuff lives, outside of this the plugins and assets can go haywire if they want. I don’t care. And I don’t keep them in the same repo as my stuff. I keep the list of used 3rd-parties in unitypackage form sumitted in a separate repo.
Inside my _ folder I do not organize my stuff by type, because we have a great search option for types in the unity project view. I keep them organized where they belong to. I call them scenes, but they may contain more than one unity scenes. I just couldn’t come up better term for it.
For example: village scene contains village_outside, village_house_smith_inside, etc scenes…
If something is very common, I make a category for them, if I use them a lot, it goes into the common folder.
The only thing goes separate is my framework I’m working on (as needed by the higher level code), that’s goes in a traditional code-folder structure:
– <class.cs>
This framework goes into the - folder directly.
I also give meaningful filenames to assets, like jason_footstep_low_1.ogg, usually: [_].
I also have a Temp folder right in the Asset folder where I can play around with stuff without affecting my project stuff. It’s the messy part and sometimes files come and go between this temp and the project (after careful consideration).