Sit down, son. It’s time we had a talk about where video games come from. You see, when a designer loves a game idea very much (or is paid a sufficient amount of money – that’s a talk for another time), he encapsulates that idea in what’s known a game design document, or GDD.
The purpose of a GDD is to serve as a single, concrete reference for the game. Ideally, each person who’s working on the game would be assigned his own personal copy of the game designer, who’s kept on a leash and fed Twinkies, in order to explain every element of the game as it comes up. But since we don’t have that kind of cloning technology yet (and some states have outlawed Twinkie-slaves), those people have to rely on the GDD instead.
The key to writing a good GDD is clarity. The enemies of clarity are ambiguity, tequila, and a compound audience.
Ambiguity
Never assume the reader knows what you’re talking about. You know the old saying, “If you assume, you waste everyone’s time and will likely get throat-punched by your producer.”
Sure, when I wrote, “The player chooses the red monkey,” I knew I meant that the player selects the “Simian Gladiators” from the drop-down menu, then scrolls through the options until he finds the red monkey, selects it, and then clicks the button marked, “MONKEY FIGHT!” — but the poor programmer tasked with coding the thing might have his own ideas about how it’s supposed to work. Maybe they’re good ideas. Maybe they lead directly to the creation of SkyNet. Do you want to leave that sort of thing to chance? Of course not.
Define everything. List each step in the process. And if you value your non-throat-punched state, make sure you never confuse your definitions.
Tequila
You might think that drinking leads to clarity, but that’s just the booze talking, and it does not have your best interests at heart. It is, in fact, a poison. It’s trying to kill you. Even worse, it’s trying to get you punched in the throat and fired. Save the drinking for when you’re working on your novel — that’s when it turns you into a freaking literary genius.
Compound Audience
Know your audience. If you’re writing a GDD as part of a pitch for the executives considering which investment for third quarter will pay off better — your game or a new Lexus — you’d better write that thing aimed squarely at their coal-black hearts. Focus on why it’s an awesome game with huge profit potential.
Or if you’re writing for a licensor, describe how the game celebrates and embraces the property, while celebrating and embracing expanded markets with deeper pockets. And if you’re writing for programmers, you can skip the squishy “This part of the game is awesome!” bits and jump straight into the technical nitty-gritty.
The problem comes in when you have multiple audiences. Yes, it’s a technical document for the programmers, but the artists need some love too. So do the licensors, and execs who still can’t get that Lexus off their minds. Trying to serve all these masters, as Tadhg Kelly points out, results in an “amorphous, unwieldy and poorly written document.” So what to do?
I recommend sidebars. Maybe they’re literal sidebars if your software supports it; maybe they’re just asides scattered throughout the main text. Maybe they’re even their own files, if you’re following the “lots of tiny files instead one giant file” GDD philosophy.
For example, if you’re writing about the different classes of monkeys and the types weapons they can carry, you may include a sidebar for the artist with weapon references and suggestions on how to make the monkeys visually distinct from one another. Another sidebar might be pointed at the marketing guys, detailing how the inclusion of monkeys has been shown to add 10 percent to any game’s Metacritic score. You might even include a sidebar for future designers (including yourself, since your memory is only so long) explaining how and why you chose these monkeys and weapons.
The benefit of sidebars is that it compartmentalized the information. An artist looking for monkey-gun reference doesn’t have to read through a whole Berlin wall of text; he can skim for art sidebars. And the exec who doesn’t care about the technical specifications can just read the part that tells him how awesome the game is, and how when it’s done he’ll be able to buy two Lexi.
To this end, consider color-coding the sidebars too. It’s even easier to skim for what’s relevant if you have an additional visual cue.
Of course, these are just my thoughts from my experiences. If you have your own tips on GDD clarity, I’d love to hear them!
