The eponymous GDD, a frequently large behemoth slowly staggering towards both developers and designers with the clear intent of swallowing many, oh so many, hours of reading. Only to change as a flighty pixie the next day.
- Do games really really need a great big design document?
- What should a design document contain?
- Who should write it, who should edit it and who the hell should read it?
These are all very good questions and ones that I completely intend not to answer with this blog post 😛
What I do intend to do is perhaps try and coherently go through my own thoughts and reach some conclusion that would help me achieve the goal of making a game. And I want to make a game, actually make that plural, I want to make games (made a few already, but nothing that was specifically mine). Where do I begin? an idea…
Ideas however live in my head, quite happily mind you, but in order to make a reality from my dreams and visions I must first somehow capture them and, wait for it… yeah, here it comes… building for it… and WHAM! Communicate them to other people so that they can help me; rather than think I’m a raving loon.
Communication is hard, really really really hard! And is also the heart-stone of collaboration, without it no games would be made and the world would be a sad place indeed. Anyway, where was I? ah yeah, communication… how do I go about capturing my beautiful and elusive sprite-like idea, why with words, down hard on paper (well, e-paper anyway). And here is the crux of the game design document’s key role in a team. It must communicate the game design to people other than the idea guy. I don’t have time nor the inclination to write a 100 page review of every nuance in my current project simply because I don’t actually have it yet. So what is a poor developer do?
I thought hard on this subject, very hard (because it’s a hard subject) and I read books, not too many because they’re hard to come by and did I mention the whole poor developer angle here…? Then I met my friend a few days ago (who is also my artist on the current project) and we started talking (which I guess is as close as two guys are going to get to communicating 😛 ). At some point in the conversation we suddenly realized that we are talking about the same project but for some reason we’re both talking about completely different things. So I figured let’s stop and stock-take.
What we needed was a clear guideline to our thoughts. The best way to do this, I thought, was by drafting a few questions and then writing our answers to them. It didn’t take too long, it wasn’t too accurate and it’s most definitely did not produce the detailed design document I was used to from before; instead it was fun and it worked. Let’s call it the Game Overview Document just because I like the acronym better 😀
The questions themselves are fairly generic and will most surely be modified, changed, enhanced and removed as the need arises, but for now they are as follow:
- What is it called?
- What is it?
- What is it about?
- Who will play it?
- Where can they play it?
- How are we making it?
- Why are we making it?
- Why should anyone play it?
The answers to these questions, by the way, should never ever ever be, “because it’s fun”, “because it’ll be awesome” or any other variation of the theme.
The result of this simple approach led to very succinct guidelines that would allow us to write the story, design the map and create the content. It also lets us remember why we are making this game and what it is with but a single glance; something those insane GDDs never let me do before. The other result of this approach is that I’ve split the main document file into several different files meaning I got a few more files lying around in the /docs/ folder but it’s easier (for me) to navigate through to the things I need; like concept art, maps, tech, etc.
Next, I’ll answer these questions and see how clearly I can communicate my thoughts about this current project (which at the moment is called The Fallen).
“we’ll find happiness together in the summer skies of love”
Coffee, Code and Fractals 
On Mark Of The Ninja we didn’t have a design document. We had a collection of what the Lead Designer referred to as ‘one-pages’, infographics to describe specific parts of the gameplay, like ‘the targeting system’ or ‘AI alert levels’. We burned through several of these (the targeting system went through…4…iterations I think), but they were an excellent way for the designers to communicate mechanics without being artists or too wordy.
yeah, that’s pretty much what I’m going for at the moment; map design for example I’m leaving for either my kanban board or the actual game-editor repository.
The one thing I’m not sure about this is whether I should have the docs under version control or just as a shared resource on something like Google Drive. So far I’m leaning more towards version control but that comes with its own set of issues.