Brenda Brathwaite recently posted an excellent article on creating a game design doc. Her best advice:

Before you start writing, consider is your audience. Many new designers write documents as if they’re being written for gamers instead of a programmer who’s tired, annoyed and up at 3 a.m. coding your combat system…

So true! Even if you’re just writing implementation notes for yourself, this is an important thing to keep in mind. When there are a lot of complicated rules going on, it’s easy to get bogged down with loose ends when programming the implementation. Unfortunately, this sometimes means important details get overlooked. A careful and detailed list of requirements without a lot of extra hype cluttering it up is invaluable as a checklist when the going gets rough. It will help prevent anything from being missed.

Writing the right amount of detail is a fine art. You need enough detail to make sure everything important is explicitly defined, but not so much that the document becomes so overwhelming that you–or your team–will be tempted to just skim over it when you refer back to it later. Personally, I’m a big fan of writing design docs in html help file format, mainly because most of the editors force you to create drill-down type topics instead of writing the document linearly. Incidentally, many of the editors will also let you save to PDF or other file formats… it’s not the file format that’s important, as much as the concept of writing hierarchically instead of linearly.

Hierarchical format is very helpful when implementing because it allows you to keep track of the big picture with fewer minutiae details in the way while blocking out the architecture, yet you can focus in on the important-yet-tiny things when you implement the specifics. If you have the discipline to do it, keywording individual topics is also immensely valuable as the document grows in size. When programming large systems so many components end up more interrelated than people realize, and good keywords are another tool that help find everything important when you’re coding it up.

The Designer’s Notebook: Bad Game Designer, No Twinkie! IX by Ernest Adams is up over at Gamasutra. If you haven’t read the column before, it’s a checklist of bad design choices that will frustrate the heck out of your players. If you missed any of the last eight episodes, you can find a database of all the points here.

This year’s column is particularly good. Points covered are:

– Failure to Explain Victory and Loss Conditions
– Time-Constrained Demos
– Obvious and Cheap Reskins
– Computer Crashed While Saving? Game Over
– Friendly AI Characters That Do More Harm Than Good
– Fake Interactivity
– Bad Gamepad-to-Mouse/Keyboard Conversions
– Setting the Player Up to Fail
– Your Only Save is Immediately Before Your Death

I’m hard-pressed to disagree with much that was said with the exception of time-limited demos. Most of the time, I agree, that time-limited demos are a bad idea. I’d rather have a content-limited demo. If the game cuts me off too soon I can’t tell if I liked it or not. That said, I’ve seen cases where time-limited demos have worked very well. For example, I think PopCap does an excellent job with time-limited demos. I’ve bought several of their games when the demo cut me off and I was eager to play more.

I’ve given some thought as to why some time-limited demos work, and some are just irritating. I think the key difference is not just whether or not the player has had enough time to enjoy the game before the demo runs out, but whether or not the player has had enough time to understand the game before the demo runs out. A casual puzzle game can be understood in a few seconds, and most of the demo is spent finding out if you like it. For an adventure game, you might have to play an hour or more before you understand the mechanics well enough to actually play. If the whole demo is spent learning how to play, you never get enough time to find out if it is fun.

The last point in the article, “Your Only Save is Immediately Before Your Death”, is a really important one. I think we’ve all been bit by this at some time or another; I know I have. You load the game from your save point and die before you have a chance to even do anything. After 10 reloads, you realize you might as well delete the save file. Ernest doesn’t mention it, but this is a critical consideration if your game auto-saves! If you auto-save, be warned that you may have just killed the player permanently if you are not careful.