People tend to roll their eyes at the idea of making design documents for small-scale game projects. Fair enough: screwing around for a few hours to make a generic platformer doesn’t require the care, precision and co-ordination of, say, an Army of Two co-op snipe — it tends to be a more casual exercise with no concrete direction.

This in itself is okay, but creating a “lite” design doc for even your simplest of endeavours can move it from the realm of “something crappy and experimental” to the hallowed fields of “something crappy and experimental that has everybody going insane”. Taking your game seriously (or at least taking the time to document stuff) will benefit your final product immensely. The idea of becoming a more organised dev doesn’t guarantee passage to Awesomeville, but at least it can get you in the queue for a ticket.

For a real design doc, it helps to remember what you learned in those InfoSys lectures...

For a real design doc, it helps to remember what you learned in those InfoSys lectures...

For a start, lite docs offer you the opportunity to clearly realise your own game goals. In the same way that crafting a one-sentence summary of your game is a notable marketing must, the ability to jot down and regularly refer to a few of your overarching design goals can be surprisingly valuable for the game creation process. Want to add a new enemy? Check your goal list: if it emphasises momentum-based platforming action, then you can design an enemy to slow you down or bounce you away instead of doing something cliché like firing bullets.

Scribbling these core goals somewhere, even if nothing else is added to your documentation, can help you fight off looming feature creep: throwing random movement schemes into a game intended to be purely deterministic would be a bad move, yet it’s one that’s startlingly easy to make if a written reference isn’t handy. And when the game gets bigger and more complicated, you may not always remember the reasons why you’ve gone in a particular direction: plans made at the beginning of a project may well become blurry or even forgotten by the time you’re halfway through. This, more than anything else, can cause undesirable departures from your core “game plan”.

A design doc is also just a great way of forcing you to think through a game in advance. Sometimes, a project’s balance or progression can be vastly improved with a few scrawls and some pseudo-maths without writing a single line of code: for example, taking a page to summarise all potential enemies and their statistics helps you spot and fix undesirable effects before they emerge in-game among a bunch of more dissociated game objects and states.

...but an indie hobbyist's "design doc" can be hacked together in any form desired, for any purpose needed!

...but an indie hobbyist's "design doc" can be hacked together in any form desired, for any purpose needed!

Remember: a lite doc doesn’t need to be “proper” in any way. It doesn’t have to be a cast-iron set of rules that you adhere to. It can take the form of a comprehensive game plan, a stats sheet or even just a to-do list (if your game reaches any level of popularity at all, you can bet that there will be far more feedback and suggestions than you can easily remember). You can use a tool like WikidPad to organise your thoughts, or just fire up a handy copy of Notepad and start jotting down ideas.

The ability to communicate and store your ideas is an important life skill, so why not apply it within the realm of game dev? It’ll help you out immensely — both now and later.

More stuff like this: