A friend asked me to give a talk in his class about writing game design documents. This is a challenging task. Not just the writing – even simple games have a lot more moving parts than it might seem on the face of things – but specifically the task of teaching people to write good documents.
STEP 1: MAKE SOME GAMES
Nothing teaches like the crucible of game development itself. So for me, the first step in knowing how and what to write is to make games. Learn firsthand what needs to happen, the multitude of mechanics and assets that need to be created, how communication succeeds and fails in the course of production. Roll up your sleeves and jump right into building the plane in flight.
Develop by the seat of your pants. You will quickly learn – particularly on team projects – the value of planning and communication.
Whether it’s tasks or vision or how a mechanic works, the different ways to interpret an idea before it is implemented are numerous. Unsurprisingly, passionate, creative and intelligent people will not agree on what something is let alone how best to create it. A good game design document:
- Clearly communicates a game’s goals and vision
- Provides specific information about assets and interactions that need to exist
- Evolves to meet the team’s needs
Game development is a technical, creative, artistic and surprising endeavor.
Every game is different.
Every team is different.
It follows that every document will be different. In my own courses, I’ve taken a variety of approaches to teaching documentation. From saddling students with bloated twenty page templates to be fleshed out over a long weekend (rejoice, my students, this fell to the wayside) to 1-2 pagers that lead right into prototyping. Where I’ve ultimately landed is not really in the middle at all, but rather a process of revealing what is known and unknown about a given game.
STEP 2: ASK QUESTIONS
There are always so many unknowns. So many questions.
So. Many.
And everyone on a game team has them: the programmer who needs to create the AI; the environment artist who needs to make dozens of props; the level designer who is building the campaign; the sound designer; the animator; the producer who has to schedule it all.
As a designer, one of your chief skills is empathy – projecting yourself into a player’s experience. Treat your teammates the same way. What questions will my programmer have? What will my sound designer need to know? Embrace that. Better yet, ask them! Tackle the unknown head on and aim to obliterate it by asking questions and answering them. And then ask more questions. And more. And more. And still more and when you’re done, you’re not done. Ask more questions. Eventually…
Because it’s good to sanity check, I polled my network of developer friends – artists, designers, programmers, sound designers – about effective documentation they’ve created or used. The question I posed to them was twofold:
Game Designers: What’s the best advice you ever got for writing design docs? (or flip it: what’s your best tip?)
Game Design Doc Users: What makes a design doc (in whatever form it takes) useful to you?
It was enlightening to see where various creators and users synched up and didn’t. I’ve distilled the lot of it and my own thoughts into five questions a game designer and a game design document need to answer:
What are we making? Know your game. What experience or experiences do you want players to have? How big is it? A three-month project and a three-year project are totally different beasts.
Who are we making it for? You’re building a player experience. But who is this player? What do they enjoy? If they talk about it to others, what are they gushing about?
Who are we? Wear all the hats. Your document has ‘players.’ Give them what they need. Who needs what information?
How can I best present this game? Designers, this is where the work is… after all of the legwork and decision-making, it’s time to document. There are many, many, many questions here…
How are we making decisions? A good game design document is FULL of decisions. Designers, this is where the hard work begins… Coming to those decisions is a process and there’s no One True Method to reach them. Meetings, conversations, prototypes, asking for or chasing down input, solitary confinement – every team and company will develop their own methods.
This notion of decisions is very important.
STEP 3: MAKE DECISIONS
I latched on to the way this was explained in Adams and Rollings’ On Game Design. There is a section describing the difference between an ‘Idea’ and a ‘Decision.’
IDEA: Basilisks guard their nests.
DECISION: A basilisk with eggs patrols within 10m of its nest. When an intruder enters that area, the basilisk hisses before charging at full speed to attack with claws and teeth. The basilisk will attack the intruder until either a) the basilisk is dead, b) the intruder is dead, or c) the intruder leaves the 10m radius. If b or c, the basilisk will resume its patrol.
The difference between the two is stark. In the former, basilisks are vaguely defensive. In the latter specific details emerge about the basilisk’s behavior and the context for it. Even the latter description is incomplete, but it is starting to take shape. Use descriptions like these to tease out what code, sound, and art assets need to be created. Nests. Eggs. Basilisks hiss, walk, charge, claw, bite, and die. All of these will need animations. Every animation will need sounds. There will need to be code tracking health, intruders, presence of eggs, distance to nest, etc.
These sounds and animations and code behaviors are answers to some (not all) questions about the basilisk. What other things would we need to know about the basilisk? Questions are powerful.
PUT IT ALL TOGETHER
Find a GDD template. A quick search of Game Design Doc templates will net dozens. The templates will only be containers for the answers to the many, many questions that you and your team will have. And then what?
It bears stating again. Ask questions.
What kind of questions? All of them. Anything. Brainstorm. Write down 50 questions. And 50 more. And then more. Get teammates from different disciplines to write questions they have. More and more until you can’t think of anything else. And then… start answering those questions. Some will have simple answers. Some will take exploration and spawn new questions. Discuss. Think.
Don’t worry much over answering these all correctly in one pass. In the beginning, there are so many, some of the answers will be wrong. Some may not even be answerable.
And new ideas and questions and challenges will arise as you go.
The most important questions:
- What is the ultimate goal of this game? What is its purpose?
- Does (or how does) this thing we’re considering support that goal or purpose?
- Yes: keep it
- No: set it aside
Be relentlessly curious about your game.
