Return of the GDD [Game Design]

A new generation is falling into a very old trap: writing large game design documents (GDDs) in order to map out their idea for production, only to then becoming trapped by those documents later on. Most people who’ve worked in games a few years know that GDDs cause more trouble than they’re worth, but many folks newer to games don't realise the folly of creating them.

Here's why:

 

What GDDs Tend to Be

You have an idea for a game, you need to figure out what it is supposed to be in more detail, and so you start to write it down. You decide to codify the ideas, and so you reason that the project needs a central document or database that will act as a reservoir of knowledge. It will unify the team around a common cause, and the team agrees with you.

So you set to writing. What goes into that document? What should be left out? What is relevant and what isn’t? Who does the document need to satisfy, and who will need it? While at first all of these seem approachable goals, they often go awry.

It starts like this: Your producer comes to you and says that management needs an executive summary at the front. Your publisher comes to you and asks where is the first 15 minutes of gameplay written out as long form prose. Your UI designer comes to you and asks that a flow chart of opening menus be included in the GDD. Your coders come to you and ask for a section on the technical spec of the AI. Your artists come to you and ask for mood board material to be included. Your finance people come to you and ask that a business and revenue plan be included, and your business development person asks that that section be moved to the front because that’s most important.

Before you know where you are, you’re writing a bad book. It becomes a description of the whole project rather than a game design. It becomes more about proof and weight rather than establishing clarity. It proves to your bosses that work is done. It proves to the artists that they have not been forgotten. It proves to the client that their money is well spent. And so on.

What emerges out the other end is an amorphous, unwieldy and poorly written document. It is filled with contradictions and unfinished ideas, inconsistently formatted, has an impenetrable structure, and some paragraphs and pages are repeated in multiple sections.

Everyone involved in the project either cherry picks or outright ignores the document entirely. And so the the primary purpose of the document (to clarify the game idea into something actionable) fails because those who encounter it only have a partial idea of what the game is supposed to be. They don’t and won’t read the whole thing, and even those that do will not comprehend it fully.

 

Game Design is a Leadership Role

A video game does not need a thesis-length document explaining everything in exhaustive detail to an imagined audience. Documenting game detail in that fashion, before you really know whether the core loops of the game work or not, is like drawing up architectural plans with no earthly notion of the strengths and weaknesses of different materials.

By documenting heavily early, all you are doing is creating lists of things that are presumed to work on top of things that are also presumed to work. You are inferring complicated project plans based on systems which nobody has developed. You are initiating a budget for a thing of unknown size and scope, and that will lead planners and execs to set milestones based on these unknowns. And, crucially, you are minimising the possibility for prototyping to discover novel actions by tying up all the early development time with architecture and engine coding instead.

All in all, it’s a giant waste of time.

There are just four things that developers really need:

1. A direction that they can understand
2. A clear sense of what they are making and what they are NOT making
3. A path to production that they can visualise
4. A leader in whom to believe

To be a game designer is to be the one who reaffirms everyone’s faith that the project is going somewhere. That’s why the single most important skill that she needs is confidence. She also needs to be smart, creative and able to think in a systemic (as opposed to narrative) way, but most of all she needs to be able to make people believe in her.

Confident people get to the point, imparting confidence in other people as they do. They make decisions. They are committed and concise. They rule out way more things than they include, and they fight their corner when pushed.

Confidence is ultimately what gets a design from the page to the screen. While design involves some amount of writing, the designer’s job is not Essay Writer in Chief. It’s much more of a direction role, and direction is a live-fire exercise. It doesn’t come from writing things down to excess.

A long game design document is just an avoidance exercise. While it may seem like work it is not. It is just labour. Avoiding commitment in the hope that decisions will be made by default is a crappy way to design. It leaves the rest of the team at a total loss and some projects get lost in the wilderness for years because of that. Many studios shut down because of it, and many bad games get released because of it.

Leadership is not something that most people can do well, but it is vital. It starts by getting to the point. I'll be writing more about a method for doing that soon.

Comments

[Mpg4]

Stellar advice. Thanks for putting this so coherently. One of the main reasons that it's vital to become more dynamic - decisions - and less static - paper - in the approach to game creation is the sheer cost. In a world where there is less money we must become more creative and therefore make more decisions. We also need to have faith in our team.

[Flarkminator]

You write great articles here. A few months ago I was telling someone that nobody out in the 'verse is saying what needs to be said for game design, but it seems I didn't look hard enough.

Though I totally agree with you (http://www.flarkminator.com/?p=303) that people shouldn't be maintaining long documents, I feel they have a purpose. I find that attempting to write down an exhaustive pass on the game is beneficial in helping me spot, analyze, and plug holes in my design (oh right, monsters need to give experience).

This only works if it is FOR ME. If it is, as you say, a monolithic beast constructed on the whims of others, then it just soaks up my time and effort. I've definitely been there.

Thanks again for blogging. I have been back-reading slowly but surely =)

[Account Deleted]

Game design is like writing spaghetti code and hoping to find that bug that's a feature.

[Apps 55753818692 707621192 74268b06ef5761b4db7837fadceb904c]

Excellent post, thank you for sharing this great content.

[JaumeTeixi]

You're completely right in the 4 points but I would add an scope here:

i) An experienced GD has to be able to put these 4 points clear and in context up to his/her responsibilities (so with partners, managers, stock holders, etc.) and also down/parallel with (consultants, team, testers, etc.) before/parallel joining the game project.

ii) An experienced GD will be able to demonstrate that a good conceptual writing will follow a better full development and appropriate documentation.

iii) An experienced GD will know that always will exists some situations that before/after/side to, some kind of full GDD will be necessary and desirable (looking for credit, stock holders, recruiting staff). But also will be capable to write, probe and show that some features are pure conceptual writing and will be properly defined in development.

iv) An experienced GD will be capable to define short-term, mid-therm and long-term features in GDD.

I'm writing here because I'm experiencing something like this now ? ;-)

PD. I'm waiting the Blue Oceanomics of SG.

[Tadhg]

So are they. I hope to be able to get to it next week. I've been so busy and a bit run down in the last two weeks, but I think I'll be in a better space soon.

[Account Deleted]

I think there's a lot to be said for a good design doc. You're throwing the baby out with the bathwater to abandon them, for as many things as you list going wrong with a GDD, there's another set of problems that rise up.

Your central tenet, leadership, is correct. GDD or not, if a design is being written for everyone but the designer then there is a problem. Already that leadership is being undermined.

A good GDD can be used to reinforce leadership, and achieve the goals you mention.

A lot of smaller games are seeing incredibly short development cycles at pro shops - hitting the ground running with a clear, exact and concise GDD is a huge gain. Scope management is probably the single most essential problem in development, and a clear gdd can really help.

(All you need is an uber-talented designer to write a perfect one, right?)

[Simon Strange]

This is not new - it's something many people have understood for a long time. But this is, by far, the clearest statement of what so many of us have had to learn the hard way.

Great work.

[Jeremyspringfield2000]

Lostgarden.com has a post up about an alternative method for making sure that everyone is making the same game.