How to write dizdok

The request “how to write a dizdok”, given in any search engine, gives a lot of answers, representing both the translation of Western articles, and author's thoughts on this topic from Russia, or even the design of the project “Hen Ryaba”. In the imagination of the reader there is a large single document describing the idea and gameplay of the game, listing all its features. Perhaps the reader once comes with such ideas to work as a game designer in a large Russian or Western company, on a large project ... And he discovers that such documents no longer exist.

How to write a dizdok that exists in large companies (the author of these lines worked with the documentation of Obsidian Entertainment, Allods Team, Raven Software, The Workshop, Slightly Mad Studios, and teaches a course on project documentation in game design at the Higher School of Business Informatics, HSE the program of professional retraining Management of online gaming projects ), and there will be this brief article. Of course, someone described in it may seem obvious. It is designed for those who are just looking for answers to the questions "how to write a dizdok" or wants to get a job as a game designer in a large developer company.

Project documentation is now not a large design document, not a set of MS Office files, or even files in Google Docs.
')
This is almost always a wiki engine . Atlassian Confluence is most popular, but MediaWiki, as a rule, can be found with many plug-ins used in “old” companies, and DocuWiki for small pet-projects or for small studios. Therefore, the willingness to work with the documentation of large projects should start with the ability to work with the wiki engine adopted on the project. What is described as “dizdok” is usually replaced by three separate documents on the wiki:

• The concept document is a summary of the very idea of ​​the game. Vida "We will have an online game about launching and intercepting nuclear missiles with endless gameplay, spectacular special effects and asynchronous PvP!" It describes the idea and the main components of the gameplay (very briefly), as well as a couple of the most key USP (“unique selling point”, something that “sells” the idea to the player and is unique on the market).
• Vision is a more detailed document describing what I want to get in the end. Not the gameplay itself, but the whole game, as the final business product.
• Feature List (may be wrapped in other documents depending on the development model) - a list with a brief description of the features of what the game consists of. For example, the assembly of nuclear missiles, arcade interception, asynchronous PvP, clan system, achievement system, and so on, as a rule, with links to individual documents with a detailed description of game design (more on this later). Also, each feature is assigned a priority, cost, and development sequence.

The concept document is simple and is used to “lay the foundation” for subsequent documentation, as well as to enable a new employee, investor or journalist to quickly understand the essence of the project.

Now go to Vision . This document is already bigger, and usually includes the following elements:

1. Brief description of the game . Here is not only the main idea, but the game as a whole.
2. The genre of the game .
3. Target audience and market research .
4. Examples of similar games on the market and attitude to them: whether they are competitors or not, whether there is an intersection of the audience, borrowing or opposing ideas.
5. USP (Unique Selling Points) of the game - what will highlight the game on the market, and that uses marketing to attract traffic / new players.
6. "Formula for success" - which elements of the game will be the highest quality / important. This may be a revolutionary graphics, honest physics, etc. Here, unlike the USP, not uniqueness is needed, but quality.
7. Gameplay components , in brief.
8. Setting and style of play . For example, a brutal cyberpunk in yellow-gray tones, bright epic fantasy in anime-style, but much more in detail and with examples of art;
9. Business model , including monetization.

The sequence and goals of writing are obvious here: having written a concept document, the game designer defines the basic idea. Further, in Vision, he describes how and why this idea will work: on what audience, on the basis of what elements the project will be a success, and how it will earn money. At the same time, writing a concept and Vision is an iterative process. Having written a concept, you can try to sell the idea proposed in it (to the investor, the bosses, as a last resort - to yourself) and improve it until the idea is sold. By writing Vision, you can evaluate whether the game has chances for popularity and commercial success, and rework it, changing USP, setting, style, and other variables, until there is at least some confidence in the result.

The third Feature List document is a “parsing” of the component game described by the two previous documents. This is a bridge to, in fact, the development. According to what is described in it, a producer or another manager can make plans, count Milestones, sprints, and more, but this topic is worthy of a separate article.

A simple game designer, having tripled to work at a large company, is unlikely to compile the three documents described above, but you will have to read and remember them. The main time of game designer goes to the next level - the most ambitious in terms of volume. This dizdoki specific features described in the Vision and Feature List'e. For example, the design of riding animals or the design of applying clan emblems on armor ... However, there are much more ambitious ones: the design of the character characteristics system or the design of the player’s base development.

Of course, writing dizdok at this level strongly depends on the specific feature - it can be either a wiki document of 10 lines, or a whole section with a dozen attached documents, attached tables with calculations and links to collected statistics from game servers.

However, in any large company you need to combine three things:

• Templates Yes, templates and creativity may seem difficult to match, but if there are several game designers on the project, and everyone writes as he pleases, the producers and performers will not add this joy.
• Links to other documents, features and tasks . Each dizdok is not just a spherical text in a vacuum. He is a member of some group (for example, PvP features), refers to other documents, contains a list of tasks (in JIRA / Bugzilla / Trello / GitHub / ...), readiness assessments, links to testers' reports and results of tests.
• Actually, fan and gameplay! Behind all the layers of the dizdoc structure, it is important not to lose the fact that the game still has to be interesting and exciting, the feature should work in the plus of the whole game, and not just perform the task divorced from the general idea.

What should be described in dizdok? In addition to simply describing the feature itself, there are quite a few other elements:

• Author and status (draft, in work, done, refused, outdated). When there are hundreds of dizdokes on the wiki, and dozens of game designers have worked for many years, it’s difficult to understand which dizdok is relevant without these simple sections.
• Current task . What I want to get. For example, to provide players with entertainment, while the troops are training in the barracks.
• Causes of the problem and the need to solve . An important point, the presence of which saves from features "so that it is cool" or "the competitors have." The latter is the scourge of many game designers, when features are copied cleanly, even though many of their elements in the developed game are redundant, will not work or work in a minus, even if the competitor has a huge USP income.
• Brief description of the solution. So that you can embrace the general idea.
• Expanded design . Detailed description of the implementation.
• Expected player behavior, typical session. It is necessary in order to answer the question “How to play it?” From the position of a player. Without this, it is easy to get a feature that seems to make sense, but the players on the forums write “What is this all about?”.
• Place features in the game and link with other features. Obviously, the feature should support and complement other features or the general gameplay of the game, and not repeat or suppress them with them.
• Tasks for implementation and asset list. A list of what needs to be done to make the feature work: what functions at the code level, what to draw to the artist, whether you need to write the texts of the characters' replicas of the scriptwriter, etc. Sometimes this makes up the producer, but often the game designer himself.
• Required statistics. What information to collect and analyze with playtests and servers. How much time do players spend on gameplay features? Do they ride horses or cars in a feature about vehicles, do they shoot a shooter from Saiga or Boar in melee combat?
• Required testing (+ edge cases). What QA-department to pay special attention when checking features. QA can do this on their own, but often only a game designer can say at once that “if a player suddenly exploits such as adding elixirs, gains 1000 Trade skills, then he can sell a product more expensive than he bought and break the entire economy! Therefore, you need to make sure that this is impossible even theoretically. "
• Deployment and operation. Section for the operator. How to describe feature in patch notes? Do I need to put an article about her in the encyclopedia of the game? Is it necessary to take away something from the players and give compensation to launch the features?
• Future plans. Actually, all ideas that can improve the feature in the future.

Of course, this list may vary depending on the features, the employer and the urgency of writing the design. However, where it is necessary and possible, it is advisable not to forget about such points. As a rule, after all these points dizdok, game designer is waiting for the last item ... comments! Most wiki engines have such a function, and quite a few colleagues — from other game designers to programmers and testers — are happy to share their thoughts on your game design.



On this joyful note, my brief article ends. I hope you were interested in it. And you can go to the comments!