Game Design Documentation

[Raybarg]

Hi, I have this GREAT MMO IDEA... no wait... its not...

Who am I?
I am pro software designer/programmer with over 10 years of experience in industry and I have been a huge failure as hobbyist game programmer for over 20 years by never finishing any game I started.

What am I after (goal)?
My goal is to clean my table and start from the beginning with ANY of my game ideas I have 'developed' during all these years of failing as hobbyist game programmer.

How am I going to accomplish my goal?
To do it right.
Yes, if I have an idea which I start to work with, I need "to do it right".

I have basic knowledge (well, may years of experience...) of documentation but somehow it feels hard to implement this as game design document. I never written any design documents, just requirement, functional and technical specifications...

So the obstacle is the start, the actual document specifying the game design itself. From that, it would be easy (I think) to write any of those, or combination of, other documents.

That's why after so many years of reading also devmaster.net I finally registered and post something; I need that little outside "push" into the right direction in writing a design document to lock it and strictly stay in the boundaries it's specifying instead of bloating the project with on-the-fly ideas, which has been my basic flaw in all these failure projects all these years.

So, questions;
1. How common is it to merge requirements specification within game design document?
2. What would be common (mandatory) topics in game design doc?
3. Is it good idea to start a design document and build the game design while writing it, letting it evolve while its being work-in-progress?
4. Is there some basic questions about design doc I did not ask? :)

Rest assured my game idea will be simple. Also, when I achieve the level of courage and that little "push" and start writing the document, I will make it available in public and might even blog out my thoughts while working. All this to make it more simple to come back here in devmaster.net for more "outside pushing" when path ahead is again clouded with lack of experience.

Even "real" design document of a simple game could help me by reading it. Or using it as a "base" for my own document, knowing what is required to "flesh it".

I will now continue my googling in this subject :) Thanks to all who took time to read this post.

[Sol_HSA]

So, questions;
1. How common is it to merge requirements specification within game design document?

Depends on the scope of the project. If the scope is large enough, these may need to be different.


2. What would be common (mandatory) topics in game design doc?

Mandatory: None.
Common: _short_ explanation on what the game is about, background, menu flow, storyline, controls.. the rest is rather genre-specific.


3. Is it good idea to start a design document and build the game design while writing it, letting it evolve while its being work-in-progress?

Yes. You may write all the design documents you want, but you'll never know if it's fun until it's implemented.


4. Is there some basic questions about design doc I did not ask? :)

Yes: "Is a design document mandatory", and the answer is no.

If you've really tried to make games for 20 years and never finished any, you probably have a scope problem. Try making smaller games. I've done several games - and most of those I've finished within 48 hours.

There's also the definition of "finished". A game can be tuned forever; you just have to decide when it's done.

I've written some "rules" on how to survive a 48-hour game writing contest, which may help you finish some projects: http://iki.fi/sol/ldsurvival.html