This is part of a series of posts on source control for game development. Read more in the Blog.

We have finally reached the end of this series trying to find the best source control for game development.

If you have followed through all of the articles, the answer to your questions may still be unclear. Each solution has its pros and cons, many different pricing and hosting options. If you're a small team or an indie developer, you do not know what the future holds. Perhaps you'll sign a big publishing deal and need to scale rapidly with a larger budget, in which case your choices are changed once again.

So, for the final article in this series, and perhaps the only one you should read, I'll try to provide an overview of our findings and provide simple guidelines to help you with your choice.

Available Options

So far we've been studying in-depth 4 of the most popular source control options for game development.

• Git, very popular outside of Games, but its regular downsides become showstoppers for game development at scale.
• Perforce, the game industry standard, very expensive but the best option for dealing with large and complex projects.
• PlasticSCM, a very promising competitor to Perforce. Much better than SVN, but comes with a price tag.
• Subversion (SVN), a very solid option for small to medium projects, free and open-source.

Why do I see those as being the most popular? Well, one indicator is that these are the 4 options included by default in Unreal Engine 4, for instance. Perforce seems to be the most commonly integrated source control among game engines, especially the proprietary ones that you're unlikely to get your hands on unless you're part of the company.

That being said, there are other options we'll try to cover briefly.

Mercurial

Mercurial is a Distributed Version Control System (DVCS for short) very similar to Git. It is written in Python and is an open-source project as well. Mercurial's data model, features, and functionalities are virtually identical to Git. This has caused sort of an internet feud over which system is superior, with each side trying to convince the other to no avail.

Proponents of Mercurial argue that it is much better designed, and I generally tend to agree. In particular, Mercurial's command-line seems to be elegant and straightforward, using similar terms as subversion which makes learning Mercurial much easier than Git. There are other aspects that differentiate the two, most notably, while Git allows rewriting history through rebasing and several other commands, Mercurial's history is more immutable. For a full breakdown, these two articles from Atlassian summarize very well why one would be better than the other.

As with most DVCS, it requires a local copy of the history and therefore the same problems than we would have with Git would also apply. Mercurial seems to provide a solution for handling large binary files, and is considering a Git-LFS-compatible protocol.

Mercurial is still very active and used today in open-source projects as well as large companies. The Wikipedia page lists Facebook as one of the major users of Mercurial, and it is the common example thrown around when discussing Mercurial's adoption in the real world.

However, it is undeniable that Git has won the popularity contest. With Bitbucket shutting down support for Mercurial repositories, and now GitHub private repositories being free, more and more projects are looking to migrate from Mercurial to Git, as indicated even by some projects still listed on Mercurial's page.

For games, it seems that this is a poor option due to the lack of large file support, and the typical downsides of DVCS for non-mergeable files. I have, however, heard of some game projects using Mercurial, and would be very interested to hear some testimonies.

Unity Collaborate

If you're using Unity for your game project, you may have heard of Unity Collaborate.

Unity Collaborate is an official Unity product and part of their Unity Teams offering. This seems to be a managed platform and service to host your project, run your continuous integration and automation. The pricing is also very reasonable, especially considering there are 25GB of storage included.

I haven't used Unity Teams myself, but it does seem quite similar to any of the cloud-hosting providers we already evaluated for Git. When compared to those, it also seems to lack in other features, such as project management tools, documentation tools, and so on.

Unity Teams is also a black-box, and it seems that you can't access your repository in any other way than through the Unity Editor itself. As far as I know, Unity Collaborate actually runs on a Git-LFS backend, which makes it quite similar to GitCentral, but for Unity. However, I'd argue that having your entire project in a black-box system is not something you should feel comfortable with. There will be many opportunities where dealing with your source control from command-line or dedicated tools will be necessary, and as the project scales, I would be surprised if the Unity editor could handle the most extreme cases, especially since almost no dedicated source control GUI manages to do so. GitCentral, on the other hand, allows you to access the underlying Git-LFS repository directly, and deal with your project in any way you want.

Unity Collaborate is still a good option for low-stakes projects, such as student projects and relatively simple projects. As soon as your project will scale or require specific features, you'll need more than the black-box can provide.

I would still love to hear some testimonies about Unity Collaborate since I've never tried it myself.

Anything else?

Well, this is where my knowledge ends. I haven't heard of any other viable solution, nor met game developers using any version control that was not on this list. As I mentioned in the introduction of this series, some people use systems that cannot be qualified as source control, such as Dropbox and other file repositories with some sort of versioning. But, since you should without any question be using source control, those options won't even be discussed here.

If, however, you know of any other option you'd like me to look at, please reach out. I'll be very interested.

Comparison Matrix

With all that said, let's put all of this research together and see if we can draw some conclusions.

Please bear in mind that the assessments represent my subjective opinion after working with these tools in the context of game development. If we were talking about more traditional code projects, this table and the results would be very different. There are plenty of articles comparing source control for code projects if you need to.

Verdict

Unsurprisingly, the two most attractive options are Perforce and PlasticSCM. Both of these were designed for enterprise scenarios, very large projects, and a high number of collaborators. They were optimized to handle large binary files efficiently and provide great graphical tools and user experience. However, they are also the most expensive options.

Git and SVN are both free and open-source. This makes them much more popular with the development community at large. While the basic package only contains the command-line tools, both Git and SVN are supported by a massive array of third-party tools, web applications, hosting providers, and integrations in almost anything you can think of.

In my experience, your budget will be the main factor in the choice you make. This is why I've settled on the following ranking:

1. Perforce: If you can afford it, you cannot go wrong by choosing Perforce. It has been the industry standard for more than a decade, and for good reason. It does exactly what you need and you can easily work around its caveats.
2. PlasticSCM: A bold choice, but it can be worth it. PlasticSCM is constantly improving and I expect it to seriously challenge Perforce over the coming years. The price is affordable for most serious teams.
3. SVN: A classic for indie studios. SVN is free and allows you to spend a bit on your own hosting infrastructure rather than using the cloud providers. It will work well enough for small to medium-sized projects, and if your project grows larger, you should have money to spend to upgrade. For most readers, this is the right choice.
4. Git: Certainly the most popular version control, its model simply doesn't fit the needs of game developers, where binary files and non-technical people concentrate the bulk of the action. I would not recommend Git unless you use GitCentral, or an equivalent. Note that if your project is using SVN, you can still use Git for your programming thanks to git-svn.

So there you have it. In my opinion, Perforce is still the best source control for game development. This is the one I've chosen for Darewise, and we're very happy with it so far. I will continue to evaluate PlasticSCM periodically, as I feel it has a lot of potential.

However, if your budget is tight, I'd strongly recommend to take a look at SVN. You can achieve similar results for a fraction of the price, and you'll be able to migrate to a better solution once your budget allows.

Final words

I put a lot of effort into this series. I researched the source control options I didn't use, learned about them and their ecosystem, browsed through mountains of documentation, and actually tried them out on a project to see how they behaved. It was a learning experience for me, and I hope it was interesting for you too.

If you're reading this, thank you. I hope that it will help new game development teams to make the right choice on source control, which is arguably the most important technical choice to make after choosing a game engine.

Feel free to contact me for comments, questions, new information, and ideas for improvements on this topic.