Big Ass Design Documents

Posted on , updated on by Jeff Tunnell

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“.
Big Ass Design Document
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

  • http://fosters.realmwarsgame.com Logan Foster

    A couple of years ago I worked on a serious game project and the client's designer created a tome like you described to cover the project. With regards to creating a game, the information contained in the document could have been summed up in 20 pages, not the 200+ that we were supplied with. Looking back at it now, their design document was a crux to cover the lack of experiance managing a software project such as the one that we were contracted to work on. The designer needed to feel involved and justify their paycheque and value to their employer, but all they really accomplished was hurting the project because they failed at properly conveying the information to the development team.

    Information is power. Information is needed to make a game properly so that everyone is on task and working together as a team (as opposed to following shiny objects off in the far distance). But too much information, such as what you see in these massive design documents only creates information overload and confusion and if anything limits the fun factor in the game because the project gets boxed into a rigid set of boundries as opposed to having the ability to push and manipulate their confines into something that best suits the space the project needs to flourish and succeed.

    At least thats my 2 cents ont he subject at the moment.

  • http://coderhump.com Ben Garney

    Our current “design doc” is about ten pages in google docs, plus a dozen square feet of white board space. We make sure to sit down and talk about the game regularly. It works out well.

    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. – This is an awesome way of looking at it. An organizational system exists to work for you – not the other way around.

  • jgostylo

    The site you linked had a link to a great power point presentation on making good design docs. http://www.zenofdesign.com/2008/02/23/how-to-wr…

    It mentions using automated processes for your design doc creation. Are there tools available that do something like this already or are most of these automated processes just developed in house?

  • http://www.makeitbigingames.com Jeff Tunnell

    Here is a link to a photo of our whiteboard “design document” for Grunts. http://www.flickr.com/photos/jefftunn/312153832…

  • Craig Fortune

    Bit late to be adding here, but a pet peeve of mine is what I think are most accurately described as “retrospective design documents”. This is where designers put into design docs things that have already been implemented etc.

    Now I'm all for looking back and evaluating a project and seeing he pros/cons of certain decisions that were made, however I find it a joke to try and work these back into the design documentation in anyway other way than a record/log of features etc.