Game Design Documents bad?

[hallsofvallhalla]

For indies I say YES! They are bad.

Heres why:

1. Open Design. Many indies want to create a team. If you design the game all pre-hand its going to make that process harder. Many indies who join teams want a hand in development and design. The game design document says "here is the design, now you help me create it" When teams should be saying " I want to make a game like this, lets bring our designs together and build it".

2. Limitations. Many of the engines out there are very limited in what they can do. If you go and design this feature rich game and go showing off this document many people will have high expectations of the game. Sometimes by no fault of your own you cannot deliver these. Sometimes its better to mold the game around the engine then the other way around. Especially if you are on a $200 budget.

3. Expectations. Muck like above, design documents often start out very thick and full of features and designs. Players and developers both may read this before hand only to have their hopes dropped because of limits, art, money, time, engine, ect... You yourself, the writer may also be swayed from completing the game because of this.

4. Time. Design documents can be very time consuming and that week you spent writing it could have been used more productively on actually creating the game.

5. Design. Sometimes its better to create the game as you go and not be hindered by having to update a document. Sometimes the best ideas come from swift inspiration.

This is just my opinion. Each person is different but I think having a design document as a requirement is a bit over-rated and indies should think about whether they really need one or not.

[Noctrine]

I agree partially. I think at some point you are going to want to create some sort of game design document, not initially of course in indie teams its good that everyone feel involved not only in the creation of the game itself but in what they are working towards.

If people aren't interested in the end project they are going to feel less motivated to work.


But yeah, living documents for the win. Always remember, its not set in stone pencil can be erased. (I think we have changed the overall story for the arpyg sample game a couple of times before we got to the badassassery that we have now.

[Jackolantern]

I could maybe agree for projects that are using engines that only require art and scripts written. However, there are some fixes to your list of reasons:

1. Anybody interested in the creative side of development should have a hand in creating the design doc, although one person has to have final say to avoid deadlocks and lots of hurt feelings. It doesn't have to be created beforehand, because I don't think just having a design doc will make it any easier to find a team than if you didn't have one and were asking for input.

2. The engine and supporting technology can be chosen first, and then not deviated from. Then you are creating the design based around the limitations of the engine, or at least what you have the resources to alter.

3. This is basically fixed with #2

4. While it is true you could start a period of time earlier if you did not write the design doc, but would you finish that amount of time earlier?

For the last one, I could only say "for small projects". If the project requires coding some systems from scratch, it is almost doomed with no design to know where you are going. You will get half-way through coding, only to realize that what you have already done has to be broken and completely re-written because of what you have to do next (trust me on this one. I used to try to sit down and start coding with no design work all the time). The old carpenter's saying of "measure twice, cut once" applies quite well to coding. You can't just grab some wood and start building a house without blueprints, although you could get away with it on a small play house.

Also, it is hard to balance a game if you do not have any quantifiable data of what the game is about. It is easier to review what is in the game if everything is documented somewhere. For example, someone may be coding the stats for a Barbarian class, and give them a skill that increases their Strength x2 for 60 seconds. They did not know, however, that someone added a weapon that has this same effect. The weapon's effect uses a different mechanic, so the two effects stack. This is probably not what you intended.

So, I don't know. As long as you choose the supporting technology first and stay realistic, I think the design document will pay a decent return on the time spent creating it. I am also unsure if you are including a "tech document" in with the design document. Some people consider them the same thing (one part all design, one part all tech), while other consider them two different documents. If you are referring to creating the tech doc, and skipping the design doc, that would work for smaller projects most likely. I don't know if it would be better, but I think it would work. If you mean skipping both, I am not even sure if it would work for a small project.

[Agent]

Some fairly valid points i guess.
I would not consider design document a 'requirement', but in saying that I don't think any well done project has ever really been done without some pre-designing (and not just in the game creation world). A game, much like say an engineering project - is something relatively complex, multifaceted and time consuming. With saying that if you ran two project simultaneously one with and one without a design doc - the pre designed team I think would in the long run produce a much more solid product.

The points you outlined saying that a design document can restrict the project is a pretty good point. But at the same time if you think about it not having a plan and just sort of 'going with the flow' will turn up just as much if not more problems (mainly unforeseen ones) which will have the same - demoralizing effect as restrictions of a design would.

Part of design includes research, so that would also include asking communities and devs what they would like to see, - input idea, etc. The plethora of information that can be obtained is the condensed into what will and will not be a feature or good idea - based on all universal factors like budget, engine etc. - Now you may say yes but that's really all more for professionals, and yeah I guess that is true. BUT on the other hand for indie groups, it is extremely easy to get side tracked with problems, new ideas which eventually loop around you until you just get fed up and quit.

My own personal experience from numerous major projects for school have all benefited greatly from proper design and management, leading to many well rounded products that I was happy with.

That is just my 50c in all this... indies while NOT HAVING to have a design doc, would benefit from one in my opinion.

[hallsofvallhalla]

hmm all good points, thanks for the feedback.

[Cayle]

Rather than write a long reply both here and at MMORPGMaker, I made a blog postout of it on the elephant.

[hallsofvallhalla]

very nice write! I enjoyed it rather well and your point about useless devs is spot on.

[kyraneth]

That was a nice read.

[Noctrine]

Well, there is one more blog I need to subscribe to.

[Agent]

Very nice, encapsulated it all very well - and like halls; said the whole bundle of useless devs is oh so true.