Folder and code setup for a medium size Unity project

Despite there being many blog posts on the topic, I have yet to find a simple explanation of an easy to use, low cost, robust solution for a small developer team that builds reasonably complex software, involving front end, back end, UX, as well as the use of several third party components, either from the asset store or from public github repositories.

Ideally, the setup should be robust and support real-world situations, including working on a future version while performing bug-fixes to the main version. In our case it must support multiple platform configurations where some code is shared, but some plugins and code is platform specific.

In using Unity for a couple of years, some common principles have emerged to help keep sanity in a project with multiple contributors and 3rd party libraries.

  • Unity’s root folder cannot be managed. Several third party assets and libraries require that they are located directly in the root.
  • Content should primarily be grouped after function (not asset type), despite the prevalence of folders such as “Textures”, “Prefabs” etc, and despite Unity itself requiring certain folder names ie “Plugins”.

After much consideration, these are the steps I have taken after working with Unity for 2+ years in setting up the shared environment for my team.

  1. Use a collaboration platform that allows private git repositories at a low cost. I’ve found that Visual Studio Online works well for our purposes, with free private repositories for up to five users.
  2. Use Visual Studio for syncing repositories. Nowadays, it’s available for both PC and Mac, and it works with submodules. More on that later.
  3. Use a common main project with branches for your stable (master) and preview (release) versions.
  4. Put all “well-behaved” 3rd party libraries in a separate repository and clone as a submodule to your main project. Contrary to most accounts on the web, I’ve found that submodules are fairly reliable and provide an excellent way to put shared code inside your Unity projects. It wasn’t until recently they could be managed directly in Visual Studio, however, and before they required some careful setting up using the git command line.
  5. Optionally, if you have or expect some of your code to be reusable in other projects, put these in a separate “Toolkit” repository.
  6. For any platform specific content, put these in separate repositories and link these as submodules.
  7. When your wireframe application is working well, fork the release project once for each developer to reduce the risk of inadvertent changes to the master or release projects


These are just my own thoughts on how to set up Unity for maximum productivity. What is your favourite configuration? Please fill in your best tips in the comments field! Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *