Ok, I'm back again and I have been thinking about my game and writing things on paper but I've come into one problem: I still don't really understand how a design document should look. Do you wright everything? What happens, how it happens, when it happens? That would be alot of work, especially in a game where you can have multiple endings/choices. Does anyone can show a layout of a game design document (Would be even better if it was a document about a single player RPG). I hope you understand me and my question and have an answer. Thanks in advance, Daan

There are some publicly available. Personally, I prefer to split game plot and game mechanics into two documents. Depends on the game though.

But yeah; game design documents are a lot of work. They're still less work than cleaning up after miscommunication or fumbling about without a well laid out plan of attack.

The key question to ask is, "why do I need a design document?" If you can answer that, then it needs to look exactly how it should to satisfy your demands. If you are doing it to co-ordinate you art and programming teams, for example, it should explain explicitly what they both need to do. In this example, you would probably use bullet points, as you don't want to waste your time writting, and their time reading, some airy fairy text. However, if you are writing it to persuade some one to fund your project, you don't need to explain the individual class structure, but airy fairy text might be very useful.

However, if you don't know what you need it for, you just feel like you should, then you may have a problem. I'm not saying if you don't know why you need one then you don't need it. But, if you have a simple idea (admittedly yours doesn't sound simple if it is what I imagine an RPG to be :P) and it is just you working on it, your time would probably be better spent just making the game.

For me, the reason I needed one, and continue to need one, is so that things fit in together when I make it. I need to know how I envisage certain elements fit together, so I don't need to think about design when I am coding. If this is the case, then you need to have it easy to make changes to, easy to find what your looking for and without excessive detail or flowery text. Your not trying to sell the game to yourself so you don't need sentences like "The mood is tense as the player creeps down the deserted hallway". Instead you need :

*rectangular passageway
*Low lighting effects
*No NPCs
*Play tenseMusic.wav

I hope you understand what I'm getting at :)

Old sample/template by Chris Taylor

The book Swords And Circuitry have excerpts from an actual game (NOX)

And also some "amateur"/indie versions at Game Design Novice with link to the design document of Doom made by Tom Hall

Quote:

Original post by Daan013 Do you wright everything? What happens, how it happens, when it happens? That would be alot of work,

Yes. And yes.
There are sample designs out there. I have links at http://www.sloperama.com/advice/links.htm, and anyone is free to view the design docs for Shanghai Dynasty and Shanghai Second Dynasty (can be downloaded from my site; contact me for link).

There are no real hard and fast rules for this. A design doc should be formatted in such a way that you have all the information you need to get across what is required to make the game to the entire team.

I have seen design docs on AAA titles that are enormous, and run well over a thousand odd pages. I personally don't agree with this as it's hard to maintain, but they do and will get complex as your game gets bigger.

1. Write down a high level doc first, don't get into real nitty gritty detail - work out from there what you really need to dig into
2. Write additional docs to cover the specifics of those areas that you have identified as needing further information
3. If you can get away with drawing a picture to describe or reduce your word count - do it
4. Keep it up to date - it's a hard thing to do, but it is important
5. As mentioned above, keep Story and Mechanics separate - and probably level design as well (one doc per level / dungeon / track is fine)

Now - here is a depressing fact, no one will read the doc in practice - to combat this I've actively tried to make the docs shorter and more succinct. Hints for this:

1. Draw pictures, make little movies, whatever gets the idea across - hundreds of pages of prose are the last thing a programmer wants when reading a design doc
2. Dot point stuff, don't get flowery when you are talking systems - just the facts - again, a programmer wont appreciate having to decipher a story to find the nuggets of info they need to write the code
3. Use "Use cases" or "player use cases" - a list of things that the player will do and experience when playing or using this system - it's a trick Bioware use very well in their design docs, always describe each step from the point of view of the player "The player shoots their weapon..."

Hope this helps a bit. Another thing I find, is that every company I've worked for (A couple of the big publishers and a few indies) do their design docs differently, there are no hard and fast rules. So don't sweat it on the details. If you find yourself wondering what you need to put into the doc, you just need to imagine you are someone that has never heard of the game, is there enough information in this doc for that person to start making it.

Quote:

Original post by Daan013 Do you wright everything? What happens, how it happens, when it happens? That would be alot of work, especially in a game where you can have multiple endings/choices.

But if you didn't write out those choices, how would anybody know to put them into the game?

If it's in the game, and is part of the design, it's in the doc.