Jump to content
  • Advertisement
Sign in to follow this  
Mrkpc

Don't understand how a design document looks

This topic is 3322 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!