Ive had this idea for a game for a long time now. I focus alot of game elements and subtleties of games. I have ideas for levels, controls, settings, events, gimmiks, etc etc. I pretty much have a fully fleshed out game. All that I havent worked on is superficial things like dialog, plot, music, and a concrete 'map' of the city the game takes place in. Ive got the gameplay mechanics down. I want to start writing up a design document so taht in the future, when im working on professional games (this is a HUGE game that i dont plan on creating independantly), I'll have something to refer to so that i dont forget any elements or great ideas i had. Is it better to set the document up in 'chapeters'? I tried organizing my ideas like this, but there are some ideas that cross over. For example, I have alot of ideas for customizing your weapon (this is an FPS), and i have alot of ideas on how the customization effects the game. You have a circle retical, and as you fire your gun, it gets bigger. thats your area of aim. If you put attachments on your gun that absorb recoil or have automatic targetting, then the retical doesnt get bigger as fast. Also, it would have a smaller Max size, or a smaller Min size. In anycase, the idea of how spray is controlled would be in a different section (say, gameplay), than the idea of how customizing your gun would effect spray (Gun Customizations). Would it be best to put some ideas and concepts in multiple places in the document? I really have no idea where to even start.

I don't personally have much experience doing design documents, but you could always use HTML to cross-reference different elements. It seems ideally suited to this kind of situation where the document isn't really linear.

The book Game Architecture and Design by Andrew Rollings and Dave Morris talk a bit about this aspect of development and provide an example design document at the end of the book (Appendix A). I have this book (only read like 1/3 of it about 2 years ago) so cannot tell you if is is exactly what you are looking for. You can buy a used copy for about $27.00 or go to your local bookstore and see if they have a copy and check out if it would help.

I would recommend using numbered paragraphs or sections, kind of like an outline. For example you would have the reticle section be section 3.0. Then below it in section 3.1 you would go into detail about how the reticle would get larger as you shot etc. Then 3.2 would be a section that would go more into detail about attatchments or accessories that would make the reticle more stable.

The benefit to doing it this way is later in the document, say section 7, you have a section just about items to pick up (including gun customizations) you can then just reference section 3 instead of repeating the same information about reticle effects again.

When I have an idea I just want to get down so that I don't forget, I usually just start with a bulleted list of sentences to start organizing it and then come back later and put in all of the details once it is a little more organized.

For more details or actual examples you might try googling 'requirements documents' or 'functional requirements'.

I'm working on my own design document using HTML, and I've found it to be the ideal medium. You can cross reference and organize very easily, allowing skimming from the table of contents to a particular area very quickly.

I've been using Netscape Composer (much to the chagrin of my HTML guru sister [wink]) so I haven't had to worry about figuring any of it out, it's just like a word processor.

I suppose the only downside is you can't really print a HTML document out, but if you're making it for yourself, this really doesn't matter as much.

If you are going to use numbered paragraphs, don't go past 3 levels of numbering (ie. 3.1.1). Otherwise it becomes too difficult to read, in general you should keep it very high level, discussing algorithms that you plan on using, AI and so forth.

In general following this layout, it should not be over 30 pages. Also include UML class diagrams, and other relevant UML Diagrams.

Well this is the layout that I chose to follow, in the past and it seems to work well.

Hey thanks for the advice. I think Im going to go ahead and make it outline based. That seems the most logical.

Also, does anyone have a design doc made up that they dont mind me looking over to get a better idea of things?

Ive got a basic conept, but i dont want to start on it and then end up with a huge mess and a waste of time.