Eden B and I were discussing design docs yesterday. I think we agreed that going overly detailed is a bad idea, unless you have a large team and it's a professional game and everyone needs to have a game bible in order to work on it.
But if you look at the design documents of, say, Metal Gear Solid 2 (which has been released publicly, Google it), it's not very detailed, it isn't very similar to the final game, and it's just an overview or summary, it doesn't include every last enemy or every last power up or every room.
Here's the design document for my next game:
http://studioeres.com/rinku/index.php?title=Saturated_Dreamers -- I know I shouldn't release this publicly. Do NOT read it if you don't want the story spoiled, or if you do read it, please don't read the story section or the characters section, those will ruin the story for those who intend to play the game. But I'm linking to it so that I can show the length of what I use. It's not 50-200 pages long, it's about 10-20 pages long, it's a wiki so it's editable by anyone on the team, and that's usually good enough for most purposes. The first paragraph there is a link to the (somewhat outdated and now-inaccurate in parts) ID design doc too, which was more list-like, but was also pretty short.
The first major game I started work on, a RPG, had an 800 page design doc (I'm not joking) and was never finished. I think you can get too caught up in the design doc and never actually make the game, and having a design doc tends to lead people to making the game more ambitious than they actually have the capability or time to make. I used to be much more gung-ho about using design docs, recommending that everyone use them, but I've mellowed now after like 14 years later and realizing that they haven't really been that useful to me, and some of my best games didn't have them at all, and the games that did have the biggest and best design docs were never completed.
As for the idea of this list not being useful or not, of course everything should be taken with a grain of salt, and as I mentioned in the thread I came up with this list in (and I made this its own thread on I Like Cake's suggestion, but I agree that it's somewhat pointless if it's interpreted as a set of rules), I just did it quickly in two minutes as a rebuttal to that article about indie vs amateur, about how that article could have been more useful to people than it was. What I replaced it with wasn't perfect, but I think it was at least more useful than that original article.
The list also came out of years of playing really hastily made and poorly done Ohrrpgce and Game Maker games and noticing how they could be improved and be much more playable with very little effort, it's just that the creators of those games weren't experienced enough to recognize where they needed to put that effort; so yes, I was intending it to be more about polish than design, but that doesn't mean Guert's design tips are bad ideas, I agree with many of them, but I agree that they're less universal than polish tips. I mean, having a lot of playtesters and watching them play the game, although it can be taken overboard as Alec mentioned w/ Half Life 2 and Halo, is almost always a good way to improve a game, whereas having a design doc wouldn't always improve a game.
Community
