This wiki contains recommendations on how to create and manage a productive Unity Workflow. We don't claim the techniques and processes contained within this wiki are the best workflows out there. But they are what we, collectively, believe to be productive. We welcome your ideas and input, just hit us with a pull request or raise an issue to discuss a proposal.

Project Structure

When working in teams it is important that progress can continue on one section of the code, artwork, sound, lighting etc. without the risk of breaking another persons work. For this reason we like to use the Unity Package Manager to break up a project into separate components projects. For example, we might have a production project for the FooBar game that looks like this:

• Assets
  • [Imported 3rd Party Assets]
  • Scenes
  • Scripts
    • Editor
  • ...
• Packages
  • Foo_Bar_AI
    • Behaviour_Trees
    • Scripts
      • Editor
    • Scenes
  • Foo_Bar_Audio
    • Scripts
      • Editor
    • Scenes
    • ...
  • Foo_Bar_Characters
    • Prefabs
    • Foo_Bar_Scripts
      • Editor
    • Scenes
    • ...
  • Foo_Bar_Environment
    • ...
  • Foo_Bar_Materials
    • ...
  • Foo_Bar_Models
    • ...
  • Foo_Bar_Textures
    • ...
  • Foo_Bar_UI

This structure may seem cumbersome at first but the Package Manager has some pretty good dependency management. This allows for each subproject to automatically pull in the dependencies it needs and thus always be working with the latest version of that package. For Example, while the integration project pulls in all packages the Textures package might only pull in the Characters and Environment modules.

Naming conventions across the project allow integrators to pull content from across the various imported packages into the main game.

Packages can be shared across multiple projects while version control ensures that the right package is imported for builds.

Packages can be imported using the Package Manager directly from Git. However, if you expect to be working on a package directly it can be convenient to checkout the packages as projects and then load them into your higher level projects from the file system, this way they will automatically pick up any locally published updates.

Prototyping

We find it is always best to prototype and idea before actually implementing it. When prototyping one does not need to worry about technical debt or catching all edge cases. Just get the idea working and test it. Therefore we recommend that each developer has their "Scratch" project within which they can develop their own systems before sharing with the broader team. If you are using the above package structure for your project this is really easy to do.

Once a developer is happy with their work they can move it into the main package project and push it to Git.