MCV/DEVELOP News, events, research and jobs from the games industry
22cans, the Guildford-based games studio set up in 2012 by industry veterans including Peter Molyneux, has this summer launched Godus, the new GodSim game that the industry and players have been buzzing about for the past year.
22cans has built Godus with a small team of 22 developers, partially supported by Kickstarter funding and although it is expanding the team, it will use a Feature-Driven Development system to release regular updates, using a tight team – rather than having hundreds of developers, which would be the approach a larger games studio would take with a game of this scale.
It’s so much more challenging to build a game compared to 20 years ago. In those days, you wouldn’t have much more than a compiler and a paint program and that was it. The complexity of today’s games have changed that and large-scale connected social games place additional demands on developers because you have to continually add new features to keep users engaged.
This is why adoption of what we call Feature-Driven Development – also known in some quarters as Continuous Delivery – has been important to us, as we always have a stable branch of code with working features ready for release. It means we always have new features on the boil and can make a decision about which features are ready to be integrated into the main codeline and released in the next upgrade. We have complete visibility of the entire state of all features and can easily pick and choose exactly what we want to include.
The right tools and processes are almost as important as the code
While games have become more complex, development tools have also evolved and can support our Feature-Driven Development approach. That said, there is such a plethora of tools out there and making sure that you choose the right components is nearly as important as the actual quality of the code itself. This is why before launching straight into building a game, it makes sense to put a lot of thought into how you are going to build it and with which tools.
For us, a big focus has been on adopting processes and tools that minimise unnecessary workload, allowing the team to concentrate more on creating the game itself.
We always have new features on the boil and can make a decision about which features are ready to be integrated into the main codeline and released in the next upgrade.
Seven strategic steps to success
Taking version management as an example, here are some of the ways in which we are working, both in the run-up to the launch of Godus, but also giving us a foundation for post-launch.
ONE: Think of the future and integrate
Although you may not need everything straight away, it makes sense to plan ahead. For instance, how will those tools integrate together? That’s one of the reasons we have chosen Jenkins and are moving to Jira for our bug tracking, because they integrate well with Perforce.
Both Jenkins and Perforce have features that allow us to drive Feature-Driven Development and those work well in practice. For instance, when some code for a particular feature is checked into one of our Perforce feature branches, Jenkins will see it, grab that code, build it and then put build assets for that feature branch somewhere that is easy to access. This means that testing can happen very easily, without having to access a programmer to do anything to make that happen.
TWO: Short features
We want to be able to release something new every couple of weeks, so we have short sprints, which deliver our so-called ‘short features’. Current examples include guest log-ins (which makes it easier for users to play the game without having to login or register), collectible stickers and ‘happiness’ features, where users give gifts to their ‘Followers’.
To support the introduction of short features, we’ve used the ability to create numerous release branches within Perforce, which we call ‘short feature branches’. When we first started developing Godus, there was no need to go beyond the mainline code branch, but the benefit of having numerous feature branches is that if something doesn’t work out, then it is not merged in our short feature integration branch and therefore doesn’t impact on the release version. So it gives us a safe environment within which to experiment.
Similarly, we put major features into our so-called ‘long feature branches’.
THREE: Fine-tuning characteristics of the game in real-time
With the game in public release, we need to be able to react quickly to certain behaviours: for instance, how quickly people move through a game, how quickly a user builds up a game metric (for instance, we use belief as a currency within Godus) and how quickly the user builds elements in his or her world.
To minimise any unnecessary extra admin workload for our developers, we are using the Triggers feature within Perforce, which automatically takes care of pushing through the change into the live system (once it has been checked into the mainline code branch). In other words, it happens in the background without developers having to handle another process.
FOUR: Server-based version control
It is important to us that we can ensure that two people cannot be working on the same binary file simultaneously, because of the risk of overwriting changes. I know a lot of developers like Git, but apart from the fact we wanted a server-based system such as Perforce, it was also important for us to have a system that is easy for artists to use. That said, if any of our developers insist on using Git, then they can use Git Fusion from Perforce, which means they can carry on working with Git, but within the Perforce environment.
FIVE: Where possible keep binary assets small and localised
To make things more logical and risk-proof for our artists, we split our assets into smaller individual binary files where possible, one per asset. Our process is much simpler, because this granularity enables the mapping of various assets to the different feature branches.
Sometimes the granularity of the assets goes across all branches, such as audio files. It may sound challenging when we come to merge those branches, but we just have a separate audio branch, where just the audio code line is worked on by the audio designer.
We’ve also developed a way of dealing with the prodigious quantity source art that builds up over time. We needed to keep some history of the source art, but history could quickly build up especially across all the branches taking vast amounts of space. In my experience, artists very rarely want to revert changes to more than 5 versions old and certainly not across different branches.
Our repository is currently about one-and-a-half terabytes. Our way around this is to keep the source art in the main codeline branch and only branch feature branches from the source code and compiled art assets necessary to build and run the game using a virtual stream view derived from our mainline branch. This means that the only files that are branched are those that are needed to build and run the game.
So, artists work within two Perforce workspaces: one that is just for the source art and the other pointing at the particular branch they’re working in and checking in build assets. This way we don’t clog up our repo by branching all the source art files into every feature branch.
SIX: Switching between workspaces
With a small team, people often have more than one area of expertise or ownership, so they need to be able to swap easily between the features they are working on. The streams feature helps us achieve that: the user just drags an icon into the right space, doesn’t have to worry about synching workspaces and can then move on to the next task.
SEVEN: Analytics
Part of our Continuous Delivery process is collecting data around user behaviour. Everything is tracked, which means we can then analyse that information and use it to improve the game. Every time any user carries out an action in a game, a record is generated and entered into the database, which can, for example, help our designers look at the game and think ‘people are getting a bit stuck here’, or ‘they’re taking too long’ and then amend the game accordingly.
In practice, this means looking at the balance data stored in Perforce and tweaking values, which are then tested, pushed into the mainline branch and via the Triggers function, are instantly live. So if we need to, we can execute hour-by-hour tweaking of the game, though realistically, that review and analysis is more manageable to deal with every couple of days, as the designers need time to digest that information.
Godus may be hitting global launch, but this is just the beginning: the development will continue as long as the game exists. Integral to making that work well with a talented but small team is embracing branching, Streams and using tools that are designed to support that approach.
