*claps hands together loudly*
“Alrighty, who’s ready to read my 30-page GDD that I spent the last two days writing?!”
Yeah, me neither.
I’ve seen a number of game design documents get out of hand and become a chore to maintain and read. They end up looking more like a wall of text than a handy design guide. What the team needs is something that’s easy to navigate and takes them to the most relevant info as efficiently as possible. It seems so obvious in theory and yet it’s so difficult in practice.
Now, I’ve written a plethora of GDDs and probably a few hundred supporting documents for them, so I am no stranger to writing out design. I take on a new project every couple months, meaning I get to start from scratch, learn from my mistakes, and try new things often. It also means there’s a huge potential for me to be buried up to my neck in time-wasting writing when I could instead be designing the thing.
I’d like to share some things I personally do to avoid writing a soul-sucking GDD that takes over my life and wastes people’s time.
Starting the GDD
Wiki or a Word doc?
I prefer wikis for the following reasons: – Always current. If I can’t tell if a doc’s the latest version without digging around or asking someone, I die a little inside. – Easy to navigate. All the sections of the GDD are linked right there on the side. The devs can quickly get to any section without scrolling around or remembering page numbers. – Access control. In the rare event that I ask someone else to edit something, I can grant them access to just that section. – Encourages concise writing and division of features. I don’t know what it is about Word, but it tends to steer people toward writing long wordy paragraphs. We’ve given talented designer applicants challenges that include writing a small GDD for their design, and it’s astounding how many are formatted like a mini novel.
Whatever you go with, use a platform that supports writing the GDD in a way that it can be used as a convenient reference, not a book.
Defining Terminology
Once upon a time I designed a game that had missions. It also had warp missions. Then there were levels, which was a group of three missions. Levels were also called stars. Sometimes people called levels missions or puzzles. Whatever, I knew what they meant. No big deal.
Except that it was. By the time I got around to encouraging official terminology for everything we had wasted so much time going back and forth with each other to clarify what we were all talking about it would have been comical had it not been happening to me. Discussing design was like a real life Abbott and Costello skit.
These days I define terms right off the bat before writing anything. Does this game have levels or puzzles? Or are they called challenges, missions, stages, or worlds? Do we call a character’s history a bio or a description? What exactly is a “Turn” in this game? Pick terms and stick with them.
Establishing Ownership
Behold my mantra: “I am the Keeper of the GDD, Maintainer of the Docs, and Holder of the Key to all Editing Capabilities.” To preserve order, I am the only one who edits / adds to / removes from the design docs. It keeps everything in one voice, ensures proper use of terminology, and helps me know exactly what’s in there and where it all is. I serve as the funnel through which the team’s ideas flow into written form.
Same rules apply to massive teams that have multiple designers: establish who is responsible for the writing and make sure those people maintain ownership.
Maintaining the GDD During Production
Start Small
Keep the GDD simple and general, letting it build up slowly as production progresses. Only fill in niggly details after it’s been determined they’ll be part of the game. The game’s design will change a million times so don’t bother wasting words at the start.
Don’t Forget Separate Documents!
I use Google Docs a lot which can be edited live and are always current. They have a revision history, are easily linked to from the GDD, and are often looked at more than the GDD. The GDD doesn’t have to be the documentation’s home, it can just be the hub.
Document All the Text in the Game
I spent 5 hours last week procuring all the text from a couple games because we decided to have it proofread for standard English. It wasn’t all in one place, some of it wasn’t current, and a lot of text was just entered right into the game and never even lived in a document. Shame on me!
If you ever want to proofread your game’s text, do translations, record some voice-over, or if you just want to tweak things, make sure all of it is easily accessible (i.e., you can quickly give the text to someone else at a moment’s notice). Dialogue, tutorial text, descriptions… write it all down and make it easy to find. Learn from my mistake.
As I always say, “I don’t always retro-update my docs, but when I do, I update the in-game text.”
What Not to Do
Everything I avoid.
Don’t Write a GDD if No One Needs It
Not every game needs one. I’ve gotten by with just a one page pitch doc, a set of storyboards, and a list of user stories. Or nothing at all. GDDs are a tool to help designers do their job and provide extended reference for team members who need it. If the game’s small enough it may not be necessary.
Don’t Sort Features by Priority in the Doc
Never have I ever! Design docs are a reference source, not a task management tool. All sections are arranged in a way that makes them easy to navigate. They are never labeled by priority.
To prioritize, I turn all the features into user stories, put them in a backlog, and rearrange them periodically as production progresses. If anyone wonders what’s coming down the pipe, they look in the backlog.
Wordy Explanations are a No-No
I write mainly for the programmer, who just wants something quick and organized. I save the lengthy paragraphs for when I absolutely can’t do anything to avoid it. Use bullet points and flowcharts wherever possible.
The GDD is Not for Communicating New Designs to the Team
Face it, no one actually wants to read your lengthy GDD all the way through and you can’t make them. Going into a meeting, always assume nobody read it. I try to communicate the game’s design through more reasonable means instead.
I talk with my team, show off prototypes, draw on a board, and then at the very end point them to the GDD as a reference for when they need it. Everyone ends up with the same clear vision of the game. When the time comes to start making features, I direct them toward the specific sections they need to look at for each feature.
No Printing!
It’s a lot of paper to waste so everyone gets a copy of something that’s going to be outdated in a few hours. Printing the whole thing means you want to give it to someone to read, which we already know is not an ideal way to communicate design. GDDs are living and breathing beasts, after all. I never do it and no one’s ever asked me to, so there you have it.
Hold Back on Retro-updating the GDD to Match the Current State of the Game
Feeling tempted to go back and update the GDD to match what’s already implemented? I always ask myself first: is it necessary for me to document this? Is anyone on the team going to need to read this in the future? If so, do it. If not, ignore it. Let sections of the GDD die a natural death as features are added to the game, only focusing on the new and important things you need to write about.
These are just a few little philosophies of mine to keep documentation alive and useful. The best advice is to talk to your team and find out exactly what they need and be adamant about maintaining docs in a manner that meets those needs. You will end up with a nice, customized system that works for you.