How Feasible/Sane is it to have multiple unrelated projects in one Unity project folder?

Question

I'm quite experienced with Unity and other (non-Unreal C++) game engines. I've managed multiple projects in C++-based engines, but with Unity in the past, I've used one shippable project per project folder. At the moment I have 3 barely-related, multi-platform projects that share the same third party libraries, some common code, and a bit of overlap in visual resources. One is a pre-release game, another is a client project, and another is an internal prototype.

Currently, I keep these all in the same Unity project (containing Assets and ProjectSettings). Right now, to preserve build settings, I cache these files per-project:

EditorBuildSettings.asset
ProjectSettings.asset

I love the monorepo approached and I've used it extensively from solo teams to startups with dozens of people. When you're considering a change, you can easily search and compile everywhere it's used. You're forced to write code at the right level of generalization, and fixes in one project can benefit all projects in the same repo. However, I can't tell if Unity likes this approach.

I've seen people recommend use of submodules, or symlinking directories in the Unity project before. I've had bad experiences diagnosing bugs that have submodule dependencies. I'm cautious of a complicated symlink setup, as I currently use 3 machines (one macOS, two Windows) to build and test multiple types of hardware, and also have contractors use my repos occasionally.

So what are the downsides of having one big project folder for all my building projects? Two areas I'm concerned about are:

1) Resource folders that may needlessly be shared between projects when shipped.

2) Third-party libraries with unexpected effects. Currently, I'm planning to handle these with per-project compile flags.

Answer 1

I asked a similar question a while ago and didn't find a satisfactory solution so I created a plugin called Link & Sync. Most of my plugins are pre-compiled DLLs which use a post-build command to copy themselves into the Plugins folder in a central Unity project. Then when I make a new game project I can copy the Plugins folder including Link & Sync, and use it to create a link between the Plugins folders in the game and the central project. Then whenever I recompile one of my plugins in the central project, I can synchronise the changes with the press of a button.

The Pro version also has options to notify you whenever changes need to be synced or to just sync them automatically. I tend to stick with Notify mode. It also supports two-way syncing in case you want to modify your linked stuff inside the game project and sync it back to the central one instead of opening up the central one every time.

Answer 2

Aside from resources issue you mentioned, an aspect to consider is that Unity will rebuild your codebase every time it regains focus, and while generally this is much much faster than any sort of c++ recompiling/linking, a large project slowly becomes more and more sluggish to refresh with every script you add, so take that into consideration.

However you have presented some valid points FOR keeping it a single 'god' project, aside from build settings being different (and aforementioned resource management) there isnt any hard reason not to use it if works for you.

As far as resources go, a thing worth nothing: resources in the Assets/Resources folder will be included always in your builds (unity assumes you will be loading those in runtime), but you can keep project-specific resources that you do NOT load in runtime in any other folder under Assets - they will be linked with your build only if they are statically referecned in any of the scenes selected for build (I believe this includes prefabs used in any of the scenes that are currently set to be included in the build) - keeping this in mind might cut down your asset management efforts.

I have a lot of scripts that I share between projects, the way I sort this out is carry on scripting pretending a script is local, but each change gets a version increment and a one line explaining the change at the front end of the file (as not always bigger file = newer version)

If I find the change important I copy it to the repo of a given plugin, if not I wait until the current project is less active and collate the latest set of changes from all active project, propagate those to repo and propagate them back (but I do it when there's time, rarely mid-production to avoid unexpected consequences). While this is a serious waste of time, it limits breakage I've been experiencing when trying alternative aproaches (i.e. submodules) as sometimes a change takt makes perfect sense from the point of view of one project can negatively impact another project using the same code.

Based on what you said (three projects that share some resources) I would probably keep it a single project as you currently do.