how long are your design documents?

What design document?

 

We can all make design documents til the cows come home.

Turning it into an actual game is the tricky part.

 

Longest design document that I saw was 72 pages filled with back stories and description of game mechanics, but no numbers to fill in the blanks for questions such as "How many items can a character carry at any one time". With a designer who was seldom in the office. Development slowed to a crawl. As for the 72 page design document, no one I know ever finished reading it. I know I didn't

 

Word.

Plus, it's practically impossible to put together a design document that has any meaning before you have a chance to prototype the gameplay extensively. Give and take during development > fleshing everything out before development.

 

Actually ours for Shellrunner is about 4-5 pages long, some parts are decided from the start and other are "we might do this or this or that but we'll decide later in prototyping" but we have already thought about different possibilities, it's a work in progress and it evolves with the coding of the game.

 

I don't have any game design document since I don't need to communicate my vision to anyone on the team (I'm the only member of the team )

 

Mine is of indeterminate length and involves an exercise book (like the one you would use in school) with randoms thoughts/ideas and sketches in it.

but then I find design documents are more useful for me to problem solve with rather than read. (I'm the only dev on my team at the moment)

 

I don't think it's merely a team communication vehicle. I use my design document to outline the game mechanics and features. For each decision, I include a rationale so that I know the decision I made months ago and why.

I have a dozen files varying from one to four pages as my design document. When I've fully implemented a document, I read it through again to make sure I covered all of my bases and then move it to an archive directory.

The documents keep me on track. I want to keep my project lean by implementing the minimum set of features. They keep me focused on the important parts of the project. I often brainstorm new features but they sit off to the side in the "maybe" section. I want to have a fixed vision for the game and then lots of extra stuff that would be great that I will fold into the game as needed.

 

What you describe is the 'X' EA is using and that doesn't need to be pages long as you may loose focus and end up with complicated design decisions.

 

Innumerable sheets of scrap paper, covered in scribbling done with all manner of writing utensils (including, at one point, human blood).

I have yet to properly type a single design document, although I do have a few little bits written in Tomboy.

I don't have any one design document for anything. The random papers materialize when I need them, and if they don't, I consider it a message of fate.
Then again, that might explain why I have yet to finish anything of significance.

If I was to ever end up with someone else crazy enough to work with me on this stuff, I would probably need a pretty big document. For now, it is quite handy to keep it all bouncing about it my head. The prototype phase is generally with a smaller group, so I think an major design document should be written during or after that prototype is finished, before the rest of the team gets going on a full project. (I say during because there are a lot of little decisions people forget the significance of once they've been working for a while, making it quite confusing for whoever else reads the document).

 

What Jeremy said, with a little of vjvj and GFK said into the mix.

For me any time spent writing a design document is time wasted if most of it has to be changed when the prototype proves it to be wrong/bad, which it invariably does. I don't have anyone to communicate with either. I have a very clear idea of where I'm going in my head. How I get there will depend on how it looks and feels when I try it.

 

I used to believe that... I used to hate reading GDDs... but now I think GDDs are a necessary evil. They codify what is in your head onto paper - that you've made DECISIONS and those decisions can be communicated to other people.

A demo and prototype is still necessary to iron out all final details, but the GDD keeps you focused and allows you to estimate how much time and money it will take to build.

My current GDD is 40+ pages (original plan: under 20) - describing the control scheme and camera setups is almost 10 pages (with images) alone.

Turning the GDD into a game is just sweat and money to me ;-)

 

I suppose it comes down to how much you wrote about the mechanics, layout, interface, interaction etc. about what the prototype is testing. If one piece changes, I can change the document and check other things that might be affected. For example, I've started a match-three and it's possible to make matches in groups of three, four or five but not six. I documented that because I want bonuses for longer matches. Working out my longest match helped me brain storm bonuses. I also made sure to test which conditions I need to get a match of five. Having things written down and organized saved me time trying to find a match of six or generating bonuses for a match of six.

 

For me it usually comes down to inflection points - can I get to a playable demo with what I have now, can I get to theoretically feature complete wwihn, etc.. Every time I try to get more organized than that I tend to lose focus and time - the important questions to be able to answer (either for your doc., elevator pitch or green light meeting):

1. Why is this game worth making, ie. why will it be fun and either better or different than it's competitors.
2. Can I play it yet, if not what is required to make it playable.
3. If I can play it and it's fun, what is the minimum feature set to a theoretically shippable game.
4. If 3 then why isn't it good enough to ship OR what super hot thing can still be added to make it dramatically better.
5. Fix 4 and iterate or kill the beast.

Step 4 often takes a long time for me.

 

My "design documents" are a list of 10 to 15 bullet points on a half page (or usually a white board). And this is what we write up AFTER there is a prototype with a working play mechanic.

 

I didn't say they were a waste of time/useless/evil. I said that scribbling notes and ideas on bits of paper is the easy bit.

 

The requirements document is, IMO, the single most important document in the software development process. If you don't know what you're building, you're in trouble. Design docs? Not so much. Maybe some high level architecture stuff, but the lower level design to me is largely a waste of time. Code, unit test, refactor, repeat.

 

I think it probably comes down to what type of game you're writing too. If I was writing a Match 3, maybe I would use a GDD. I don't see the former happening though.

 

My design document for 1000 Crystals of Altaxia was about the size of an average napkin but I compensated for that with long hours of looking at the screen thinking : “ No, I have to do it another way “