We frequently see questions on the Unity forums and Reddit asking how Unity users are meant to collaborate on projects as a team. While there is no ‘one size fits all’ answer to a subject as complicated as this, we hope to provide a place to start.
Why collaboration is important for teams
Working with others adds complexity, which is why collaboration is not easy. That said, it brings with it substantial benefits that, if managed right, can outweigh the complexity of working within a team. When you are working on a hobby project, or a small game without a major time commitment, working by yourself can certainly be sufficient. But there will come a time when you have deadlines to meet and a game with a level of complexity either beyond your current skill set, or beyond your ability to create within that time frame. In this situation, like it or not, you are going to have to form a team.
Effective collaboration with your team can make the difference between being a highly effective unit working together to achieve a clear vision and being a disjointed group of individual developers that eventually combine their work. When you not only bring additional people on to your team, but let them share their experiences, creativity, and expertise, you will complete work faster, achieve higher standards of quality, and create an end product that has a cohesive vision and is greater than the sum of its parts.
How to collaborate on Unity projects
When working on a Unity project with a team, there are typically two concerns: how to distribute/share the project files and code, and how to collaborate efficiently at a more granular level while keeping everything organized.
Source control is the core of how teams collaborate and keep their projects organized. While source control is typically built for managing code, it has become better at handling assets and project files over time.
In general, source control works by having a master repository in a shared location that all members of a project can access. Team members can pull the latest revisions from this repository to ensure they are working with the most up to date version of the project. When users make changes to the project, they can submit a request to merge their changes to the repository.
The great thing about source control is that it typically supports other very helpful, if not critical, features to managing your project. For instance, most source control systems will provide a revision history that can allow you to view and revert changes that are perhaps causing problems. They also support merging of code and many assets. So, if two people are making changes to the same files within the project, their progress is not clobbered and can instead be merged intelligently. Some assets don’t merge well (or at all), so there are exceptions to this. Overall letting your team work together in an intuitive system that helps manage and maintain project organization can make a big difference in how well they collaborate.
Here are some examples of source control tools:
- Git (GitHub and GitLab to assist in management)
- Here’s a great guide on how to use Git and Unity
- Subversion (SVN)
- Collaborate (Unity’s own source control system)
Art Assets and Digital Asset Management
While art assets will typically be stored in your source control platform, they don’t have the benefit of being easily merged. In addition, because of the origins of most source control platforms, they aren’t built to have a great way to identify differences in art assets. This makes it difficult to decide when to overwrite existing files with new revisions.
To help solve this problem, Digital Asset Management (DAM) tools have been created. The purpose of these tools is to store and track different revisions of art assets. Many of these tools can read files from common art applications (Maya, 3ds Max, Blender, Nuke, Photoshop) and create snapshots and version comparisons so that major changes can easily be changed. Often, artists are also able to use the tool to leave notes and annotations to identify specific changes they have made.
Here are a couple examples of DAM tools:
Collaboration within Unity Scenes
Anyone who has worked within Unity understands the struggle of collaborating on a single Unity scene. Scenes can be highly complex, requiring input and work from many team members. Unfortunately, while Unity offers a couple workarounds, it does not offer an easy way to ensure everyone can work together within a scene. Here are a few methods used by Unity development teams to get around this:
Unity offers merge tools that let teams take multiple versions of a scene and merge the changes together. While in theory this works, it gets much more complicated when conflicts between two scenes occur. This often results in a lot of tedious manual adjustments, lost time, or in rare cases complete loss of work. It also promotes an environment where members of a team work independently and do not see each other’s work until it is smashed together with their own.
“I own the scene” or the ‘conch’ method
To avoid conflicts or clobbering of work within a scene, some teams will resort to having one person ‘own’ the scene at a time. During this time, only that person is allowed to edit anything within the scene. It isn’t until that person has completed their edits that anyone else can begin. This method can cause annoying inefficiencies and typically results in one person waiting while another works.
Multi-scene editing lets users open multiple scenes at once in the editor. Teams can use this method to use scenes as smaller chunks of a larger level. By approaching scenes this way, the ‘conch’ method can be used at a lesser detriment to the team, as only a chunk of the level is reserved by them. However, this is still far from optimal.
Due to the clear need to be able to work together within scenes, our team developed a tool called Scene Fusion. This tool allows multiple users to connect to a scene at the same time and work on it together in real-time. The idea behind this is that you no longer need to worry about conflicts, or who owns the current scene. Instead you can work in an environment where you can see changes being made by other users in real-time while you work. This type of workflow promotes communication and helps users adapt to other changes being made in the scene without having to wait for an unfortunate merge conflict to identify the issue. The net result is that teams will complete level design, construction, and decoration significantly faster with less risk of lost work.
We hope that this article has given you some helpful information. While there is a lot more that can be said on this topic, this will hopefully provide your team with a place to start collaborating in Unity.