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?

  • 5
    \$\begingroup\$ 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? \$\endgroup\$
    – Kylotan
    Jun 7, 2012 at 17:15
  • 4
    \$\begingroup\$ 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. \$\endgroup\$
    – user1430
    Jun 7, 2012 at 17:19
  • \$\begingroup\$ 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! \$\endgroup\$
    – jcora
    Jun 7, 2012 at 17:21
  • \$\begingroup\$ You can also check this article for more information on the structure of your GDD. It's a really great source: active.tutsplus.com/articles/game-design/… \$\endgroup\$ Jun 7, 2012 at 20:10
  • \$\begingroup\$ @Josh your score is the intimidation - who's gonna try to beat you on an answer ;) \$\endgroup\$
    – Tim Holt
    Feb 6, 2018 at 7:24

5 Answers 5


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.

  • \$\begingroup\$ 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. \$\endgroup\$
    – gardian06
    Jun 10, 2012 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.

  • \$\begingroup\$ 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. \$\endgroup\$
    – Wertilq
    May 23, 2013 at 16:31

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.


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


The structure of your game design document is completely up to you, but one I create tends to include (note that this works better for RPGs or other story-driven games):

Table of Contents - Very important, as once you have more complex games you will need to include an organization method

Description of the Game - A brief description of the game, giving some descriptions of game-play, along with platform and other important details

Story overview - Give an overview of your plot

Controls - List the controls you will be using in your game

Tech requirements - You can go into more detail about platform here

Game Flowchart - Show how your game's screens connect

Presentation - Give details about camera type, HUD, and other info the player will see

Player Character - Give information about your player, such as what they look like, backstory, and tools/weapons they may use

Combat - Describe how combat works (if applicable)

Game Levels - Give some examples of levels

Enemies - Give details about your enemies (attacks, looks)

Bosses - Information about specific bosses

NPCs - Describe AIs that don't attack your character

Music/SFX - What music and SFX need to be produced

Appendices - Place long lists here along with scripts and any other information

You may also want to create a more concise version of your game design document which is about one page, containing the following things:

Title and Concept Overview - Give a brief overview of what the game is like and what players will do

Platform - List the platform the game will be published on

Main Points - Give the very basic info about your game, such as it being an FPS, an MMO, and having a single-player mode

Summary - Summarize your plot, if any

Characters - Give some info about your characters


Not the answer you're looking for? Browse other questions tagged .