Marek Bronstring, a game developer that I met on Twitter, writes a blog called gamslol where he recently penned a post entitled “Game Design 101 Rant: Over-Reliance On Documentation“.
Many people have asked me what a design document should be, and while I am not going to write that article today, you can read about what they should NOT be in his post. Here are some quotes:
If you already knew that game design isn’t all about writing design documents, then that’s great. I like you. We should do the secret handshake. As for everyone else, I’m sorry that you have been misled, and hopefully I can help make some amends.
But sadly there’s a myth that writing giant Game Design Documents (GDDs) is what designing a game ultimately boils down to. This myth needs a thorough pummeling.
I totally agree him. What he calls GDD’s, I like to call Big Ass Design Documents, or BADD for short. I have seen design documents that look like the old ancient bibles that sit on top of family pianos. While the developers think they are really solving a problem, in actuality they are causing bigger problems.
Nobody reads those tombs, and they are so large that, like a government legislative proposal, entire developers are sucked up just keeping the document up to date. Worse, designers get pissed at the programmers because they still ask questions about the design even though the designer thinks the answer is in the document. “Didn’t you read the f***in’ document?”, is the common phrase.
Just like “Agile Development” is kind of the new phrase for doing what you want just about any time you want, I think Agile Design is a much better way to go. Of course, you need a certain amount of design documents, but having a designer that can communicate his vision and a producer that can carry it out is much more important than the bureaucratic process of creating and maintaining a BADD.
-Jeff Tunnell, Game Maker
Make It Big In Games
