Extreme Game Development pt1: killing crunch

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 look 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
Let’s talk broad-and-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 good 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 in to 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
But don’t think that’s the lesson over – don’t just grab your task cards and disappear to your cubicles. That 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.

[Image credit: http://media.oldben.com]