Nobody needs documentation.

Writing your ideas down is not necessary at all.

All you need to communicate with your team – is tongue.

Even if your game (app) will be in need of update, you can deal with it using only power of your mind.

For sure everyone shares your vision of how a game will look like.

Well, sadly

NO.

In real life, only the “hard work pays off”. It means that your game planning document, and furthermore – you by yourself, have to be as serious about your ideas, as impossible. Despite how funny your project is going to be.

It means you have to write down more words than your mind generate. Despite how useless it seems to be.

It means you have to describe your idea to your team as if they were 5 years old. In total.

5 needs that are fulfillable only by documentation

That’s it, in real life, there are at least 5 main reasons to document things (of course, if you aimed at profitable games, not pet-projects):

1) Write game design doc on all game development stages, in all of its states and forms. Every written game design paper gives you a lot of points of view on your project, so it would be easier for you to see any changes from different points of view. Everyone needs documentation.

2) Your ideas cost more if you can write them down. Yes, you can lose some fairy thoughts in process, but all that you will keep on paper will have x100 more chances to be implemented, than all that is only in your brain.

3) Communication. You have to ASK your TEAM about how to make a game design document (s). A tongue is not even a basic way of communication when it takes to development. It’s better for you to talk to each person in your team to define what would be the best way to keep related documentation in a good state.

4) If your product worth something, then trying to keep all the updates-related stuff in your brain will break it. Both brain and product. Offload yourself by wasting some time for a greater good.

5) Nobody shares 100% of your vision. Even more (or even less), nobody can see 100% of your vision, until you formalize it.

For those who ask about “how to make game design document” – as One told, “It is very important for me to be clear about this next point, so I am going to use a very large font. Please listen closely:  The magic template does not exist! It never has existed, and it never will exist”.

Ok, now, these are some of “must-have” docs, that each in its own way will help you.

Guide your development

It’s not a full list of documents that your project may require, yet it’s a most usual “package”.

Game Design Overview

That’s the only doc, that can be described with “sample game design document template”. It usually covers the basics of such things, like game name, genre, setting, storyline, and so on. It is often written primarily for management so that they can understand enough about what this game is, and who it is for, without getting into too much detail.

Detailed Design Document

This one will help you on the very first (and the very massive) stage of development. It usually contains all the details about most of game aspects. Well, when most of your game is done, so there are no more bunches of bunches of bunches of details, that are have to be implemented, this document got unneeded.

Technical Design Document

Often, a videogame has many complex systems that have nothing to do with game mechanics and everything to do with getting things to appear on the screen, sending data over networks, and other crunchy technical tasks. Usually, no one outside the engineering team cares much about these details, but if the engineering team is more than one person, it often makes sense to record these details in a document so that when others join the team they can understand how the whole thing is supposed to work.

System Limitations Document

As actual as heck. Now, game development tools allow you to create more than game-launching devices have capacities to work with. So such things as a number of objects per scene, number of update messages sent per second, triangles per mesh, and so on, have to be defined at the earliest stage of development.

Story Bible

While one might think that the story of the game might be determined entirely by the writers (if any) on the project, it is often the case that everyone on the project contributes meaningful changes to the story. The engine programmers might realize that a certain story element is going to be too much of a technical challenge, and they might propose a story change. The artists might have a visual idea for a whole new part of the story that the writers never imagined. The game designers might have some ideas for gameplay concepts that require story changes.

Game Walkthrough

Are you sure at all that your game is passable in all predetermined ways?

That is it, globally, there are two questions that you have to ask yourself to know what you need to get from docs. “Working on your design” will mostly mean answering these questions, so you don’t want to lose the questions.

1. What do we need to remember while making this game?
2. What needs to be communicated while making this game?