MCV/DEVELOP News, events, research and jobs from the games industry
[This feature was published in the June 2013 edition of Develop magazine, which is available through your browser and on iPad.]
The games industry changes all the time, so we need to adapt rapidly as a business.
We have stuck to the core values of Agile beneath everything, because it provides us with a strong framework to keep projects on track in a fast-moving, creative and highly technical environment.
Here are some examples of how we apply the four different pillars of Agile.
ONE: PEOPLE POWERED
Firstly, we value individuals and interactions over processes and tools. And we value them very highly, especially in terms of regular face-to-face communication. But, of course, we still also value tools and processes. When efficient and used correctly, they are vital to support our more collaborative, iterative approach. One cannot replace the other.
A lot of what we do in a project’s early days is to iterate and discover the elusive ‘fun factor’ in a game. That’s not a process you could build a tool or process to achieve. It can only be accomplished with iteration and collaboration. What works in theory can’t be proven until you play the game.
Harnessing individuals’ passion for making games is essential; that’s what motivates them. It’s important that they know their great ideas could end up in the finished product.
Across the studio, we use Scrum and generally stick to its core tenets, with regular meetings to review progress, blockers and plans, but how much we use it varies according to the project and the stage it is at. It works particularly well in a project’s middle stages when it is easier to define what the goals are.
At the beginning of development so much is investigation and research that it can be hard to write specific, measurable goals, whereas in the latter stages the focus is more on addressing bug reports and making fixes. Every sub-team generally has its own task board and, at the very least, it provides a way to make progress visible daily.
Using effective version management means that we can be less concerned about trying something out, because if we make changes we won’t lose the original version; we simply roll back if needed. It gives us the freedom to focus on creating code and assets to explore new ideas without having to worry about losing any valuable work.
Perforce has always been very reliable. We just know that we can assume it is working and will scale to match whatever we require. By autumn 2012, our three Perforce servers were handling around three terabytes of data, or about 6.7 million files.
A feature we find very useful is Protection Groups, which, when coupled with well-managed Client Specs, gives people a solid framework for what they should be focusing on and prevents them from making accidental changes outside their remit.
Also, they only need a subset of the whole project source, rather than synchronising everything, which can make a big difference in time and network traffic on a large project such as Until Dawn. For example, we might put all the audio team members on a project into one group and then limit the folders and files they can use to just the audio and other relevant project data.
TWO: MAKING SOFTWARE WORK
We also value working software over comprehensive documentation. Working software is massively important to us. We try to review the game very regularly – towards the end of the production process as often as once or even twice a day – so it’s really important to get a build of the game easily and quickly.
Again, tools are a complement to that: we have built a dedicated build server that is always integrating the latest data through Perforce, so we can create a build in just a few hours, often as little as half an hour. Ten or so years ago, it often took all night to create a build, despite having far less data.
Branching also helps us ensure we always have working software. We can branch the code and data – perhaps we want to try something different, or to prepare separate demo versions as we did for Gamescom in August 2012 – and then work on that in isolation, so that any changes will not affect the working mainline.
This allows the bulk of the team to continue working as normal, whilst ensuring that changes in either branch won’t cause bugs in the other.
THREE: WALKING WITH CUSTOMERS
Next, we value customer collaboration over contract negotiation. Our publishers are our paying customers, but customers can also be colleagues within the studio.
On Wonderbook: Walking With Dinosaurs it became evident that we needed additional custom tools for our designers to create the interactions and sequences of events used on the Wonderbook page layouts.
We have found from experience that taking a brief, working with a rigid set of requirements, going away and building something in isolation, then coming back to the customer several months later doesn’t work well in practice. We believe it is far better to sit down with the customer – in this case the tools programmer sitting with the designers on the project – for half a day or so and really understand the context of what is required.
This more collaborative approach means that better solutions to problems can be suggested, and also gives a solid foundation for on-going communication during development. We avoid having a completely separate central tools team, as this can lead to a lack of communication and understanding of the problems the development teams face. Instead, we have a tools specialists group who are assigned to the teams as needed.
Of course, we also work closely with our publisher customers, particularly their producers and QA teams. While a lot of the work we do is agreed and planned well in advance, we try to foster as collaborative a relationship as possible, with regular face-to-face meetings.
One of our most essential systems supports the localisation of text strings and voice audio for a game. On Sony products, a centrally hosted database, which can be accessed by the translation teams and the development team, holds all the current assets. For an interactive drama game like Until Dawn this can be as much as 25,000 lines of dialogue.
From our side, we can then pull down new versions of the localised data into Perforce or push any script changes back up. The client’s translators can take a drop of anything that has changed and put their translations back in the database. Previously this would have been a laborious, error-prone and manual process on a spreadsheet with notes about which text needed to be changed.
FOUR: PLANNING FOR CHANGE
Finally, we value responding to change over following a plan. But that does not mean that you do not need a plan. In fact we place a lot of importance on solid planning processes and have recently brought in dedicated production managers.
However, within that framework it is still essential to be flexible, to be able to respond rapidly to change and make that attitude part of our ethos. While it’s not always human nature to embrace change, it is a lot easier if teams know they have the supporting mechanisms, including dependable version management.
The games industry is going through an unprecedented period of change, with games available on an increasingly wide range of devices, as well as the growth of casual games and more complex games, meaning that the ‘middle market’ is tougher than ever.
That is why we are focused on building a reputation for high quality games, which requires a studio where people can do their best work all the time, and we believe that working in an Agile way will continue to help us to achieve that.
