I'm working through a detailed design document at the moment. One problem I'm having is that since I'm creating the design as I go along every new feature I write down creates two more problems that need to be solved. Maybe it's my background as a tester and QA specialist, but I'm plagued with all the little cracks that don't yet fit together with the design. Plus the structure of this living document is now very chaotic, as I haven't found the right place to put everything. So my question is for general advice about how to write a large game design document; any tips from those of you working on your own designs or from those who have already completed theirs. How do you make sure everything fits together and all the gaping holes are filled? Any good writing techniques you'd like to share? Thanks in advance!

Writing a design is just like programming. The more planning you do before you start the less chaos you will have. You need to step back and look at what it is you are trying to create and then divide that up into sections. The easiest way is just to imagine running the finished software and work through its use in your head, noting each new feature/module as you go along. That will give you the list of section headings for your design. Then if you find stuff that might fit in several sections put it in the first and just place notes in the other sections that link to it - that way if you later look for it in one of the other places you will find a quick link to its actual location. Remember - it is your design and you need to be able to use it so put stuff where you think you will find it. Easiest way of all to do it is in a wiki style with a search box. That way it is a live/searchable doc and finding stuff will be easier.

As for the problems that keep cropping up? That is a good thing - that is what design is for. Bad designers identify these problems, work out a solution, find that creates two new problems and so scrap the solution and just put up with the original problem. A good designer will solve the first, then the two it spawns and on down the line solving each problem. It is a lot of work and not particularly enjoyable but in doing this you can save vast amounts of rewrite/debug time later.

This is exactly how I work on my design (How obscure said).

First I make an overview of the game in the top of the document (What genre, what engine, Commercia/Free/etc... and other things), this helps the designer to know
what he's working on without having to repeatedly think about it.

Then I make the big categories list like Storyline/Gameplay/User Interface, Then make subcategories for Gameplay which define the gameplay attitude (Combat System, Item System, etc...) and in User Interface I do the same (HUD, Economics, etc...)
And also storyline needs multiple sub categories such as the history, the storyline itself and the ending/s.

Then Inside these subcategories, I put in the Concepts, If I see that a concept
doesn't have much to do with other subcategories, I imagine what it would most fit to and put it there.

But Before I put in all the Concepts I would see if they interconnect with each other, if one does not make the other fail. If I already wrote something down and know some other concept doesnt work well with the new concept, I look into it and try to fix the problem, usually, I do not have any problems because as Obscure said, you have to imagine the finished product.

Well, I hope this helps in any way, Currently me and a team are working on a very big Modding project.

Hi

May I ask if you are working professionaly or for funn? I my self would like to write and design a game my self. I am a proffesional developer working in medical industry.

Regards, Martin.

We're doing this as a hobby, but we'll get paid for some of our work as well :)

Edit: But the design is done mostly professionaly (As you can see from the resemblance of what I do and what Obscure does).

Thanks for all your advice! The modular method is what I'm presently using, as that seems to make sense. I've already got an oveview and some of the sections mapped out, but I'm beginning to understand why I'm stuck. The problem is my project is really a big AI tech. demo that I'm meaning to turn into a game; the AI implementation at the moment is a bit fuzzy, and I don't think I properly have a true vision of how it will play. The game design is sort of a hybrid of many different genres and is not really like anything else I've played, so it's hard to imagine and it's too easy to throw in new ideas. It's like not fully understanding your argument or thesis when writing a technical paper; it all turns out a mess.

I guess if I write a short description of how the game will be played, from the perspective of the player (i.e. no technical implementation based stuff) I'll have a better idea of how to continue. Although there might be a danger of overplanning; it's a one man project so having a huge document is slightly less useful than on a team, although I think it's practically compulsory to have a full design document anyway (if you want a good game at the end).