Cutting the Long Chain of Change

[Sick and tired of seeing your ideas get butchered? There is a solution, but you'll have to abandon the notion of them being solely your ideas...]

For many of us the process of game design (and I include level design in this) is one where we breathe the initial spark of life into a part of the whole, such as a creature, by specifying everything that needs to be known about it, except the details that other departments can or must contribute.

Once the spec is done, art must take your work and run with it, literally fleshing it out so that the beast can enter the game world. Code has many tiresome tasks, but there's also a considerable amount of craft that goes into making this monster roar and not rank. You can replace the creature in this example with any game element you choose, from a mechanic to a level, a character to a weapon.

Sadly, all too often, this process is somewhat fraught. Design seeks "sign off" from the other two disciplines and once that is gained they hand off the work. It then travels down the line, reaches the end and turns out to be sub-optimal in some way. Fingers are then pointed, work flows are disrupted and all relevant staff, from all departments, gather to figure out how to make the blighter awesome, rather than awful. Everyone sits down, discusses solutions, works out an action plan and, assuming time doesn't run out, makes the creature a compelling part of the game.

The problem here lies entirely in the work flow, and the problems start at the point where the designer places their last full stop and utters "my work here is done". At that point they must court the other departments to sign off on the detailed specification for implementing the game element.

When art and code sign off on something the theory is that they're rubber stamping it, asserting that they think it's something they can create (in the case of art) and implement (in the case of code) in the time available. But there's an assumption in this process that everyone takes the "sign off" seriously enough for it to work, and that simply is not the case.

Sign off was a problem when we all used waterfall methodologies, but it can, potentially, be even less genuine in agile development. With waterfall the sign off process is, notionally at least, taken very seriously and signing off on something is tantamount to scrawling your moniker in blood when Satan pops round for sponsorship - "I'm doing a fun run, everyone else has sponsored me a soul each so far. Yeah, if you can just open a vein and sign there."

It should bind like cheap underwear in hot, humid conditions. Even so, it doesn't work very well; people simply assume they will be able to revisit the broken things again at some point in the future, in epic tracts of post Alpha "bug fixing". But in these agile land there are some that sign off with their scrum fingers crossed behind their back - "Sign off? Yeah, whatever - if I find a problem later I'll just change it, cos I'm agile." This is not a conscious thought process, it's simply a by-product of the methodology. In reality, "sign off" is a flawed notion in agile because it doesn't belong there, it's purely a waterfall concept. 

Once the other departments sign off on a piece of work it's time to advance to the point of genuine separation and hand off your work. This is analogous to being a sea turtle. Working through the night you labour hard in a semi daze, building a nest, laying the eggs, which you then cover with perfect precision. Your offspring formed and packaged for success you are then on your way to other tasks. Your young hatch as perfect little turtles, they are amazing and they run free.

But you have handed them off to the world, you have left them to fend for themselves, and various fates will befall them in the absence of your attention. Some won't even get off the beach. Some will thrive, but these will be few. Some will be killed, often when they are young but some will be quite mature when a grizzly maw cleaves through their shell. Sometimes, the worst fate is reserved for those that are mutilated or perverted.

The next time you see one of these unfortunates they may be dressed in a bellboy uniform and being made to dance for Paris Hilton on a reality TV show. Or their shell may have been scooped of its flesh, polished and used as an ashtray on a luxury yacht. It's not a pretty sight. Some can be saved, but some cannot, for the wounds are too deep and too horrible to look at.

I don't want you to think that designers are innocent in all this, they can be complicit in the problem. When GM attempted to distribute its considerable learning from their their joint venture with Toyota at the NUMMI plant there were problems at every turn. One of these was the feedback of suggestions from the production lines of the various factories back up to the designers, be it of cars, tools, machines, anything.

At GM everyone was used to designing something and then, as Ernie Shaefer describes it, they would "throw it over the wall". Sometimes designers actively refuse to acknowledge suggestions and requests coming back up the line to them, but this is rare and should always be stamped on. However, design doesn't have to be actively obstinate to act like this, it's possible for it to be unresponsive simply because it is busy, diligently working on the next bit of information to throw over the wall. Whatever the reason, the result is always the same, the designs are handed off and any changes that have to be made are done without consultation, and bad decisions are made.

At the end of the long chain of change we get bad results and the remedial fix system must kick into action.

So, if sign offs and hand offs are doomed to fail, how do you proceed? Simple, don't have a sign off process between departments and never, ever hand anything off. Instead, work as a team from the beginning of first jottings, right the way through to the completed implementation and beyond to the tuning and bug fixing.

In the early stages this actually means less work for the designer, as the flow of ideas and definition of structures is much faster in brain storming sessions than it can ever be for one person sat there pondering... hmmm. Problems are solved in the design phase because there are no nasty surprises waiting for art and tech, there can't be, because they're sat right there with the designer, flagging them and felling them at the moment of conception. Any time saved in this gestation process naturally frees up time later, for iteration and fine tuning.

Of course, there will still be problems, but because all departments share ownership then none will ever move to change something without complete consultation of the others, which means that the solutions will be infinitely more robust. Nothing gets thrown over the wall, and no one gets hit on the head by someone else's decision.

In agile development this is called a cross-functional team, but Valve call it a Cabal, and they know what they're talking about. However, you don't need to apply this to building levels, as Valve do, you can apply it to anything which can't be done without support from another discipline. In an ideal world you'll be sat with the other creators, but even if you can't the weight of support for a piece of design that has multiple champions, each from different disciplines, is orders of magnitude more powerful than a lone lobber behind a wall.

I described this process in the second paragraph, but as a common tactic for fixing problems. So why not skip straight to the cross-functional team approach and do the job right the first time around?

You'll save on all the interdepartmental bickering, at least the nonconstructive 50% of it. You'll save time, not just in terms of raw work but in analysis and feedback overheads. You'll save face, because the results are more complete in the first place. And you'll have those liberated resources available to make a better game.