Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Should the design document be a continuous line of text, with real sentences, more like a description of the entire game, or should I structure it in simple points? What are the benefits, and are there more ways of structuring it?

share|improve this question
4  
Not that I disagree with Josh's answer at all, but 35 minutes in with just 1 answer is a bit early to be marking a question as answered, surely? –  Kylotan Jun 7 '12 at 17:15
3  
Yeah, I agree. You can always change it later, but that's always very disappointing to the person whose answer you are changing away from. And more to the point, sometimes having an answer selected discourages others from answering on their own, and that could cause you to miss out on a much better answer than mine. –  Josh Petrie Jun 7 '12 at 17:19
    
OK, welp, unmarked the answer. But, I will probably mark it again tomorrow, I found it really useful! Unless, of course, someone gets me something even more useful ;). Thanks for this hint though, I didn't think about that! –  jco Jun 7 '12 at 17:21

5 Answers 5

up vote 23 down vote accepted

There are no rules or industry standards; structure the document in the way that will be most useful to the people who will consume that document, keeping in mind what the purpose of your document is.

Personally I would expect there to be portions of the document that are better suited to using "real sentences" to convey your idea, as well as portions that are better suited to being written as a bullet-point list of features.

Who is your audience? If it's just you, if this is just supposed to help you focus your thoughts, do whatever works for you. If you are working with others, ask them how they'd prefer to see the document broken down and how they would expect to use it.

I would expect to see a prose description of the salient points of the game: it's main concept, style and feeling. I would then expect to see a section for each major feature of the game.

Do not go overboard with detail and statistics, remember that a design document is typically something that will evolve over the lifetime of the game as you build and iterate. It's impractical to think that you'll write it once, up front, and it will be perfect, so focus on what you need the document to convey now and how you can best convey that to the specific consumers of that document.

It doesn't matter what other people do, you want to do what works best for your team.

share|improve this answer
    
a design document is at its core an outline of the game. the same way you write an outline for a book the only things that truly matter is what "you need" in order to understand your idea, and to make it. though I would like to reinforce the point of intended audience, and that even every subsection could have a different audience a project plan is for the team/manager, use cases/ERDs are for the programmers, and entity descriptions are for the artists. its one of the few times that you can write something that doesn't seem to fit together besides being about the same general topic. –  gardian06 Jun 10 '12 at 2:11

In addition to what Josh has said in his answer, several people have shared their idea of what should go in a game design doc, which may help you decide what aspects are going to be useful in your own docs. Remember that these are professional designers, and what worked for them in the context of the traditional games industry is not necessarily right for you, so it's useful to try and work out why they use certain approaches and pick the ones that will help you the most.

share|improve this answer
    
I have looked around for game design documentation and how to do it. Your first link was great. Works really well with 'scoping'. Setting up the basic scope of the project and with rough words explain what is inside and outside the scope of the game. –  Wertilq May 23 '13 at 16:31

You can also check this article for more information on the structure of your GDD. It's a really great source: http://active.tutsplus.com/articles/game-design/effectively-organize-your-games-development-with-a-game-design-document/

share|improve this answer

There is one piece of information that I'd like to add: when documenting the actual design of the game (ie: the rules), provide clear explanations for why you're making a particular rule design choice.

One of the things you're more likely to forget when you go about implementing something is the exact reason why you added a particular rule. Also, one of the things you're very likely to do is to add rules and game elements just because other games have them, not because your game needs them.

By adding a section on exactly why a game element exists, it forces you to justify the use of that element in terms of the overall game design. And later on, it allows you to effectively evaluate whether a particular element is actually serving the needs you intended it to. If it's not, then you can remove it and replace it with something else that does serve those needs.

Even better, if you find the game isn't working out, and you want to replace multiple elements to make the game more fun, you can look back at your design document and understand why you choose those elements and what new elements need to accomplish. If the needs of your game design change, then you can update your list of what the game elements are supposed to do.

share|improve this answer

I like the way Level Up author uses to write his game design documents with drawing many cute shapes, characters and etc.

I highly recommend you take a look at this book Level Up!: The Guide to Great Video Game Design

With adding little drawings to your documents the others will pay attention to you more and you can be sure they will read your design documents

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.