Death of the game design document

It has been called many things over the years – GDD, Design Bible, Game Overview Document. Regardless of title, they all describe one thing; the living design document for a video game. The GDD has been a pillar of design direction for decades, providing countless developers and artists a singular vision for a game. Sounds great right? Who wouldn’t want one place to store everything there is to know about a game?

I wouldn’t.

I joined the game industry in 2008, fresh out of university and with big dreams. Going into a well-regarded independent studio, I was ready to set the world alight. My three years at university taught me how to write the best documentation and effectively communicate with different team members, which meant I was sure to be a great game designer!

To start with I was right: Our design team worked closely with EA, who at the time wanted rigid design documentation, with briefs upon briefs and documents on documents. Perfect! I can nail this design malarkey. And for a year or so it worked. We shipped solid, formulaic games, meeting all the requirements set of us and didn’t rock the boat. That began to change as we rolled into a couple of new, more creative projects for 2010.

The old ways I’d held so dear and believed in so much had started to crumble away. The idea of writing thousands of words about a game that didn’t exist started to feel maddening, with so many untested concepts sitting on top of one another like a wobbly house of cards. It would only take a small gust of uncertainly to topple them and bring down the whole project.

In the early months of 2010 the studio I worked for had a game cancelled, not 100 per cent due to poor design, but we knew it was a factor. That hit home. It really began to sink in how our method of writing huge documents, expecting creative artists and developers to read them and happily implement our ideas, was fatally flawed.

So why don’t GDDs work?

1. They make too many assumptions

The premise of a design document is it is exactly that – a document. It isn’t a game fragment, it isn’t proof that an idea is great, it is only the idea. This simple exploration of ideas in Microsoft Word prevents them from ever being truly proven. Along the way many assumptions will begin to be made and your product is now based on some fairly shaky foundations.

2. They are always out of date

Let’s say that we’ve written our wonderful document and a developer has implemented it. We now find that a collection of features need to change. At this point not only do we have to provide guidance to our developer but also begin pulling apart our document in order to update it for future reference.

Every time you make a change in the game you have to update your documentation. An unending circle of edits and corrections. All time that could be spent helping with code, creating assets or balancing. Useful things to help the team and the product. I can guarantee that if you look at your design document right now it will be out of date in at least one major place.

3. No one reads them

We are always told that management need a GDD. They are proof that the game idea is thought out and well researched, and that there is evidence of all the preparation before development (preparation that we usually have to rewrite).

Great, but how many times are they actually read? All the time? 50 per cent of the time? Probably ‘never’ is the answer. While it may be a requirement, executives, producers, or leads of any kind almost certainly don’t have the time to read your 50,000 word document and probably don’t want (or need) to.

But what about the developers? The artists? They read every word right? Nope. Most of your team have a good idea of the game you’re all trying to make and won’t need all of the detail you’ve stuffed into your document. They want the points that are important to their work and that is all. Time spent reading and rereading is time not spent on making a fun game.

4. They are too rigid

Design documents by definition aren’t open to interpretation. They aren’t doodles on the back of a cigarette packet for someone to interpret. They are detailed diagrams and blueprints for an idea that have to be implemented by the numbers otherwise that design falls apart. This rigidity kills creativity in the team, saves it all for the designer, removes by-in, and builds a wall between the ideas and implementation.

5. It doesn’t allow for failure

Fully designing a game in document form means so many elements have to be decided before you have even written a single line of code. By the time development begins to reveal errors or problems an entire production has formed around this singular vision, meaning a huge cost for any core changes to the concept.

What’s the alternative?

There is no escaping documentation in some form. You have to get something on paper otherwise you’re developing in the dark, but that doesn’t mean we need a bible to guide us before we start on our path to game development glory. All we need is some guidance, a few signs to help us on our way. So when putting finger to keyboard think about these points for your future documentation.

1. Keep it light early on

An idea is still an idea until it is proven. Keep documentation to an absolute minimum. By minimum I’m talking a single sentence. Define what you need in order to prove the idea and make it happen. A way I find useful is the ‘user story’. A simple story that explains your idea and why it’ll be fun or interesting. Keep it in the guise of a player. "As a player I can do x with y in order to feel z".

2. Keep it agile

Working with little or no documentation means you aren’t waiting for your designer to finish their epic tome before you can test out the idea. Jump into paper or simple digital prototyping so you can fail early and fail often. No design document has ever been correct first time. So waiting to find out an idea doesn’t work after weeks or months of documentation and preproduction isn’t good for your project or your studio.

3. Keep it collaborative

Don’t sit in a corner for weeks writing your finest works. This kind of "lone creative" style of game development should be and hopefully will be consigned to the history books. If you work in any kind of team in the game industry then anyone in that team should and will be as passionate about games and design as you are.

Instead of controlling the design with sprawling documents, work to discover and solve issues together. The deeper your team’s involvement in the design process the closer they’ll feel to the product and the better that product will be.

4. Research and record

Once you do produce larger sets of documentation they should come in one of two forms: research or recordings. Documenting research on a particular subject, if kept light enough, can be a great resource for aiding decisions as a group and guide the wider design of the product. Recordings are the real definitions of the game’s design, and are the results of design conversations or prototyping that fully define the direction of your product. These are documents you can refer to when being questioned on decisions made around the design of the game.

5. Don’t do it in Word

If you must write a design document of some kind, do not craft it in Word. Don’t get me wrong, Word is a good tool (I’m using it right now) but it isn’t a tool for documenting a game. Its rigidity, closed nature and poor support of advanced layouts and imagery makes it unsuitable for design documentation. Keep your documents open, online, collaborate and most importantly – visual. Wiki’s, Prezis, Google Docs and other great forms of live documents are far better for rapid, visual documentation for all to see.

There is no design utopia

While I’d love to really put the nail in the coffin of the traditional GDD for good, there will be occasions where something like it may still be required. Outsourcing, third-party or multi-studio development will always need some form of central design documentation for reference.

Expecting everyone to join the collaborative, document free commune may not be realistic but there are always ways to challenge the status-quo. Try new ways of documenting, break free of the shackles of Word and bring a fresh approach to the dying concept of the GDD.