4 Things that starting teams forget about the Game Design Document
If you’re trying to create video games and have already went further down the road of how to plan ahead, then you probably heard of the Game Design Document. That wiki or document which contains every aspect of the game from story, graphics, AI, and well everything.
As an indie startup team you probably did your homework and investigated everything there is to know about this document and may have created one, but there are a few things that often happen in new studios that you may forget.
1. Everyone should participate and everyone should approve the GDD only after reading it entirely or at least in any part where that supposed person plans to have an opinion on in the future.
So this guy from the Tech department or a programmer has this great idea that he discusses with the planning committee in the early stages of the creation of the GDD, and then he for whatever reason misses one of the meetings when said idea is turned down. This information is in the GDD, but since our buddy here is pretty confident he know the GDD because he participated in the meetings he doesn’t read it. Then, at some point in development, he randomly starts coding that particular piece, and when someone who read the document finds out all sorts of hell break loose as he exposes his idea again and explains it and defends it while everyone who read the document is either contaminated by his thoughts or blaming him for not reading.
Certainly there are parts that could be skipped by certain members. For example an Art Director is probably not going to understand the more technical aspects of the GDD, but he should have them available anyway.
A GDD is a big document, but the worst thing you can do with such hefty work is invalidate it by not having everyone agree with it in the first place.
2. You have to update the GDD as you work.
Maybe you think that if you set up your GDD perfectly, then it may not change at all during development. But face it, projects change as they are built and so should your GDD. Take the time to review it and update it accordingly. Keeping your GDD up to date is essential for the inclusion of new personnel in the middle of a project. It’s essential to keep everyone on sync. If you don’t keep your GDD up to date your might end in useless discussions about stuff you simply forgot.
3. Your GDD has to be as complete as possible from the very beginning of production.
Maybe you think that you can skip to development and maybe not have the complete level details, or that the Art Bible will take too long to complete and maybe the programmers can get to work already. There are several parts in the GDD that may or may not be essential to begin production, but a healthy, full GDD before production will relieve you of many mistakes. So maybe only when you have some hands doing nothing but waiting for the GDD to be ready you start, but if you can afford it, have a complete GDD.
4. Keep your GDD in a wiki. Not as a document.
You might have taken the hint from the top paragraphs, but here it is again. Do it in a wiki. Wikis were practically meant for GDD’s. A gigantic word document or even a google doc are not the best options for this service. If you don’t believe me try it. It will suck. Whether you set up your wiki internally or on the cloud is up to you and your needs regarding security and accessibility.
If by any chance you don’t have a GDD or don’t even know what it is, do yourself and favor and get this book It contains one of the best explanations on all the areas of the GDD.
