Design Documents

Design documents are a pain to create but are the best references that designers can create for the team. I’d recommend to take at least a month and write down every little design aspect. The best documents are hundreds of pages long!

During this phase you should be able to tell whether or not your game is too ambitious for your team. If it is try to cut out gameplay features. There’s always room to add those in for a sequel. 😉

With The Divine, we built the engine before the game itself was fully designed. We knew that we wanted a space shooting game but we didn’t plan to put in special effects and the sort. Inadvertantly the coding is a little messy and locating a bug is becoming rather difficult. Now if we knew ahead of time every little aspect that we would need in-game we would have been able to write a more efficient engine that would suit our needs. But oh well we’ve learned from our mistake. Make sure that you do too.

2 thoughts on “Design Documents

  1. I couldn’t agree with you more.

    It’s very tempting for inexperienced game programmers to overlook the need to “think it through”. This can apply even to programmers who ARE experienced, but not with games!

    Games have a much larger design space than most computer applications. If you breezed through academia and think you can sit down and code ANYTHING, you’re in for a rude awakening. Any kind of highly interactive, explorable simulation world is going to shock you for the *sheer number of relationships* you must manage. The complexity of this system grows geometricly with the number of components. In fact, games are about as hard as operating systems, only WITHOUT the decades of prior research behind them.

    The point of writing the design doc is not so you can get everything right so you can just program to predefined specs. Lots of things will go wrong when you try to implement even the most carefully written spec. However, having a detailed design doc means you will have explored a big part of the design space beforehand.. this is much more efficient exploration than waiting for your implementation to fail! When you have a real design doc, you can look at it any time during development, and say, oh yeah, I’ve explored this issue already, and these are the implications of doing that!