How to create TK for a programmer

Recommendations to the game designer from the programmer (architect).

Introduction

Computer games are a relatively young industry that will change the film industry in the future, just like movies have replaced the theater. Creating a game is a collective creation , much like a movie. In addition, the creation of computer games is one of the most difficult IT tasks, since it includes all of itself practically all IT areas.

Everyone has heard about pre poduction , but few people know exactly how this happens. And if much has been written about the development stage, and even more about the publication stage, very little is known about the planning stage. At best, you are lucky enough to get acquainted with the results of planning . But how were these results achieved? - a riddle in the dark .

This document is the result of "debriefing" after writing the game Star Arena for social networks. In this document, I tried to streamline the list of problems and solutions that Alexander and I came to in the process of working together on the game. In addition, this document is part of a lot of work on building a workflow for creating computer games.

I deliberately left behind the scenes other documents: a concept, a business case, and TK for other performers. This allowed us to focus on one topic and to cover it, and only in sufficient detail.

The most important:

1. A clear understanding of the end result. (Quality control.)
2. Deadlines.

Why do we need documentation:

1. Save time on communications. (Write once, instead of retelling 100 times, confused in the testimony.)
2. A way to see what the finished project will look like.
3. Analysis and identification of problems is still at the planning stage. (The sooner an architectural error is discovered - the cheaper it is to fix it)
4. Fixing decisions made. (Accurate evidence, instead of scattered rumors of varying degrees of freshness.)
5. Work planning.

What are the documents:

1. Concept (“What about the game?”)
2. Specification (What do we want to get?)
3. Terms of Reference (How this is arranged - it will be discussed about him.)
4. Work plan (How will we do this.)

Who is involved in the discussion of TK:

The sooner feedback from interested specialists is received, the less unnecessary work will be done.

1. Game Designer (Writing Documentation)
2. Architect (Tracking the completeness and details of the description, decomposition.)
3. Programmer (Evaluation of the volume of work.)

Documentation requirements:

The more sloppy the design will be, the less people will generally begin to read it . Readers are incredibly resourceful in order to avoid unpleasant work for them. Therefore, it is so important to make sure that reading documentation is as easy and enjoyable as possible.

1. Formatting (Easy to print and nice to read / hold)
2. Highlighting key phrases. (To read the document diagonally)
3. Making lists. (Instead of solid text)
4. Splitting long lists into groups. (Three items per group)
5. Repeated repetitions. (Avoid document references)
6. Date, page number, number of pages, pagination. (For exact references when discussing what is read)
7. Table of contents, list of documents, history of changes. (For searching documentation / versions)

Requirements for the content of TK

There is no clear list of requirements that documentation must meet. Therefore, the development of TK is suspended long before approaching its fullness. As a result, the next stage of development begins without TK, in the hope that TK will be added along the way, or even based on the results of development.

1. Russian language. (No memes, distorted English terms, Albanian language, or other rubbish. Even a lot of internal documentation is read.)
2. No common words like:
   • all possible options
   • the card is invented by a computer
   • interaction of various objects
   • after all actions, etc.
3. All names of types of entities (classes) must have:
   • Russian name (for the player)
   • English (for code)
   • short description (transcript / hint / comment)
4. An entity should have only one name. (So ​​that the “armor” does not turn on another page into an “armor” or “shield”).
5. Suggestions should be complete and understandable to the reader without a close examination of the context. (Do not imply that the reader himself will guess what the author meant)
6. All that can be measured must be measured.
   • image sizes in pixels and bytes
   • the number of columns and cells in the table
   • number of characters in the text box
   • number of weapons per level
   • session time, etc.

The main requirements for the result of the programmer's work:

These important requirements are implied, but never voiced by anyone.

1. System flexibility to change. (Dynamic requirements.)
2. Automatic error data collection. (Feedback.)
3. Easy to launch and configure by customer. (Demonstration of the result.)

The first stage of writing TK:

Description of the subject area, its formalization in terms understandable to programmers.

1. Database (metadata)
   • list of object types
   • characteristics of objects
   • relationship / dependency between objects
2. Business processes (full game cycle)
   • process list (work scenarios)
   • functional list (what should be able to)
   • list of expected changes (what could be)

The second stage of writing TK:

How the product should look / work for all types of users (players and administrators).

1. Interface (visual part)
   • list of game screens with names (or groups of elements)
   • a list of items on each screen with names and text hints
   • a description of the behavior of the elements (wink, tooltip, blocking, pop-up dialogs, etc.)
2. Admin (management)
   • server (vital / system indicators)
   • game content (sales, quests, monsters, things, shops, drop, locations, etc.)
   • game data (content generated by players)
   • statistics and reports (what statistics do you need to collect?)

The third stage of writing TK:

How are we going to do it all.

1. Necessary technology research
   • List of requirements for each technology
   • Description of tests / demonstrations of each technology
   • List of future requirements / possible problems (what's next?)
2. A list of requirements for different types of content (resources) for the game (the size of the picture of swords, the length of the names of quests, varieties of special effects, the size of videos, etc.).
3. List of essential tools for working with content (map editor, quest admin panel,).
4. Prioritization of tasks.
5. Requirements for the first working assembly (what the first prototype should be able to do).
6. List of other iterations of project development with requirements for their results. (What needs to be shown at the end of each stage to complete it)

Documentation support

1. Most of what is written in the first stages is outdated and will need to be rewritten long before the end of planning.
2. The main principle of the first stages of planning: to arrange a list of sections and make a list of questions for each section.
3. The lower the detail in the initial stages, the better. (the number of types of weapons, instead of a complete list with names, the number of quests by level, instead of their detailed list, etc.)
4. The easier it is to find the right item in the documentation and change it without affecting the rest - the better. Therefore, you should avoid graphical schemes and solid text from complex sentences. Leave graphic presentations and emotional descriptions for final reporting.
5. After each planning cycle, check and test the completeness of the documentation and the uniformity of its level of detail. (If in a house of 5 rooms only one is described, you need to describe the other four, or throw out a detailed description of one room, so that all rooms are described equally equally .)
6. Make a list of uncomfortable questions . There are always dark spots, and they try to get around and shut up, not realizing it.
7. Provide concise instructions to end-users . The final performers should not be faced with full documentation, and the painful search for the right mention throughout the entire volume.
8. A sign of mastery : each next level of planning refines, but does not change, the results of a description of more abstract levels. It is a good skill of moving through the levels of abstraction / detail that allows you to move from an fits of descriptions of details to a planned listing of entities.

Cutting corners

Any technology will be simplified to the point of absurdity to reduce the amount of work and costs. Chemical yeast bread, alcohol wine, development without documentation.
Many people think that documentation is not needed if:

1. The project is in 2-3 months.
2. A team of 2-3 people.
3. Limited budget. (He is always limited)
4. No documentation requirements. (Nobody knows how to do it)
5. There is no use to her. (Never used documentation)

However, it should be remembered: the development of documentation takes 40% of all efforts. And it determines the 90% probability of successful completion of project development.

First steps

It is strongly recommended that beginners choose the "clones" of classic games as their first projects . While there is no successful experience in such a game, there is no vision of the entire product development cycle. So there is no understanding of how to get to the finish line .
You should not start developing a game without writing at least two full TK as an exercise . This may be TK for arkanoid. But this must be a TOR by which developers can write a full-fledged arkanoid, even if they have never seen this game before.