The first step to building a house is creating the blueprints. So the first step of making a game should be the Game Design Document, or the GDD. Except it’s not. Writing a comprehensive guide to all design decisions for your game before you’ve even made a prototype is not only a waste of time, but it’s completely counter productive.
This Aint No House
It might make sense to get every requirement for a house; once you’ve poured the foundation, the floorplan is set in stone. At that point you know what you’re getting, how many beds and baths, two floors or three – there won’t be any surprises. Good luck changing that without some huge expenses after the foundation has been poured. If you lay down the foundations for a castle only to find out you really needed a chateau, you’ve just wasted tons of time, energy, and cement. But in software, decisions don’t have to be as expensive.
Instead start with the basics. Get a prototype built, and then figure out what it needs. Software is malleable, there’s no reason to over think at the early stages. Just get a working project and re-evaluate what it needs and add exactly that. You shouldn’t be adding features simply because it seemed cool six months ago; add them because it would make the game better today. Similarly, you don’t need to keep features that were in the original prototype if they no longer fit; try to use what you can, and throw away the rest.
Don’t let yourself be carried down by dead weight. There are enough obstacles to getting your game out there, don’t make it harder for yourself! Writing out a 20 page GDD is not the first step in building your game. It’s the first step towards obsolescence. There’s no way you can know what will be best for your game before you start playing around with prototypes, and a GDD will tie you down to details that may be irrelevant in future development rounds. Your favorite feature will be cut. Your best idea may be produced in a late night brainstorm session. The final game’s details may look very different from what you first envisioned.
What We Do Instead
How do we keep the game from resulting in a chaotic mess of random features being thrown in and out every week? After we prototyped, we figured out what we thought the game needed and prioritized. Whenever we finished one item, we would re-evaluate the next to see if it still made sense, or if something new should take priority. Anything we felt didn’t belong was gutted without prejudice.
By allowing our vision to grow with our understanding of our game and its needs, we didn’t have to guess ahead of time how many windows our game needed, but could add them in as necessary. In the end we believe that this flexibility creates a more cohesive structure and avoids wasting time.