That’s right, Paisley, the specification

Ahhh, the software specification. Other than arguing over whether this year is the year of Linux on the desktop or not (it isn’t), never have I seen anything more contentious than the software specification: particularly those for computer games. I have seen specifications from 0 to 50,000 words. In the worst case, project bibles were involved. Project bibles are a genius way of being able to tell your staff at anyone can design a game and can have it produced without ever having to carry through on your promise. After all, for anyone to be able to make it through the nine tests of hell is such a challenge that very few people will make it past the gate of horror, let alone successfully traverse the long, miserable corridor of “peer design reviews”. Once all the creativity has been designed out and a project bible several inches thick is produced, everyone is ready for one last final go/no-go meeting where, funnily enough, it doesn’t seem like a good idea any more.

Long fish is long, indeed, longer than most specifications should be

At the other end of the spectrum is the seat of one’s pants approach. In this, there is no design at all: the project just “evolves”, usually into something that is a hotchpotch of so many ideas that it isn’t good at any of them. This approach of making it up as you go along only works with very small, tight development teams where one person has a vision and it turns out to be a good one – a scenario considerably rarer than me refusing a glass of wine.

There are so many fun ways to fail with a design document that this article can merely sniff at the surface. Take the “living document”, for example, where more time is spent documenting than working. If that isn’t to your liking, how about the one where several strong-minded people have overlapping ownership of various components of the design allowing the all-chiefs-no-injuns scenario to flourish like an unwanted fungal infection. This creates a working atmosphere that you can cut with same knives you’re using to stab each other in the back: now that’s efficient!

Somewhere in this broad spectrum of choices is something that works. A design not too small as to not contain any content and not too large as to stifle creativity along the way. This kind of design inspires those that work on the project by creating a really nice foundation upon which everyone can build: a design where different ideas can be integrated without ending up with a half crocodile, half octopus; a design that actively encourages the right changes along the way whilst discouraging shiny-box syndrome.

Most of the specification for my game, if one can call it that, is in the form of one diagram and notes on a piece of paper (although perhaps it could have done with being a fraction longer). I figured that if it needed a book to explain it would need a book to understand. Furthermore, this is an exercise in fun, not work and if it all goes tits up and I sell one copy no one is hurt but I had a blast along the way: I am not expecting to pay any bills with this game. Your situation may vary, but over complexity and misplaced detail is a killer. If you write to much at too low a level, you are quite simply inviting failure. One game project I recall had a one year schedule that was broken down into chunks sometimes only an hour long. It was late by the end of day one and you can’t even begin to imagine the leveling disaster that occurred after the first member of staff had a day off due to sickness. The real problem was that the scheduler was concentrating so much on the positions and orientations of the individual bricks that he forgot to mention that the intention was to build a house.

This is one of those three bears type situations where getting it wrong leads to one or more of the three grave digging assistants:

1. Strategy de Jour – a new idea every day!
2. Flogging a dead horse – the idea is doomed but ‘we’ve started, so we’ll finish…’
3. Blindly ignoring the bleeding obvious – the market has moved on but you’ve got a dying horse that is probably going to need flogging shortly

This is a fast moving industry and the business model, design and market that looked so sexy when you set off may have gained a few pounds and stopped shaving under the armpits. As I am overly fond of saying, the art is to be open minded but not so open minded that your brains fall out.

Unless you’re truly doing it for the giggles, getting your specification right is your best weapon for actually delivering something. Don’t forget to prominently feature the actual game when you’re getting carried away with the low-level stuff that’ll change so fast as to be worthless by the end of the first month anyway: focus on what it is, not the mundane details of how it’s done.