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:

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.