GDD's and do they matter?

Like many of you -I assume- I have been scouring the interwebs to find information on best practices on how to start developing a game. I'm not talking about how to start programming or where to begin with art. No, I was more interested in the very beginning. How to plan, how to prepare, how to limit my rework and get my game out there. I did find a few sources that helped, but they were all scattered and fitting all that information together took time and I usually just ended up stumbling through the process myself.
After a while I started working with a small hobby team who wanted to make their first game. Since I had experience I figured I'd share my knowledge and try to help them along. I wrote a few posts for them that described a few game development processes and such and it turned out they really liked it. My writing really helped open doors for them and they suggested I should make a blog. So here we are.


Again, This blog isn't about how to program or how to art. There are tons of tutorials and blogs and guides and the like out there for that. This blog is for the core aspects of game development based on experiences I've had and from what I read and learned while developing my own games. I'd like to point out that I'm not some big shot expert who produced 100's of games. But I have been through the process a few times with several different teams. I'm just wanting to share my experiences and see if they can help more beginners.
Without further ado, shall we get into it?
One of the first steps in developing a game is making a GDD so I thought I'd introduce every one to what a GDD is and some opinions on it.

Please enjoy and let me know if you like this type of thing and if you have suggestions for future topics.

GDD's and do they matter?
To begin with what is a GDD? For those who may not know a GDD is short for Game Design Document. It is essentially the games bible. It contains everything you need know about the game you are making and allows every one on a team to know exactly what needs to be done and why.
A GDD contains information from 'What is the game?' to 'what art assets are needed' to 'How will the game function' and more. Ideally a GDD will answer any question you come up with in regards to what should be in the game and how it will interact with everything else in the game.
Now that we know what a GDD is do we really need one? Why or why not?
Many people will tell you many different things about GDD's and how helpful they are. Some, like myself, are big supporters of the GDD and others are against them and prefer other methods. I'll first explain why I find it important and then follow up with why people may not find them as helpful. Make no mistake though, Neither side is 'correct'. Ultimately it comes down to personal preference and how team is structured, so I won't be harping on those that disagree with me. I fully understand their points of views and find them valid.

Lets begin!

Like I mentioned a GDD is essentially the game bible, but it is not a static document written once and then never touched again. It is a living document that constantly changes and evolves with the project as new problems and solutions crop up. It is also important for all members, regardless of position on the team, to constantly review the GDD and ensure that their tasks conform with the most up to date GDD.

It is also every ones task to ensure the GDD makes sense to them. It should also be as clear as possible to limit rework as much as possible. Some times starting over is actually the fastest and best way to move forward. But in the real world employers wont want rework and they would be much happier -in my opinion- if you ask questions and make sure it's clear.
GDD's don't have all the answers though. They don't detail out time lines, who is doing what task and who reports to who. It is strictly a guideline for what is in the game, what it's about and the points the product is trying to get across. It isn't a marketing tool or daily planner.

To sum up I like using GDD's because the team can stay connected easily and know exactly what needs to be done and what their objective is. They can read about what the final result should be like and judge their progress based on what they have done and how it compares to the desired output of the GDD.

So I've talked a bit about what a GDD is and why I like it, but what about why people don't like them?

Many people dislike GDD's because of the upkeep they require. Projects change constantly and it almost feels like a daily upkeep. If the GDD isn't up to date than every one who is relying on the GDD to be accurate is given miss information.
Some people like to simply talk it out and let the game flow, rather than have a set of 'rules' to guide them so they don't feel as restricted on what can and cannot happen. This is partly because some people don't view the GDD as a living document, but still feel like they can't deviate too much.
Some people work alone and thus don't feel they need a GDD. There isn't any one to communicate to or bounce ideas off of, so there really is no point other than to keep track of your own thoughts.






I'd love to hear your ideas and thoughts about GDD's. Do you like em' or hate em'? I also encourage you to look up some GDD examples and see what you're in for as your project moves forward. You can always google GDD templates or GDD examples. I'd also be happy to share the templates I use when creating my own games; If any one is interested.

I really hope this was informative to you. I'd really like to hear feedback and input from you, the reader.

Next I'll talk about Testing in regards to why it is the worst thing ever, but arguably the most important thing ever.

Thank you for reading and please give me suggestions of topics to cover!