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?
|
|
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. |
||||
|
|
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.
|
|||
|
|
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/ |
|||
|
|
|
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 |
|||
|
|
|
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. |
|||
|
|