How to create a TK for a programmer

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

Introduction

Computer games are a relatively young industry that in the long term will replace the film industry, just as movies have replaced theater. The creation of the game is a collective creativity , in many respects resembling the creation of 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 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 mystery in the dark .
')
This document is the result of a “debriefing” after writing the game Star Trek for Social Networks. In this document I tried to streamline the list of problems and solutions to which Alexander and I came in the process of working together on the game. In addition, this document is part of a great work on building up the 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 highlight it, and only its sufficiently detailed.

The most important:

1. Clear understanding of the final result. (Quality control.)
2. Deadlines.

Why do we need documentation:

1. Save time on communications. (Write once, instead of retelling 100 times, confusing testimony.)
2. A way to see what the finished project will look like.
3. Analysis and identification of problems at the planning stage. (The sooner an architectural error is identified, the cheaper it is to fix it)
4. Recording decisions. (Exact data, instead of scattered rumors of varying degrees of freshness.)
5. Planning work.

What are the documents:

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

Who participates in the discussion of TK:

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

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

Requirements for documentation:

The more sloppy will be the design - the less people will begin to read it at all . Readers show incredible ingenuity to avoid unpleasant work for them. Therefore, it is important to make efforts to make reading the documentation as easy and enjoyable as possible.

1. Formatting (Easy to type and enjoyable to read / hold)
2. Highlight key phrases. (To read the document diagonally)
3. Listing. (Instead of a solid text)
4. Splitting long lists into groups. (Three items in the group)
5. Multiple repetitions. (Avoid references to the document)
6. Date, page number, number of pages, numbering points. (For exact references when discussing the read)
7. Table of contents, list of documents, history of changes. (To search by documentation / version)

Requirements for the content of TK

There is no clear list of requirements that the documentation must satisfy. Therefore, the development of TZ is suspended long before approaching its completeness. As a result, the next stage of development begins without TZ, in the hope that the TZ will be completed on the fly, or even on the basis of the development.

1. Russian language. (No memes, distorted English terms, Albanian language and other debris. Even many read the internal documentation.)
2. No common words like:
   • all possible options
   • the card is thought up by the computer
   • interaction of various objects
   • after all the action, etc.
3. All names of types of entities (classes) must have:
   • Russian name (for player)
   • English (for code)
   • short description (transcript / hint / comment)
4. Entity must have only one name. (To “armor” did not turn on another page into “armor” or “shield”).
5. Sentences should be complete and understandable to the reader without careful study of the context. (Do not imply that the reader himself guesses what the author meant)
6. All that can be measured must be measured.
   • image size in pixels and bytes
   • number of columns and cells in the table
   • number of characters in the text field
   • number of weapons per level
   • session time, etc.

The main requirements for the result of the programmer:

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

1. System flexibility to change. (Dynamic requirements.)
2. Automatic error collection. (Feedback.)
3. Easy to start and customize. (Demonstration of the result.)

The first stage of writing TK:

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

1. Database (Metadata)
   • list of object types
   • object characteristics
   • connection / dependency between objects
2. Business processes (full game cycle)
   • process list (work scenarios)
   • functional list (which should be able to)
   • list of expected changes (which may even 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 titles (or groups of elements)
   • list of elements on each screen with names and hint text
   • description of the behavior of the elements (wink, hint, blocking, pop-up dialogs, etc.)
2. Admin (control)
   • server (vital / system indicators)
   • game content (sales, quests, monsters, things, shops, drops, locations, etc.)
   • game data (player-generated content)
   • statistics and reports (what statistics need to be collected?)

The third stage of writing TK:

How are we going to do it all.

1. Research of necessary technologies
   • List of requirements for each technology
   • Description of tests / demonstrations of each technology
   • List of future requirements / possible problems (what next?)
2. List of requirements for different types of content (resources) for the game (the size of the image of swords, the length of the names of quests, types of special effects, the size of videos, etc.).
3. List of necessary tools for working with content (map editor, admin quests,).
4. Prioritization of tasks.
5. Requirements for the first working assembly (what the first prototype should be able to do).
6. List of remaining 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 will be outdated and will need to be rewritten again long before the end of planning.
2. The main principle of the first stages of planning: 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 item in the documentation and change it without affecting the rest - the better. Therefore, it is necessary to avoid graphic schemes and continuous 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 there is only one described in the house of 5 rooms, you need to describe the remaining four, or throw out a detailed description of one room, so that all rooms are described in the same detail .)
6. Make a list of uncomfortable questions . There are always dark spots, and they are trying to get around and shut up without realizing it.
7. Provide brief instructions to end performers . The final performers should not be faced with complete documentation, and painful search for the desired mention throughout the volume.
8. Sign of skill : each next level of planning specifies, but does not change the results of the description of more abstract levels. It is a good skill to move through the levels of abstraction / detail allows you to move from the epilent description of the details to a systematic listing of entities.

Cutting corners

Any technology will be simplified to the point of absurdity in order to reduce the amount of work and expenses. Bread from chemical yeast, wine from alcohol, development without documentation.
Many people think that the documentation is not needed if:

1. Project in 2-3 months.
2. A team of 2-3 people.
3. Limited budget. (He is always limited)
4. No documentation requirements. (No one knows how to do it)
5. There is no benefit from it. (Never used documentation)

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

The first steps

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