Thoughts on Game Design Documents

        There comes a time when you're producing a game, you look for a feature, only to find that there's a lot of ambiguous information regarding its function and overall use/implementation. Often an issue in any design document, its a concern , after all having all the answers so your team can do what they need to do, maintaining the core of your product, is the most essential element of any game design document. However, when is to much, simply to much? Executive summaries, financial plans, marketing directives, prose for the first parts of your game, etc. Is all of this necessary? Who's going to actually read it? 

 

        The basic building blocks of any document should involve 3 major things, the way I see it: Core Statement, written for your team who read it, and lastly, no ambiguity (though that doesn't mean there is no elasticity in what can/cannot transpire with regard to mechanics and what not, there shouldn't be any direct questions regarding whats suppose to happen, or how things are suppose to work with any given feature or scenario). Clearly, I'm not alone in that sentiment, as others like Brenda Brathwaite with her take on ambiguity and core statements, or Tom Sloper with his belief indetail and even Black isle studiosleaked Van Buren documents present a clear standard.

        Over time, however, it's become apparent that game design documents have become biblical – only in the sense of their immense size. It's not uncommon for publishers and other departments to have a say in the overall GDD, and often end up including a wide array of things that simply aren't necessary or beneficial to development – clearly I'm of similar opinion with Mr. Tadhg Kelly. There comes a point where everything that your document is about becomes veiled by clutter – elements that no one but executive would ever look at, if they weren't already busy listening to you and watching your presentations instead. No one in the design team is going to care, and they're the very people these documents are really meant for.

         Of course, there are other developers who have their own opinion even on that – these documents are worthless in their eyes, something they feel is a waste of time to write, according to Joe Danger's Sean Murray. I admit, there's a certain appeal to game design as a form of purely elastic, reiterative prototyping, rather than design documents backed with concept artwork galore. Raph Koster has a great article regarding less design documents, art, and more prototyping, like in the image to the right – as well as learning to make products cheaper. It's certainly insightful, and definitely relevant in a world where games can cost as much as fifty million and higher – in the hundreds of millions, as it did with Star Wars: The Old Republic. 

        Ultimately, there's always going to be room for design documents. They're truly beneficial, though only if they continue to focus on the design, remain elastic, and revolve around prototyping (even if that prototyping is some flash cards and paper cut-outs). There's a point where we seem to get focused on the 'idea' of what we like, rather than on the implementation and functionality of 'fun' with those ideas. While it's clearly not everyone's cup of tea, a good foundation, and a good place to finalize information that you're actually using as you prototype and iterate your designs.