Sharing Experience: 5 Examples of Writing Game Development Documentation

Many gamers in childhood and adolescence dreamed of developing games. Some started their journey at a young age. And only a few became professionals in this matter closer to maturity. However, now it’s not the 90s or even the early 0s, so learning game design and game development has become much easier. But game development, as before, requires not only programming skills or drawing abilities, but also competent organization. First of all, the development of documentation will help a novice developer in organizing the work process - a design document, technical specifications, a script, sketches, and so on.

However, the most important of all these documents is the design document (dizdok, DD), since it contains the maximum information about the game and is understandable to everyone. In this article, we will look at what a disdoc is, its features, unlike other documents, and examples of how it should be maintained.

What is a design document

A design document is the most complete description of your future game. In DD, you will have to not only describe what the game is, but specifically describe every detail of the game: mechanics, interface, graphics, sound, plot, etc.

A design document is being written to solve several problems at once:

1. Helps you stick to the plan - once you start development, you can get carried away with the process, forget your original ideas and just lose touch with reality. Dizdok will be your blueprint to help keep game development on the right track and avoid distractions.
2. Helps you and other people understand what you want to do - a detailed description of the game in the mass of its details will create a general vision of the project. Each member of your team will understand what is required of them, and the publisher will decide whether it is worth allocating you funds for development.
3. Shows you're serious - publishers are not interested in funding projects that aren't either super-unique or just profitable. And even more so if the development is something unrealizable. And every self-respecting outside specialist that you hire, after looking at the DD, will say whether he is ready to join the project, or the game is not worth the candle.
4. You will have a field for experiments - The document will be corrected. And more than once. It is in the document that you can examine new elements and their interaction with other components of the game, without spending money on developing a prototype, which may not be viable.

I hope that after looking at this list, you have an understanding that if a design document is, if not required, it is highly desirable. But a question arises. And how is the development of documentation for game developers?

Writing a document and looking at examples

First of all, it must be said that there are no clear rules in the design of DD. However, different companies have their own traditions and features of design documents. Only general recommendations will be given here.

First, you need to understand that you are writing a design document for both the publisher and yourself and the team at the same time. You should not try to fool the publisher by writing a separate advertising document for him in which you will promise mountains of gold, but work according to a completely different plan. They will find inconsistencies in your promises and the final product - they will drag you through the courts, and you will lose your reputation.

Secondly, although the DD should be the same for both the publisher and the team, it is still necessary to develop a document specifically for the publisher - an introductory brochure that can be either a separate document or part of a design document or concept ( significantly abridged version of the disdoc, no details). In this document, you should briefly state the name of the game, its genre, mechanics, features, timeline and costs, as well as an explanation of why your game will be bought and what benefits it will bring to the publisher. After reviewing this text, the publisher can already decide whether they should consider your project in detail.

A great example of this would be the first section in design-document free-to-play first-person shooter Dirty Bomb. In the Game pillars section. Here, developers describe the features of their product and company. They distinguish three bases, each of which has specific features. This may not be the best structural solution, but a good publicity stunt.

Ok, you've written the introductory text, now it's time to start writing the design document itself.

What should it contain? And it should contain tasks and methods for solving them, which will bring your project closer to implementation. Structurally, all your ideas and how to implement them should be divided among several main aspects of the game, such as the interface, game mechanics, story and world, software mechanics, graphics, sound and music. In short, you yourself must decide what should be given attention and to what extent.

All this can cause misunderstanding and confusion in the head. Therefore, it is best to look at documents drawn up by professionals. One good example would be dizdok of the Ryaba's Revenge project . Why should you pay attention to this document. Firstly, it is in Russian, which will make it easier for you to understand, especially if your knowledge of English leaves much to be desired.

Second, it's a good example of a clear document structure. It will help not to turn your DD into a mess of ideas by throwing everything mixed up.

Also on the web, with due diligence, you can find various templates for design documents.

For example, here is the English template, which briefly indicates what and how to write. It also has a clear structure.

And here is DD one of the parts quite popular in a series of quests with erotic elements, Larry 7. Here the story and characters are described in great detail, there is a section with the passage of the game, in which the player’s actions necessary to move through the game are indicated in the form of a list.

Another doc of a story driven project , which received a lot of awards and accolades, 3D quest "Grim Fandango". This document describes puzzles and cutscenes in detail, as well as the structure of puzzles and locations in the form of tables. Not exactly DD, but a good example of a detailed description of one section.