22 Cans – Old Dogs Reject New Tricks
With the games industry embracing the mobile and tablet markets and a plethora of new developer tools now available, a start-up in this industry might decide to take a clean-slate approach to its systems. This was not the case for 22 Cans, an exciting new games company based out of the UK and co-founded by the legendary Peter Molyneux OBE. After thoroughly evaluating the new version management options, 22 Cans decided Perforce is still the best fit for the fast-evolving world of games. We asked co-founder and CTO Tim Rance to tell us more.
Peter Molyneux founded Lionhead along with me and three colleagues and steered it through the acquisition by Microsoft. That was in the days when console games reigned supreme. However, we both decided that to focus on the exciting course in which the games industry is heading, we needed to start a new company. It’s a brave new world with the games industry going through a lot of upheaval, especially with the move towards tablets and other mobile devices, so there is huge potential to do something new and exciting. We set up 22 Cans last year with just 3 of us and today there are over 20 in the team, with a ratio of approximately 60/40 artists to programmers. We managed to secure Kickstarter funding last year and are working on our second big game, Godus, which is essentially the God game brought to mobile and tablets, inspired by Peter’s early and highly successful work Populous. Our first product last year was called “Curiosity—What’s Inside the Cube?” and as I write this it’s now down to the last few layers. This was more of a social experiment rather than a game and was designed to help us understand what makes this new market tick. It attracted a lot of buzz in the industry and from users.
Both Peter and I come from larger game development studios and publishers including Lionhead, Bullfrog and Electronic Arts. Our heritage is large triple A games involving lots of source code, third party middleware, massive game assets including animations, artwork and game levels. The asset and code pipelines are complex and the teams in those environments are big—up to 200 people. We used Perforce at Lionhead because it was ideal for version-managing such a large array of data, but we had decided not to have any preconceptions when we started 22 Cans and wanted to take the opportunity to see what else was out there.
We started with Unity as our development platform, because it is very much honed towards the mobile and tablet market and it even had its own version management system although it did not have any of the more sophisticated functionality we had become used to, such as branching and fine grain access control. This lack of branching made it difficult for some of the team to stabilise a version—for example in preparation for a show while the rest of the team continued development of new features. While Unity provides a very rich feature set with much extended functionality and a vibrant user community, in the end we opted for a pure language C++ solution. This gives us a touch more control, which is well suited to creating a very procedural-driven environment that we need for Godus.
So, we moved away from Unity and we’re now back to using C++ as our main development platform, along with Marmalade for cross-platform development. That’s all working well for us.
Back to version management: After Unity’s offering we moved onto DVCS systems which were loved by some programmers for the easy branching they offer. First, we used Git for some preliminary testing. Mostly running from the command line, this would have been no good for artists as the commands are somewhat obscure. Git was followed by Mercurial hosted in the cloud on a service called Kiln, which we used for Curiosity. Neither of these gelled particularly well with the team or our pipeline and in the end we had to abandon them. There were two issues with the cloud-based solution: First, we didn’t get 100% availability; second it was very bandwidth-heavy and slow at transferring the gigabytes of source art assets. The other issue with DVCS is that everyone gets everything; the whole repository and all the history, which leads to extreme file system bloat especially for binary assets. There are ways around this but it is all a bit fiddly.
The other problem is that without the concept of a centralised server, there’s no way to exclusively lock data, which is necessary for files that cannot be merged. This means there is no mechanism to prevent two people from working on the same file with the risk of one person’s changes accidentally overwriting the others. There are other server-based solutions such as Subversion but the interface is not particularly refined and some operations such as branching were not well visualised. So we decided to take another look at Perforce and realised that there were some new features that we hadn’t been using before that were ideal for 22 Cans. We particularly liked the look of Streams and the ability to support intelligent branching. Also, it is a centralised versioning service and people can easily get their heads around what that means: It’s a central server that can lock files, with no need to have repositories on everyone’s machines.
Perforce is a powerful mechanism that lets us customise every type of file and gives us absolute control over file locking and how much version history is stored. File loading is fast so we don’t waste time. The ability to be able to branch and control access to versions is a critical advantage of Perforce, particularly when we are releasing games out on new formats.
Perforce is the best fit for us. The games market is moving faster than ever before. In the past you could take a couple of years working on a game whereas these days, you are talking about less than a year, often just months. We don’t have time to learn complicated systems that need to be administered; we just want something we can rely on and does the job without getting in the way. And that’s exactly what Perforce gives us.