next »

[Orymus]

Gdd at the indie level is wasted time under the illusion of productivity

I believe that's a bit extreme, but I tend to agree with this comment.
You should only have a GDD for someone that are not familiar with the project (outsiders) so that they understand what it is. In essence, it will be much more an elevated pitch that showcases your dedication than an actual GDD, and it should only be used when looking for financing, marketing, etc. Basically, when you need to convince a third party that you are for real.
Of course, a demo/prototype does the job best.

My team and I tend to use decentralized information (a series of single-feature documents in google docs or confluence for example) and iterate too fast on mechanics to document everything. You should embrace this aspect of indie development: GDDs are simply not required most of the time because they are used to communicate more efficiently across large teams, and most likely, you only have a small team.

A 'no-GDD' universe works best with very small teams (3-4) and physical proximity but is not unheard from larger teams with alternate solutions (skype, etc.)

That being said, sometimes, when you have an idea, it is best documented than explained. The reason for this is that a lot of people might get carried away on how fun it appears from the surface (and may lead to inefficient communication) but if not all of the details have been thought through, it may be a moot point. As such, a 'Feature Design Document' is both a tool to help you describe the finer details to insure you have a fair grasp over the use cases brought forth by said feature, and a good support tool to explain to your team.

[halk3n]

I don't agree that GDD's are only meant for grand-scale productions. I think that is one way to approach GDDs. Another would be to use this tool as a means of communication with a programmer under development on a project.

Most will say an indie game designer must have programming under his/her belt, but I beg to differ on that presumption. My perspective (and it is mine only) that a programming language is best utilized with the language of images first.

It's not even just about documentation (though that is extremely useful) it's also about reiteration of images and design as the code is being reiterated/optimized etc etc.

GDDs for me evolve as the project evolves (code/programming etc).

[Mopee]

I think it actually depend on what we call gdd.

Having an actual bible of game design for your whole projet is pointless because nobody will read it.
It depend on the size of the team but your document will be usefull if you ask to the people for which the document is intended to in which format they want it, it can be a flow chart a word document a ppt whatever. The point of having those document is to communicate and the means to do so change from people to people. Those document can then be put on a wiki.

However as soon as you put in place dev test in your project you need pristine design document describing each feature in the most atomic way possible. Then your dev tester can test it thoroughly and see if it work as intended. Those document are a pain to do but are really usefull.