Project Management Case Study Q&A: Rebellion

As part of our special investigation into project management (you can read our in-depth feature on the topic, here) we’ve been speaking to Rebellion’s CTO, Chris Kingsley, about the changing nature of software configuration management (SCM) requirements in games development, using the studio and its use of Perforce as examples.

Much of project management revolves around team sizes and scale, so how has Rebellion grown since it was founded in 1991?
Rebellion started in 1991 with one employee, working from a basement in Oxford. Today, it has grown to 280 people, with studios in three locations across the UK, making it one of the biggest privately owned games developers in Europe and possibly the world.

Can you describe how your development environment has changed, and the drivers behind these changes?
It has changed considerably from the days when we worked on the Amiga and ST. Back then we would work on one project at a time and hand over our work on floppy discs and would have to take a lot of backups as we went along. Today, we often work on five or more multi-platform projects simultaneously, that ship in multiple-language versions.

Rebellion’s recent growth to three studios has had a profound effect on our digital asset management strategy. We have become a lot more professional in terms of how our developers work, how they co-ordinate their work, how they communicate and how they share and maintain their assets. These assets are not just source code, but lots of large art assets, particularly the high-resolution texture maps – normal maps, parallax maps and so on – required for our PlayStation 3, Xbox 360 and PC projects.

As the business and the development environment evolved, Rebellion assessed a range of different SCM solution solutions, constantly looking for the most appropriate.

Is there a particular methodology or process that you follow with respect to game development?
Over time, we have developed our own method of working. There are so many buzzwords and different processes and ways of working but we just try to be as flexible as we can. In the mix are some elements of SCRUM, some agile development methods and some elements of the Spiral model. What we’ve settled on is our own kind of unique blend that works best for making games.

Today, our game development process is well structured. It starts with pre-production, when we do all the documentation, and create the game design, and from this we work out what resources we will need over the complete project lifecycle. Next, we go into full production with milestones tracking the project’s progress, and in particular focusing on alpha, beta and the final “gold master" milestones. If we are developing for the PC, we can say, “OK, so we’ll ship it, and then we’ll do a patch”, because by the time it’s out, we will have had another month of development. But, you can’t do that with consoles. There are Technical Requirements Checklists, which you have to go through to satisfy the console owner that they are getting a good “play experience”, and that the games work well on their system and won’t crash. So, for consoles, there’s a more stringent set of tests to go through; that can be tough and you have to allow extra time.

Over the years, to what extent have the software configuration management tools available helped or hindered your development teams?
When we started there weren’t many solutions available, though any form of source control was a huge advantage. One option was Visual SourceSafe, which had its benefits but Rebellion quickly came to the conclusion that it had its limitations. I think that’s because it was designed for fairly small teams and for projects that were more source-code heavy, and pretty light on the graphics and other art assets. With games development, the source code which we do fits easily onto one CD; but the art and sound, and all those other assets – textures, characters, objects – will fit on multiple DVDs if you’re lucky. So the scale of data storage is completely different. When we first started out, we had one or two projects going at a time, but now we have many more projects going simultaneously, and SourceSafe didn’t scale up brilliantly.

Did your past experiences with SCM tools help you to define what you wanted from a replacement SCM solution?
To an extent, yes. We needed a system that was going to work well across multiple sites because we work on live projects and all sites share code. Ours is a live code base across all of the projects, so it is critical that what we do works not just from a coding point of view – as we have strong coding standards and procedures – but allows us to work well together.

We looked very, very closely at SCM products that would facilitate this, but we decided that most weren’t right for us. We also needed to look at something that was going to work well for art and for code. As it happens, the team in Derby had used Perforce before and were saying some very good things about it.

We looked to see if Perforce would scale up to the sort of thing that we wanted it to do. It seemed to do everything we wanted and, as an added bonus, we discovered that our database size wasn’t going to get too big because Perforce actually compresses the art data.

How does Perforce benefit your developers?
One of our programmers, who decided that the Time Lapse View is one of the best features ever, says he now has much better source control. The Time Lapse View is one of the key features, as it really helps the teams see the timeline of a file, what has been changed and when, really quickly. This is important as you may work on a file over a period of time and if you need to quickly work out when it went wrong in that time, you’ve got the timeline view to refer to. Also, artists are really picky about the tools they use, but as Perforce is a very easy system to use, they get the hang of it very quickly.

Were there any objections to deploying a new SCM solution?
No, it was fine, everyone was really happy with Perforce. The principles and values of source control are – hopefully – understood by everyone, and though it took a little bit of time to get used to the terminology and the slightly different ways of doing things, the transfer was pretty smooth.

Does this increase in productivity enable Rebellion to deliver projects much sooner?
Yes, I think it would be fair to say that Perforce has really helped us deliver projects with better quality code and in less time. There’s less time sitting around waiting for files to check in or check out, and that’s time you can spend on coding. We delivered a game – Dead to Rights: Reckoning – on Sony PSP in three and a half months, and that’s a short timescale that’s unprecedented, and which amazes even industry professionals.

Looking ahead, how is Perforce supporting your next generation projects?
For us, Perforce is working well on our next generation of games development. Data sizes are exponentially increasing, so being able to cope with those data sizes, is incredibly important. On our next generation projects, the amount of data we are moving around is getting crazy; we are talking about numbers we didn’t even think about before, Terabytes of data generated throughout a project’s lifetime… and that’s an awful lot of data.