Context
This was written while I was a developer at Silverball, which had branched out from the Nintendo-exclusive Fuse Games. We were now on some multi-platform Xbox/Playstation/PC stuff using the Blitz Tech engine.
Our main jobs were rescuing other peoples projects that had gone somewhat off the rails, which was quite interesting and diverse work and it was good to be the team that got called to the rescue. Unfortunately it wasn't the steady work we had as a Nintendo studio. Belts and scopes were tightening, new work was looking less promising. I finally had to move on about six months after this was published when I found out my car was doomed to fail in the near future and I just couldn't afford to replace it.
I cannot for the life of me remember why I particularly wanted to write this for Develop, but I kind of sprung it on then editor Michael French out of the blue and he was keen to print it. It also sort of fed back into and clarified some principles we were using in the team at the time. Possibly I wanted to fire off some kind of record into the world of what we'd discovered about developing games using a proper, in case the studio came to a close.
Working at Fuse/Silverball was the single most valuable development time I have spent in what is a long career and our working methods deserve wider recognition. I've tried to apply these lessons to every job I've worked at since, with varying success, but always with a better process than I started with.
I'm pretty sure I didn't write the sub-headings, which seem to start off enthusiastically dense but tail off towards the end. I've put them in here to break up the solid wall of words. And yes, the printed version did have both bullet points AND numbers. That's just how we rolled back then.
My bio picture is a salad sandwich with Caesar dressing hair, and for some reason a bit of cold spare rib. My children were 4 and 6 at the time, and I could imply they made it for me but that just wouldn't be true.
Article
Hello, I'm Andy. I'm a game developer, and I'm wrong.
I'm wrong about when the game's going to be finished, I'm wrong about how it works, I'm wrong about how it's going to look , I'm wrong about what features it's going to have. I'm frequently wrong to think that my code is even syntactically valid C++. Wrong, wrong, wrong and wrong.
But you see, it turns out that everybody's wrong at pretty much every level, and if we accept being wrong and try to make ourselves just slightly less wrong at every step it turns out all right.
Here at Silverball Studios in Oxfordshire (formerly Fuse Games) we use our own system of Extreme Game Development (XGD), derived from the mainstream Extreme Programming (XP) method to deal with being wrong. With half a dozen on-budget, on-time, no-crunch games under our belt, it seems to be working.
So where are we wrong, and where could we be less wrong?
To The Extreme
Firstly, we're wrong if we think we're engineers. Engineers describe what they want to build, then work backwards from there figuring out the steps needed to build it. This gives an efficient and accurate plan, with a minimum of fuss. Follow the steps, build the thing, job done. While this is a splendid way of building bridges, it's a terrible way of building games. Finished games never looks like the original plan. They can't because you don't really know how it's going to play until you play it. So don't worry about it! Getting it right at the very start is philosophically impossible, wasted effort, fool's gold. Instead begin with an idea, some concepts, a kernel of a game to develop from. Make it cool, make it exciting, make it inspirational, make it (conveniently) the kind of thing you'd put in your pitch to a publisher, just don't feel the need to flesh it out too much as it'll be wrong.
With the kernel decided, we jump straight in. We have to find the eventual game that's going to come out of this idea. To do that, we need something working and playable as soon as possible; That way we can quickly discover which were bad ideas, and which were good, and even think up some even better ones along the way. But we're not completely rash, before we start coding we of course do some planning.
Oh what's the point? Of planning, I mean. Well, to have a reasonably detailed idea of what you're making, and how long it's going to take. It is a form of peering into the future, and that gets murkier and more wrong the further you look. Because of this we split our planning into broad-and-vague, and detailed-and-specific.
Broad and Vague
Vague first. Our concept is divided into individual features, called 'stories'. Each gets its own index card with a short title. They don't have to be too detailed ('Multiplayer' is a perfectly good story) because we can split them up later. Each story gets a rough (because it's wrong) effort estimate called the cost.
How Do We Decide What To Do?
This is the job of another member of the team, the 'customer'. In traditional XP this is literally a representative of the person paying for the system. In XGD it's typically the project lead, or producer. They get a fortnight's worth of budget to spend on the stories they want to see in the next, working game in two weeks. Unpicked features go in a pile for future versions. In this way we concentrate only on the most important features, and are constantly re-reviewing what is essential, and what is only nice to have.
Detailed Planning
Now we know what we'll be doing, detailed planning can begin on those stories and those stories only. This saves effort doing detailed planning into stories that may well never happen. Each story is split into individual tasks of no more than a few hours work, each of which goes on its own index card, with discussion notes and diagrams to flesh out what is needed.
Tasks and time estimates are then assigned in a simple way – each developer grabs a biro and writes their name on the tasks they most want to do, adding an estimate of how long it will take. This results in surprisingly few fist-fights, just the occasional rebalancing. As each estimate is only a few hours and is made by the person who's going to do the work, it's as not-wrong as you can hope for.
And that's planning. It takes somewhere between a morning and a day, but at the end we have a chunk of work that we can reasonably expect to complete in the next fortnight, a detailed spec, and a time estimate that at least has a chance of being accurate.
14 Days Later...
At the end of every fortnight a polished, playable, bug-free game containing only those features listed on the cards, and suitable for sending to the publisher for feedback, is produced. This forms the basis for planning the next two weeks development, bringing back the untouched story cards and adding any new ones we've thought up during development. This rapid iteration lets us focus on what's good, and trim what's not. Some features never get implemented and stay at the bottom of the pile for the whole development, but every two weeks we're doing what adds the most to the game, and at least we know we didn't waste any time on features that ultimately weren't needed
One other thing comes into every few planning meetings – a retrospective. This gives us the chance to reflect on what went well, what we could do better, and how we should adjust our development methodology in future to avoid these problems. You could call it a post-mortem, but that would rather unfortunately imply that something had died.
Fine-Tuning
Right everyone, grab your task cards and disappear to your cubicles. We don't want to see you for two weeks! Is not what happens next. Just because we know what we're doing doesn't mean we'll do it right, so XGD has a number of features to reduce Development Wrongness.
♦ 1. Test Driven Development.
This one takes some getting used to, but pays enormous dividends. Before writing a function in the game we make a little automated test that will check that it's working. Once we see it failing, which you'd hope it did because we've not written the code yet, we write the code and watch the test pass. Hurrah! Or not, because often either the code or the test were wrong, but at least we noticed.
Once written that test keeps being run for the rest of the project. If ever your original code stops working – well, you know about it straight away, not when some unfortunate player tries it in several months time.
Writing good tests takes practice; You don't want every change to a class to need a change to all the tests. We aim to test all our public functions, but trust the private stuff to do the work. In this way we only have to change the tests when we change the class interface, and it can implement the functionality any way it wants.
It's important to know that automated tests do not replace QA and playtesting, but they make sure you're building the system on solid foundations. Reported bugs are tackled the same way, with a test that exposes the bug first, then the fix. This makes sure it doesn't rear its head again.
♦ 2. It Always Works.
Although we have polished versions at the end of every two weeks, we can take a working build at any time. We have a machine dedicated to building every configuration, and running every test all day every day. If your check-in stops it working, you fix it immediately. Build failure is subtly flagged by a booming proclamation from an electronic Brian Blessed we keep in the corner.
Bugs are also fixed as soon as they are found, taking priority over starting new tasks. This constant fixing prevents the large build-up of problems at the end of a project, and keeps our estimates accurate as bug-fixing time gets built into the schedule.
♦ 3. Don't Repeat Yourself.
In code, this is just good practice. You don't copy and paste code, you refactor into a common function. That way bugs are more likely to be noticed, and when they're fixed in one place they're fixed everywhere. It's always worth taking the time to do something properly.
In wider development terms this means automating any donkey work. We have autocomplete, macros for many common operations, shell scripts for art and build processing and so on. The computer is wrong far less often than a bored developer.
♦ 4. Pair Programming.
XGD's most unusual practice is to have programmers sitting next to each other at the same development station, working on the same task card. One has the keyboard 'driving', while the other is 'navigating' a process that involves thinking about the design, fielding questions, spotting mistakes, using the devkit for testing, finding advice on the Internet and so on.
Pairs swap roles frequently, with one developer writing a test and the other writing the code to pass it. During the day the member of the pair who isn't signed up for the current task will swap onto a different task, so developers also move around the room.
Although this may seem like it should reduce productivity, it provides many benefits. Code has to be clear enough to be understood by another person, and many bugs at the design level are caught before the cursor leaves the edit line. It is slower to produce code, but having at least two sets of eyes look over everything means that you rarely have to come back to it later. You also don't hit a wall; There's always someone with fresh ideas and a new perspective that can get things moving again.
With each coder on every task, knowledge of the whole system percolates through the group. This stops duplicate code being written, and means that work can always continue through illness or holiday.
Artists also perform pairing, although of a looser kind where they share a desk so that they can see what the other is doing and get advice if needed.
All these techniques reduce our level of wrongness, and so our risk. The game is on time and on budget because you can always stop when the deadline arrives and it'll be working. It might not have all the features you originally wanted, but those you do have will be of production quality, not rushed for a deadline.
A subtler, but useful benefit is improved developer confidence and morale. Progress is visible, tangible. You know you're going to hit your ship date. You know the change you just made didn't break the game. It can actually be played almost immediately, getting better story by story. Good ideas can be added at any point in the process. Involvement in the planning process gives a sense of empowered control, rather than detached helplessness.
For similar reasons, the publisher is happier. They can see the game make progress and actually play it. Corrections can be easily incorporated. The game will be ready on schedule, and there are no nasty surprises.
What's Not To Like?
Sounds like it's perfect. Well, it is good and it's the first system I've used as a developer that feels like it was made for software, not circuits or bridges. However, there are some drawbacks.
Some aspects of games are just very difficult to write tests for. How do you reliably and quickly test that a random element in a feature is working? Brrr. Still, having some tests is better than none, and it's important to remember that you still need QA, it's just that they get to find the interesting bugs not the basic stuff.
Also while it's a highly efficient system for developing software, but other important jobs such as coming up with new game ideas, or creative tinkering with better ways of doing things will be missed unless you explicitly schedule time for them. During 'dead' times, like a long re-compilation, you generally talk to your partner, rather than browse newsgroup discussions or the web. While this is admirably sociable, you can also lose awareness of the wider world.
Scale is also a question. There are a dozen of us in our team, and we all work in in the same (admittedly large) room. It's very easy for each person to interact with everyone else. Because we swap pairs at least twice a day, it's easy for everyone to have a good idea what's going on in their own discipline, and a fair idea what's happening in the other. I doubt it would work well if there were two-dozen or more of us, or if we were spread across multiple sites. In such a situation it'd be better to parcel up jobs into chunks, then use XGD on the smaller sections.
All told, I love developing with XGD and I'd find it hard going back to the old hack-it-and-hope, or plan-then-ignore techniques. I'm still wrong a lot, we all are, but at least I know that it can be put right, and at the end of the development cycle I know there's going to be a good game because I've already played it.
Boxout - Extreme Game Programming Tips & Tricks
Planning Numbers
Who is best placed to tell how much effort a story will take? The person who is going to do it, so it's a principle that those with the most knowledge decide the relative cost of the stories. After a brief discussion of the feature and its scope, with relevant points noted every developer decides on their time estimate by choosing an appropriate card from their planning deck. Cards are then revealed, and if there's a large range then the lowest and highest estimators get to put their case, often highlighting problems with the story or shortcuts we could take, and the estimating happens again. Numbers quickly converge, and an eggtimer stops the system devolving into endless debate. Oh, artists and coders give separate estimates as their time usage differs so wildly. The numbers on the cards in the planning deckfollow the fibonacci sequence, as the accuracy gets more wrong the larger the task.
Planning Points
How many points can the customer spend? Well, it's a bit of a guess at the start of a project, but when we repeat this process, as we will every fortnight, the size of the next fortnight's budget is the same as the total for the completed stories from the previous fortnight. Over time, this compensates for estimation problems, illness, bugs and so on.
Progress Tracking
The story and task cards go onto a board in the development area in priority order. When a task is started, it is moved to the active area so everyone can see what is being worked on. When complete, it moves to the done column. When all tasks for a story are complete the project lead reviews it, then the story card is also done. At the end of each day every developer adjusts their estimates up or down to reflect how much work remains. The total hours of left are added up, and this goes on a chart on the wall so we can see if we're going to get it all done on time. If not, then the bottom story will get bumped off the chart. It's better to have fewer, complete features than a larger number of buggy, half-finished ones.
Mini Bio
Andy Krouwel is currently lead programmer at Silverball Studios. He has been programming for ever, roughly, and has developed games of Nintendo, Atlus and Ubisoft.
