“My first comment is one you probably expected: There’s not a lot here yet. I strongly suggest a period of frenzied prototyping and trying stuff out. The key problem here is that you haven’t found your game yet. There’s no hook, no feel for how the thing is going to play.”
There’s more to a game company than a snappy title and there is more to a game than just an idea, even if that idea is written down. When I first got it into my head to cannonball into the indie pool, I figured I wouldn’t do what a lot of my fellow predecessors did: do work without documentation. GDDs are extremely important, unfortunately, they are the most under utilized because, well…a good one is hard to do. The difficulty doesn’t come from writing things down and hashing out ideas, but just the consistent nagging of ‘doing cool shit’ or ‘getting money flowing’ that becomes louder as your bank account dwindles or something that resembles your idea is up on the Itunes store.
I’m fighting that right now, actually. I’m fighting myself daily to not drop everything I’m doing and start tinkering, playing, prototyping; you, know…just being a mad gaming scientist. It’s tough. I’ve been working on my first full game, Cap’n Sparkle’s Revenge for two months now and the only thing I have to show is a skeletal prototype and four (going on five), renditions of the game’s GDD.
Bah. Just bah, but the above quote came from Jeff Vogel, Mr. Spiderweb Games himself. I wrote Jeff on a whim and asked for his sagely advice, I mean…he was indie before it was a thing and, as far as I know, he never worked for ‘The Man’, so I found it a great resource of brain pickings.
I know most indie devs hate criticism, but I found his to be more than comforting. Finding out what I want my game to be on paper is much more alluring than if I spent two months slogging away on some nebulous tech with no record of the process. I’m glad I didn’t waste time. Jesus H. Christ, am I glad.
Why Use A GDD?
There are tons of great books on game development, but my favorite isn’t a game dev book at all; it’s a book about the open source Processing language that can be used for all sorts of projects. The solid take away from Daniel’s book is not how to develop something, but how to theorize, break down and archive your development on paper first.
The first exercise is breaking down how to brush your teeth from the moment you wake up until you shower (if you’re into bathing, not everyone is. If you’re not into that, shame on you. Go shower.). Breaking down the steps of the mundane brushing of teeth and writing them down in a ‘task tree’ shows how detailed the act of brushing is. Since most(!) of us brushed everyday for years, it’s thoughtless; but imagine if you’re a three year old child who had someone do it for you, then suddenly you have to learn to do it yourself.
This is basically what a GDD is; it’s a detailed, thought through collection of ideas, theory and practical development steps to:
- Cut down churn
- Keep scope creep in check
- Have a solid reference to coincide with budget
- A roadmap that can lead to franchising
- Makes an unwavering blueprint for development; streamlining the process considerably.
- And for beginner devs, it’s a safe, constructive place to document systems without f****in’ neckbeard coder trolls getting in their kool-aid. If someone says: ‘I want a tower that shoots up, down, left, right’ in an ineloquent language, they have the right to do so. Once they figured out what they want, they can translate and as for help online.
With Cap’n Sparkles, my heavily modified GDD keeps me honest about what I can do currently, what I previously planned and there is also resting place for any ‘wouldn’t this be cool?‘ ideas that we gamer folks always have.
My favorite GDD templates are the following; I’ve used them for years.