I am the director of a start-up game development group (I say "group" because it is not yet an official company). I have recently gained the willingness of a few coders who are willing to help me with the project, but they are asking for documentation.

I understand the need for documentation, and I have a lot of our ideas in a few different documents, but I imagine that I will want to organize it in some way that the developers can understand individually as well as collectively.

Is there anything I should leave out of such a document; if so, what kind of things? Is there an appropriate template for this kind of document; if yes, where can I find it? Is there anything else that I should know to offer the coders before they begin their work?

I know that I have many questions being asked here. I hope that isn't a problem. Thank you in advance for any guidance!

  • 5
    \$\begingroup\$ Liz England gave a good microtalk at GDC 2016 about actionable documentation, adapting game design documentation to different audiences, with references to other useful sources. \$\endgroup\$
    – DMGregory
    Commented Oct 28, 2018 at 4:01
  • \$\begingroup\$ As a programmer myself (who is, in fact, making a game), I can say that I would want an entire notebook of detailed stats. But it would be just as easy for me to use a sentence explaining the purpose, demographic to target, and platform to make the exact same video game. \$\endgroup\$ Commented Oct 28, 2018 at 21:52

1 Answer 1


Game development usually works a bit different than application development. The reason is that games usually have far fewer and far less stringent requirements. You don't have a well-defined business problem your software is supposed to solve. The only true requirements of a game are "runs properly on the target platform", "appeals to the target demographic" and "is fun to play" (and maybe "sells a lot of microtransactions" if you are in that section of the industry). Everything else is subject to change during the development.

However, in order to make sure that all developers of the game are working in the same direction and not end up fighting to the death over creative differences, you should have some codified "vision" of how you want the final game to look and play. This vision is usually codified in a Game Design Document. Such a document usually describes:

  • The basic premise of the game:
    • The elevator pitch: The main game idea, described as briefly as possible.
    • What is the genre of the game?
    • Who is your target demographic?
    • Which platform(s) are you targeting?
  • The game mechanics:
    • What actions can the player perform in this game and how do they affect the game?
    • What non-player entities are in the game, how do they behave, and how do they interact with each other and with the player?
  • The scope:
    • How much content do you want the game to have?
    • What level of quality do you want that content to have?
  • The aesthetic direction of the game:
    • What general atmosphere do you want the game to have?
    • How do you want the game to look?
    • How do you want the game to sound?
  • When it comes to story, it depends a lot on the genre. Some games need no story at all. Many games only need a few sentences. But if you are creating a plot-driven game, like an RPG or adventure, then this can be in fact the longest part of the design document and can include:
    • A description of the world in which the game takes place and its key locations
    • A description of the important characters, their looks, their personality and their backstory
    • A basic outline of the plot which is told during the game

If you look around the web, you can find a lot of templates for game design documents. The game industry is a lot less into formalities and standardized processes than the rest of the industry, so you won't find the one ISO-standard to rule them all. Just try to find one style which fits your project, your team and your work methodology.

However, be open to changes during development. When game design documents of popular games leak to the public, either intentionally or unintentionally, you can usually notice something interesting. If you compare these early design notes to the finished game, there will usually be lots of considerable differences. This is usually the result of a design process game developers call Fail Faster:

  1. Come up with a rough design
  2. Create a simple prototype
  3. Playtest it with a critical mindset and figure out what does not work about it
  4. Revise your design
  5. Go back to stage 2

So do not be afraid to change or cut features when you realize during playtesting that they aren't actually as fun as they were in your head. Also, be open to suggestions from the team. Most people in the game development industry decided to join the industry because they want to put their own game ideas into practice. So giving your team some creative influence can be a great motivator for them. But as a good producer, it is also your duty to say "No!" if you think an idea wouldn't work or would exceed the budget.

I am looking forward to playing your game.

  • \$\begingroup\$ Thank you very much! Your detail answers my question very well, and I really appreciate the guidance. I will do my best to put this into practice for my projects. FYI (also for anyone else), my "group" can be found at ataxiagames.com. Thank you again! \$\endgroup\$ Commented Oct 28, 2018 at 14:24
  • \$\begingroup\$ I would also suggest taking a look at this forum.unity.com/threads/game-design-document-template.240038 Since I used it with a friend and it helped us a lot to sharpen the idea and get a good definition of what should be realized in which way. \$\endgroup\$
    – Nico
    Commented Oct 29, 2018 at 9:40
  • \$\begingroup\$ I can't believe nobody ever asked this question before, and this is an amazing answer for it too! I'm sure this will help a lot of people. \$\endgroup\$
    – Brian H.
    Commented Oct 29, 2018 at 11:49
  • 3
    \$\begingroup\$ One ISO standard to rule them all / One ISO standard to find them / One ISO standard to bring them all / And in the documentation bind them / In the land of waterfall development where specifications lies. \$\endgroup\$
    – OnoSendai
    Commented Oct 29, 2018 at 13:21

You must log in to answer this question.

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