Best practices - Folder structure

Hi

Is there any best practices for sorting assets in folders in Unity?

Have been doing something like this:

Assets

+Scenes

+Common

+Materials
+Textures
+Objects​

+Scene01

+Materials
+Textures
+Objects
Scene01.unity​

+Scene02
...
​

How do you structure your assets?


Cheers,
Tobias

 

Whatever works for you and the project is the best. I don't use the same structure for everything.

--Eric

 

I try to make sure that whatever I do is as malleable as possible, so as the project expands, I can reorganize if necessary. Unfortunately, Unity isn't the only environment that needs to be managed. For me, I have a bunch of Blender files that require links to assets, also. It's a huge pain in the bee-hind to have to worry about this and I'd love for someone to give me a solution; I can move assets in Unity, or I can move them in Blender, but either way, everything will break. (I am sure there are other cases like this, but Blender is the only one for me currently.) Blender-aid helps but I think a web interface is a terrible idea, and last time I used it, anyway, it couldn't even see .psd files.

 

In general there are two main approaches to organize assets: by type or by relevance.

First option works good with small projects, second one is better for huge games, also you can combine and get something in middle, e.g. our team is working on a MMO, folder layout we use looks like:



More about how our team organize assets you can read in our blog: http://developers.nravo.com/mastering-unity-project-folder-structure-level-2-assets-organization/

 

If n people reply to this thread, you're going to get at least n+1 different answers. ;-)

There's a useful folder structure in http://devmag.org.za/2012/07/12/50-tips-for-working-with-unity-best-practices/, but I think it works better for smaller projects.

Here's my input:

I always keep my project-specific files in a single folder (e.g., Assets/Project) and let the rest of the Assets folder be a wild jungle of third-party products from the Asset Store. If you move all your third-party products to a subfolder (e.g., Assets/Plugins), it still often breaks some of them, so I prefer to leave them where the developers put them.

In Assets/Project, I organize by relevance. This allows for easier division of labor in a team.

 

This is interesting and I'm hoping that a lot more people will post their conventions

I've been working on my project for a little over 18 months now and I've restructured my folders three times, I think.

• First I tried something very similar to the OP, one folder per scene (for scene-specific assets) and one "Global" folder (and subfolders for models, scripts, sounds and so on), but this didn't work out so well (lots of scrolling in the tree when assigning scripts).
• Next I tried it with category folders on the root level ("Enemies", "Player", "CutScenes", "Items", "Buildings") but that didn't help any
• Finally, I settled on having 5 root-level folders containing one nested category folder under which I sort for asset type (because this optimized my workflow: when I'm coding, I usually only look at code files, when I'm modeling, I only look at models, and so on)

I've now got 5 root-level folders, ("External" for 3rd party components, "Framework" for things not specific to one game, "Game" for things tailored to the game, "Scenes" for scenes and "Resources" is Unity's special runtime-loaded resources folder).

Beneath these, I one folder per category (eg. "Actors" are active things like enemies, cars, etc.) which by convention contain nested folders named "Code", "Models", "Sounds", "Editor" and/or "Prefabs"

​

 

Since this thread got revived, I'll reiterate my experiences having worked on dozens more projects with several groups since my last post.

• Don't move third-party Asset Store products. Leave them in their original import locations. Some of them still expect to run in hard-coded paths. Also, if you update a package that contains new files, the new files will be imported into the original import location, which makes a mess. Finally, if you're collaborating, team members will have a better idea of where to find things if you leave them in their original locations.
  • The only exception is moving code-heavy products into Plugins to optimize compile times. But mind the caveats above when doing this.
• Organize your own assets (code, textures, models, etc.) under a single folder. I prefer "__Project" because the underscore makes it sort to the top of the folder list. Or maybe two folders, "__Project" and "__Framework" (or "__Game" and "__Common"), if you also have a common framework that you share among projects. You might even name the common framework folder "__ReadOnly" or "__DoNotEdit" to remind people not to edit the contents since you probably want to edit the original files in your common framework project, not the copies in your active project. (I use two underscores because some third party assets use folder names with one underscore. This helps ensure that my project folders sort to the top.)
  
• Inside "_Project", organize folders to maximize your team's workflow. Art assets tend to be the problem area since there are usually so many files.
  • If your game is divided into sections (e.g., levels) with distinct sets of art, consider folders for each section (e.g, Mushroom Kingdom, Sewers, Dracula's Castle, etc.). When your artists are working on the Sewers section, they can quickly find everything the Sewers folder structure without having to dig through Mushroom Kingdom and Dracula's Castle assets.
    
  • If your game reuses most of its art across levels, consider folders for each function instead: Scenes, ParticleEffects, Characters, etc.
  • I've found that it works best to group all assets related to an entity in a single folder. So, for example, you might have a "Dragon" folder with subfolders for Dragon-specific textures, models, animation, particle effects, and audio clips. If an artist is going to be working on the Dragon, he or she will probably be touching most or all of these in the same work session.
    
  • The goal is to establish a folder structure that allows artists to find assets easily and avoid messing with assets that they're not currently working on.
• For really big endeavors, like an MMO or a full length content-heavy game, use multiple Unity projects. That's a topic unto itself, and there are threads on the forum about it.

 

Hah! Yep, I use "_Game" for my actual implementation. Then, all third party assets go wherever they go. If they don't go in a single folder, shame on them. I actually repackage those so that they are contained in their own folder.

My tree goes like this:

_common
_game

Animation
Editor
Prefabs

<game specific subfolder hierarchy>​

Resources

<game specific subfolder hierarchy>​

Scenes
Scripts

<game specific subfolder hierarchy>​

UI

atlas
images
fonts
prefabs​

<third party>
<third party>
<third party>
...

"_common" is actually a symlink to my UnityCommon folder that contains all scripts that I write and share between all my projects, like utility code.

 

I've just started thinking about this and naturally organised by feature/theme rather than by scene or base-type.
Obviously there's some re-use across objects, so it's not all great. But I tend to think in terms of 'features' or clumps of features, and want to see the entire makeup of an object in one view without hunting. Does anyone get into a pickle with this type of layout? I can imagine if you just want a list of all prefabs, it's a little annoying.

Planets

Textures
Prefabs
Mats
ParticleEffects
Scripts​

Spaceships

SpaceshipA

as above​

SpaceshipB

as above​

Asteroids

ditto..​

 

I find this thread pretty interesting... the concept of organizing information, efficiency access to files you need, and the accumulation of wasted time doing mundane tasks like squinting your eyes looking for which folder has which file in it (which would be accurately classified as an inefficiency in gamedev which could cost you many work hours over time).

This is important IMO, because GameDev is an extremely lengthy & complicated process. This means that what most people will see as irrelevant (spending a few seconds to sort through files or folders) is in reality minutes which add up thousands of times over the years - which means hours. At least in theory, anyway.

Furthermore I absolutely hate posts like "It depends!" - entirely dismissive posts with absolutely no content. They are equivalent to spam posts "askjedhasgkdfhweiujsfhnweijfn" and are IMO an unintelligent cop-out for someone who doesn't actually want to think or doesn't grasp this isn't simply subjective.

We're not asking "What is your favorite color?" or "What food tastes the best?" Nope. We're talking about organizing information. This is something those of us in the field of Psychology actually study. Our brains handle information in a very human way (i.e. the same way). For example we are programmed to identify simple icons much more quickly & accurately than a huge wall of jumbled text (tons of folders/subfolders/file-names which all blend together to be "some text" which you must squint your eyes, go into detail, and figure out with tangible effort "Where is that file I need?"

Search functions of varying complexity, tag systems (like those used in Unity Answers to organize Questions), and alternative visual representation of language are all tangible methods - and often superior methods at that.

It is not someone's "Opinion" that you should use the search function to find a file by a specific name when you don't know its location. It's not an opinion or "taste" that easily identifiable icons are a better idea than text when you need to identify symbols. Having different colors for different icons, like with Rainbow Folders, is factually superior than not having it. You could prove in a study that this actually improves how quickly a user can identify folders/files.


Even Art is not always subjective. Color Theory is mostly about what actually looks good. It's not an "Opinion" that specific colors on the spectrum are considered complimentary colors. If you think that's an "Opinion" then you will produce bad or mediocre art at best. Those who know this stuff to be fact (within understanding of said theory) produce superior art. That's actually a thing. For example Realism isn't subjective. You don't attempt to recreate what you see in real life, and have people "with different taste" who think it looks just as real. For example, If you draw a stick figure and claim it's photorealism, you are just plain wrong. Another great example is coding conventions / standards - they exist for a reason. Readability is very important. In fact it is often more important than performance.

There are tangible ways to measure quality of a lot of "subjective" things. And organization of information is the least subjective compared to something like art (which as I stated, is not always subjective.)

If we weren't so intellectually lazy and unmotivated to find better solutions, we could actually have solid advancement about best practices, organization, and user interfaces. (For example if you know anything of Bethesda, their content developers use the Creation Kit. I feel very sorry for them; it is a horrible application. So incredibly disappointing that so little effort is put into making a better interface. I would not work for such a company; all that money, and so little care for their employee's sanity.)

 

I find the traditional method of Folder--->Subfolder--->Filename to be a bit inefficient.

I'd be much more interested in a search function, maybe using tags, or perhaps verbal communication to find specific files & a learning AI which gets used to your personal method of organization/thinking/language.

"Open Orc's Animation Set" or "Open Orc's Walking Animation" or "Show me every file related to the Orc." or "Sort files by recently added; show only animations".

No need for folders at all in such a system. I have no idea how it would work out... but I'm much more interested in using Icons, Colors, and intelligent functions (i.e. search) than a traditional folder hierarchy.

In fact I don't really use Windows Explorer. I use "Everything" - an application which searches with instant results. When required, I copy/paste in a directory & search for file. For example to find screenshots for a specific game, "C:\Users\Administrator\MyDocuments\Game42\" + *.png

But at least it has "Quick Access". Unity (default) doesn't even have such a thing, even though it's superior to not having it.

"EVERYTHING" is such an amazing application - it has probably saved me hours of times & frustration. Always so easy to find anything in an instant. Perhaps this (and a few other features) should replace Windows Explorer entirely. I am not a fan of the current Folder system used to organize thousands of files & apps.


Your brain already knows "I am looking for an image" or "I am looking for a script" so when you go to browse your project (harddrive) you shouldn't be seeing anything else. But typical methods for this type of thing is extremely inefficiency. There's no quick access to instantly pick "Images only" with a single button. You often have to type this out in something akin to a command line.

 

From the top of my head and after reading this thread, I came up with 2 BASE models (there might be slight variations for each individual) :

Organizing assets by type of asset (script, animation, sound...):

Pros:
* Keeps things better in perspective (subjective)
Cons:
* Searching for individual components that relate to that object might require additional clicks (locking inspector for a prefab and looking for the material/script etc.)

Let there X be:
Enemies
Player

Animation
X
Materials
X
Models
X
Prefabs
X
Scripts
X
Sounds
X
Textures
X

Organizing assets by type of object (enemy, tree, player...):

Pros:
* More natural way of representing assets (subjective)
Cons:
* Will clutter the browser with a lot of folders once you expand it for an object (subjective)
* Doesn't help with shared Assets across objects (what happens if you have a non-duplicable asset like a script?)
* Scatters the assets (subjective)

Let there X be:
Animation
Materials
...
Textures

Enemies
X
Player
X



Organizing by scene usage wouldn't be ideal for projects that:
A) Would not require unique objects for each scene
B) Even if it did require unique objects per scene, you would still have to use one of the two methods above to organize them in the scene folder. This is a derived method.

If you have any suggestions/additions to this, reply

 

The problem is that in gamedev, assets often have multiple uses.

For example there may be a single animation set for "Characters" who all share the same rig, but different meshes & textures for each various of a character (ex. Race/Class)

This is one reason why a folder system just doesn't work. Something close to a tag system would be better, as a single file could then be in multiple locations at once (I'm not sure if Unity supports shortcuts in the Project tab; and that is cumbersome when adding/moving files).

What I do find useful is having Assets (textures, meshes, animations, etc.) separate from Prefabs.

Prefabs are what you actually use in games. Their components can be easily found by clicking in the prefab's inspector.

So within the limits of a folder/subfolder system, you'd probably want to do something like...


Assets/Resources/
.../Textures
.../Animations
.../Meshes
.../Etc


And for Prefabs (things you actually use in the game)

Assets/Prefabs/
.../Characters/NPC
.../Characters/Player
.../Characters/Animals
.../Environment/Trees
.../Environment/Foliage
.../Etc/Etc


By having Prefabs completely separated from actual game files (art) and game logic (scripts) you can more quickly access what actually matters: Content.

In that regard, you could organize by when you actually use something.

"Creation" folder for Resources that are used to build the content for the game (Art, Music).
"Content" for files that are used to make the actual game (Prefabs, Scripts)

And stick to some standard where you use a Prefab to handle things rather than going directly to Resources.Load(). This way content creators (even if the same person as artist & programmer; you) don't have to mess with art or scripts- they just deal with Prefabs (content). If they want to assign different music, then they change the music variable on a Prefab, in the Inspector.

I guess this would then be organized by "Profession"

Programmer ---> Scripts
Artist ---> Textures
Artist ---> Music
Artist ---> Animation
Designer ---> Prefabs
Designer ---> Scenes


This is not ideal though.

While I feel this handles art assets very well (I only have Textures, Animations, Animators, and Audio - and once I make the prefabs I never need to mess with this stuff ever again)...

It is still a Pain to sift through Scripts, Prefabs, etc. Rainbow Folders help, but the icons in the project tab are way too small.

 

I'd be interested in a new project tab entirely. While Rainbow Folders changes the project tab, it doesn't do enough. The icons are too small to make any big impact, and the number of colors is too limited. You still have to mostly rely on text - which just takes too much time for the human brain to parse. You have to identify it as text, stop to read the text, and then think about what you read. This is way too many steps. With big, obvious icons, you simply identify the icon. "Tree Icon = Trees. I need to click that." Easy.

Text are also just icons (symbols) but they all look identical; same colors; same style; and way too abtract. The word "Tree" doesn't look like a Tree. It looks like a bunch of nonsense our brains have to figure out based on our language.

 

Yeah, sometimes the sheer quantity of folders i have to get through to get to where I want is too much, making me stop and think everytime I go to the next folder...

I wish there was a solution to read your mind and point you where you want to be at. There was a Mind Field episode from VSauce where they had a machine that could guess what you will do even your conscious self even knew! I thought that was amazing! Imagine being pointed to the right asset even before you consciously knew!

Here's the excerpt from the episode in question:

 

I also like using labels instead of some impossible to follow folder schemes. Folders named after the type of its content is rather unhelpful. It needs a theme or scene or creator reference etc. which can all be defined by multiple label conventions.

 

That immediately made me think of what Pengocat just wrote:

@CarterG81 - Have you experimented with using asset labels? There's also no reason why you can't use asset labels in addition to a reasonable folder structure.

I think I provided reasonable rationales for the folder structures in my previous post, but I kind of only hinted at one that became important in a project recently. The developer has a project that had grown so large that they wanted to split it into multiple smaller projects, similar to the solution described in Schell Games' Unite presentation. If the assets were sprinkled throughout the project, it would have been more challenging to reliably extricate them into their new, smaller projects.

 

Thank you; I was entirely unaware of asset labels. This is awesome!

 

Off topic, but relevant to why I posted here.

@Raresh Looks like your Unity answers question relative to this was deleted entirely.

The power user involved probably didn't like the fact I pointed out the links of "duplicate posts" he posted had absolutely nothing to do with the answer he closed. They weren't even close to the same topic...it made no sense. Perplexing...like he didn't even read what he was copy/pasting. Maybe he was drunk? lol

Would be nice if we had a better system over there to remove actual duplicates. It's a bit of a mess there.

 

There isn't "a mod" on Unity Answers, or any mods, just users. Anyone with sufficient karma can edit/delete/etc.

--Eric

 

Ah, that makes a whole lot more sense then

Are they just seriously understaffed? StackExchange has tons of newbs spamming duplicates every day, but they clean up extremely well. Unity Answers is just.... bleh... so many duplicates... so unorganized... so chaotic. (Unlike what one user stated, it is not the users. All sites have newbies, ppl who dont read rules, etc. Idk what the problem is - maybe understaffed "mods" / no mods?)

 

It's not being understaffed; that's the structure of StackOverflow-like sites, where there isn't really staff as such. It's up to the users how much time/effort they want to put into cleanup etc.

--Eric

 

Power users, mods, paid staff; that's all just semantics. If there aren't enough people to cleanup, I'd call that understaffed. It's a problem for Unity Answers, not for me, not for StackOverflow - just for Unity. And users will be driven away from answering questions when all they ever see are the same thing over & over.

 

There is a third way that is an extension of the second one you mentioned but without the following drawback:
* Will clutter the browser with a lot of folders once you expand it for an object (subjective)

You just need to add prefixes to filenames, which will stand for their types.
Example:

You can read about more about this approach more there:
https://github.com/Allar/ue4-style-guide
But for Unity you probably will need to create your own style.
Something like this:

Spoiler: Naming Style

Prefixes:
SM_ Static Mesh
SK_ Skeletal Mesh
P_ Prefab
PS_ Particle System
M_ Material
PM_ Physical Material
T_ Texture
A_ Audio Clip
AM_ Audio Mixer
S_ Scene
SP_ Sprite
F_ Font
SH_ Shader

Suffixes:
_BC Albedo (Base Color)
_BC_O Albedo + Opacity
_MT Metallic
_MT_G Metallic + Smoothness (Glossiness)
_S Specular
_S_G Specular + Smoothness (Glossiness)
_R Roughness
_N Normal
_DP Displacement
_AO Occlusion
_H Height Map
_FM Flow Map
_L Light Map (fake)
_M Mask

Albedo texture:
RGB = Albedo
A = Opacity

Occlusion texture:
G = Occlusion

 

I have been scratching my head for few days on this now. As my project got larger and larger I was beginning to lose it with the project structure. I hate having too deep of folder structures, just makes things messy and hard to find.

On top of all this I recently implemented perforce (on top of versioning, it helps me keep project parts separate, coding, content creation, resources processing). So, with simple/easy to manage in mind, it was really time to restructure my project since I am still in the early part of the development.

Thanks to what people on this forum said, especially @OSMET and @CarterG81 , this (see screenshot) is the simplest and most practical structure I was able to come up with. I will probably be unhappy with this in a few weeks but, this is it, no more changing. I will also be using unity's tagging system tag each folder.

_game root is the only folder that will be included in the build.I will have 4 separate projects with only corresponding part of the project(Perforce will be used to manage this). "Systems dev", "Resource processing" and "Content creation". Those 3 will do their sync(using perforce) with the "Final build project". In theory at least final build should be nice and clean.

I am simply trying to keep my sanity. I'd appreciate any input you can give me.

 

Good idea. Barring any technical issues, that's the smartest thing. If you develop better folder structure ideas, you can save them for your next project.

That said, if any assets install into Plugins or any of the other special folders such as Gizmos or Editor Default Resources, you should not move them out. In the best case, moving them can substantially increase your compilation time, which will slow down your development. In the worst case, it can break the assets and prevent your project from compiling.

Speaking of compilation time, look into assembly definition files if you haven't already. They can significantly speed up compilation, but they can also impose restrictions on how you organize your folders.

 

You are awesome! Thank you for the instant response. No I had no idea about the assemblies. I will take a look. As for the plugin or any run-time systems (e.g. third party stuff), I never move them. I let them go where they want to go in the folder structure. I only move Audio/Texture/Animations/3D stuff.

 

One of the single best tips I have ever got when it comes to folder structuring in Unity, is to have your entire game inside a folder in Assets.

/Assets/MyGameProject/



Ever since using this tip, I've never had any of the annoying problems organizing third party assets or anything else. I just let everything fall where it wants to in Assets.

Idk why, but it's definitely the best tip I've received. Maybe it's my obsessive-compulsive desire for perfect organization, but having all of my stuff in a single folder and not caring about everything outside of it is just wonderful.

It's like being okay with a horribly messy shared room because your own shelf is pristine.

 

Also, I just recently upgraded Unity from the 5.x series and discovered that AssemblyDefinitions were a thing.
Placing all of your game's files in its own folder lends itself to creating an AssemblyDefinition of your game, to further separate it from third party assets, and maybe even improve compile times during the day-to-day.

 

I am a new developer creating an island game with a couple of people. The island has different sections. The player has to do something to unlock the next area of the island. So my question is: Do I need to create each section of the island separately? Because I thought I could just create one island and create barriers between each section and open those barriers by even triggers.

 

Hi! When you're starting out, always go with what's easiest. In this case, I recommend creating one island with unlockable barriers. In the future, you may want to split sections, but experience is the best guide to when to split things.

That said, do try to keep the assets in your project organized. Don't put too many assets in a single folder. And give them names that are easy to search for. It'll make it easier to find the assets you need.

 

Thank you so much. One last question, would these same recommendations apply if I am creating the terrain assets and models in 3Dmax for export to Unity?

 

Yes, I think so.

 

Guys, Where you are storing Input Actions file of New Input System?

 

So, it has been about 3 years since I posted on this thread trying to figure things out. Here's what I have learned since then.

It literally does NOT matter how you organize your folder structure if you work solo. Unless of course if you work in a team, then things are little different because you have to do whats easy for everyone.

Today, I organize in the most convenient way possible for myself. And sometimes I move things around at will. Not working for me? Rename/Move. Unity folders are very dynamic (and very fast in never versions), you can rename, move or do anything you want at anytime (Unless of course you have some thing hard coded to a specific location).

When I need to create a folder, tell my self to go find and open that folder (imaginary folder), first place my mind wants go to is likely the place that would want to create that in. For example when you said Input Actions, my mind immediately went to my

Assets/Game Root/System Settings/Input

folder.

If I have to spend more than 3 seconds looking for it, its at the wrong place is my philosophy now.

 

From a web developers wievpoint, there are two main ways to structure an application; by feature or by type.
For larger applications, I have found a good mix of those two to be good.
On the top level, group files by the most important types, e.g. a folder for Scripts, Prefabs, Objects, Shaders etc. Now under each of those folders, you may sort by feature, and make a new subfolder for every large feature, and subfolders under that again for smaller features.

 

Allow me this necromance. Does your game having a somewhat linear story change the philosophy of how to organize the project? I'm curious of some ideas on how to store things in relation to how they show up in the game. In my mind this falls under a separate category. My intuition is that code that isn't "time specific" should be stored in one of the ways described above, but time dependent code should be separated as best as possible. But not sure if this intuition is correct. Something like :
- Game
- Chapter 1
- Stuff
- More Stuff
- Chapter 2
- Etc

 

I like this _underscore idea and the multiple Unity projects idea, it is not often mentioned. It certain would solve any and all immediate conflicts and allow getting to work quickly. I wonder about non-unity assets like .psd .txt .doc .png etc, what the impact of storing these in Assets is.

 

Unity will still import asset types that it recognizes, such as .psd. If you're not using the file as an asset in your project, consider using a folder that's on the same level parallel with Assets instead of putting it inside Assets. It'll save time when reimporting, and it may also help keep your project organized.

Something could be said about new features, such as assembly definition files, added in the 7 years since this thread started, but the general ideas still hold up.

 

My philosophy is to keep together what belongs together. So rather than different directories based on file type, have a directory based on the different concerns. For example a directory "character" which contains the models, animation, prefabs and scripts (CharacterController etc.). I usually have a directory called "3rd" for third party assets and a "common" directory for common assets (which I may even use for other game projects).

 

Good idea. Only thing is prefabs and scripts (and even animations) tend to be shared.

Especially scripts, if you structure your framework in a reusable way and/or use assembly definitions it is best to keep them separate I think. For example, my CharacterController would inherit from my ManagedBehavours base class and will need access to game settings etc... which would be in my core framework assembly.

I guess it depends on the project though, if it is a small project it could work.

Not an easy thing to do but I have been trying really hard to keep game logic and art separate, it makes it much easier to extend, update and iterate.

I have been trying so many different things but I keep going back to what Tony Li said here:https://forum.unity.com/threads/best-practices-folder-structure.65381/#post-2237072

Unity doesn't really enforce how asset developers do things, if they did it would make things much easier and assets would be in the plugins folder or in packages (via package manager). Until they do, I let them go where they want to go, and all my stuff go in "__Project". This is the most sustainable way for me on a long term project.

 

@TonyLi

Could you potentially elaborate a bit further into this? I tried looking for it on the forums but couldn't really find much.

Our game for now is small in scope however we do have plans for it becoming significantly larger. Do you guys think it would it be better to start off a new project using a specific file structure knowing that in the future it's going to become large? Or start with the smaller/easier file structure as the ones discussed here and then refactor/restructure as the game gets larger?

 

If you are planning to make a big game (in size and complexity), you likely need multiple projects.
What I do (and advise when I work with others) is (if we are starting from scratch)
- set up the version control system first (I'm using Azure Devops Repos, it's a free GIT service from Microsoft)
It is important, because my repo will encapsulate not only the Unity project, but also more things.
In this screenshot (I copied a current project but only showing the basics):
1-

ProjectMainName

is the folder what you call it in the VCS repo (the git client makes this folder). As you can see it contains the .git folder (git client), .idea folder (JetBrains Rider).
But it contains the folder for the

FMod

project as well (we're using FMod middleware as our sound and music), here we build the sound banks.
This also contains a .gitignore file, which derived from a Unity .gitignore file, but has some extras and all the Unity-related exclusions are prefixed with "/ProjectName"
We have a

SourceAssets

folder in here as well, there is where we store most of the actually used (but unoptimized) artwork, submitted to VCS but separate from the Unity project. So we don't pay the import cost for everything, only the game-optimized things which we import.
2 -

ProjectName

(can be the same as the ProjectMainName) is created by Unity and a standard Unity Project folder.
3 -

__ProjectName

- this also can be the same as the other ones. This contains all of our code, assets, everything we create or add, except for our general framework which is a package and pulled in as a package using git url.
We do not touch almost anything outside of this folder, except when some asset has config somewhere.

But after all this, when you have an empty project set up (mostly), you should make a project copy on disk without version control (remove the .git from the copy).
We have several copies of the project on various stages (usually doesn't matter, really).
But what we do is, we import 3rd-party assets in a separate project and we only export over in our main project the small number of really necessary files.
We develop our separate things (player movement, attack scenarios, sensor prefabs, etc) in separate projects and export everything in our main project, when they are either done, or decent enough to start to assembly the main project. Essentially think of the extra projects as more advanced scenes where you are really free to mess around, you don't hurt your main project and when you have something tangible, you want to preserve, move it over to the main project and submit it into the version control (from there on, all, well, most changes need to happen there).

Also, I usually propagate the "folder per feature" method as opposed the "folder per asset type" method (which is fine for smaller projects. What it means, most of the building blocks a feature needs goes in a folder, so you can remove it any time in its entirety. So not

Textures/DragonTattoo.v2.png

but

MobBoss2/Tattoos/DragonTattoo.v2.png

. And if you end up removing the "MobBoss2" from the game, you just remove the folder and call it a day.

This is my short idea on the many-project-style development. But the most important thing is, when you're working on a bigger project is that you make the rules. Make them, actually and make sure, you and everyone else are following them. And be consistent.

 

Take 7 year old advice on an ever-changing game engine with a grain of salt. Much of it predates assembly definition files, addressables, disabled domain reloading, etc. In a moderately-sized project, it may be simpler to use asmdefs to speed up compilation (although there's a limit; too many asmdefs slow down compilation) and external addressables to keep reimports and scanning of art/data assets fast.

However, some of the advice is still quite valid. Leave third party assets where they import; don't move special folders such as Gizmos or Editor Default Resources.

Back at I think Unite 2020, Schell Games did a talk on their multi-project setup. You can search up the slides, but I don't think the video is available any more. I think they had some pure C# projects to compile assemblies and automatically distribute them out to Unity project(s), and some Unity projects holding their source art that they'd use to generate assetbundles and distribute those to other Unity projects. Their main Unity project (the one they'd generate end-user builds with) was very simple: virtually no code and assets except for DLLs and assetbundles. This would make code projects small and clean without a lot of art and data in the way; they can contain their own test code and data without having to keep it in the main project. Artists can use projects to pack assets into asset bundles. Level designers can work in small projects without any loose scripts or art assets to manage since it's all in DLLs and assetbundles. A plugin like RockTomate would probably be useful to automate a lot of this. Then again, some of this is outdated (use addressables now) and probably overkill unless your project is really massive.

This is the best advice.

 

It would be a great watch/read but I cannot find either slides or video (searching for "Unite 2020 Schell games" and "Unite 2020 project setup").

If someone finds them please do share!

 

Did a quick search in the forums. It was Schell Games' Unite 2011 presentation on Scalable Game Development. Found it on the Wayback Machine. Hope it's OK to drop here. Keep in mind that it's from 2011.

 

Thank you very much!!!