Game design documents are almost universally terribly boring to read — a paradox considering they’re describing something fun. That’s because they describe every part of the game in a lot of details, just like software specs, and software specs are boring.
What we need is to describe the experience we want to create, rather than the piece of software that will create that experience. It occurred to me that the best way to do this would be to write design docs in the form of a walkthrough of the game: describing everything in the game as the player sees and feels them, introducing new gameplay elements at the same pace and order the player encounters them. A bit like movie screenplays: they tell the story and it’s for the movie-making team to determine how to make that story on paper into a movie on a screen.
That approach would make for a much more readable design doc, so members of the team would be more likely to read it (something that happens too rarely with traditional design docs). It would also be easier to get a feel of the game to see if it has the potential to be fun, and some problems with approachability and pace could be resolved before production even starts.
On the other hand, the document would be harder to refer to — if you’re looking for the behavior of one specific enemy, there wouldn’t be an easy-to-find section called “enemies” to refer to. That means more work for planning and separating all the tasks to be done. A separate reference document could be useful for this. It wouldn’t be made to be read from start to finish, but it would contain all the technical elements that are needed in a format that’s easy to refer to. Writing the design as walkthrough would also be harder for non-linear games — how could you cover Civilization entirely that way? — bu that wouldn’t be an issue for most games.
That approach would be a radical change from the established approach: as far as I know, nobody writes design docs in that way. I think the potential for higher quality of design outweighs the cons, so I’d have to try it out to see if it’s still the case in practice. Any thoughts?
June 2nd, 2007 at 6:01 pm
Just a note to say sorry for the long lack of update. I had a problem with Wordpress that prevented me from posting anything and it took a while until I made the effort to resolve it properly.
August 11th, 2007 at 12:54 pm
You need both. One doc that describes the experience, and one that describes the mechanics that lead to that experience. (Microsoft calls it the moment-to-moment walkthrough in their concept submission paperworks). It’s much like a recipe for a meal … the picture in the cookbook catches your interest, and the list below tells you how to achieve that experience.
The art and craft of Game Design is to convert a desired experience into a set of rules and an environment in which those rules can be applied. In most projects the desired experience only exists in the designer’s head, which is okay, if he’s skilled enough to break it down into basic rules and aesthetics that will eventually deliver the experience he aimed for.
And I agree with you that a document describing the experience will get the people who work on the game more exited about what they do than just reading the list of ingredients. But in the end you need both.
August 11th, 2007 at 1:11 pm
It’s interesting to hear Microsoft’s been using something similar. I think you’re right that you need both. I’ve been considering the idea of making the walkthrough part a traditional document, but making the mechanics part a wiki. With a wiki, it would be easier to keep it up to date and to do cross-references.
Of course there’s also the issue of getting enough pre-production time to do all of this properly…