Как вести документацию при разработке игры — интервью с Константином Сахновым

Александр Семенов, App2Top: Костя, привет! В этом интервью я хочу поговорить с тобой о документации. Тема, казалось бы, не очень сложная, но, на самом деле, с огромным количеством подводных камней. Готов?

Константин Сахнов

Константин Сахнов, Vengeance Games: Буду рад!

Отлично. Один из первых вопросов, с которым сталкивается молодая команда: в чем вести документацию?

Константин: Если речь идет именно о командной разработке, то одним из наиболее удобных и востребованных решений является Confluence. Среди его плюсов — интеграция с Jira, Trello и Slack.

Но есть и нюансы. Confluence трудно использовать, находясь в России. Во-первых, нужно иметь иностранную карту для оплаты. Во-вторых, при работе с российского IP приходят письма, уведомляющие о блокировке аккаунта через 30 дней.

Это значит, что для работы с инструментом вам потребуется корпоративный VPN на всю команду, либо переезд из России.

Если вы инди-одиночка, то альтернативой может вполне стать Notion.

К сожалению, мне пока не удалось найти российских аналогов Confluence или Notion, которые могли бы закрыть все основные потребности разработчиков в плане ведения документации. Но мне понравился сервис Weeek.

Для работы с документацией гейм-дизайнеры также любят Google Docs, но вести в нем документацию большого коммерческого проекта затруднительно.

Знаю команды, которые перед разработкой много времени посвятили выбору документации. Они мечутся между Obsidian с его чудесной системой внутренних ссылок, более простым и универсальным Notion. Даже смотрят в сторону текстового редактора GitHub. Хотят иметь под рукой сразу базу знаний, которую могут одновременно вести несколько человек. Что думаешь об этом?

Константин: Внимание к средствам работы с документацией может защитить от ее потери или долгого и неприятного процесса переноса материалов из одной системы в другую.

Но главное, на мой взгляд, это не система работы с документацией, а те пайпланы, и та культура, которая принята в команде. На одном из небольших проектов мы ведем всю документацию в Google Docs (даже диаграмму Ганта рисуем в «Google Таблицах»).

Пример списка документа по одной из игр автора

Можно ли сказать, что всеобъемлющий дизайн-документ и в целом база знаний — это документы о том, что сделано, а не о том, что нужно сделать?

Константин: В некотором смысле да.

Фундаментальная проблема любой документации — актуальность.

Сложность состоит не в том, чтобы написать сотни страниц описаний, технических заданий и формул. Не в том, чтобы придумать и зафиксировать. Сложность — в том, чтобы не пропустить ни одно изменение, которое вскользь озвучено продюсером на проектом собрании, предложение одного из членов команды, которое было принято, фактические корректировки при реализации, сделанные программистами с целью оптимизации.

Если документация не актуальна, как можно использовать ее для интеграции в команду новых сотрудников? Как можно тестировать по ней функционал игры? Зачем она тогда вообще нужна?

Ты сейчас заговорил про актуальность. Всегда есть проблема апдейта документации. Возникают новые фичи, исчезают старые… Плюс постоянно выкатываются билды на обкатку. Очень много билдов, которые могут отличаться друг от друга всего парой измененных цифр. Нужно ли это вообще фиксировать? И, в целом, что следует заносить в документацию, а что — нет?

Константин: Чтобы ответить на этот вопрос, нужно вспомнить, что документация в геймдеве бывает не только продуктовая, о которой мы обычно говорим. При разработке игр нам часто приходится иметь дело с административной (в которой прописываются регламенты, правила, штатные расписания и структуры отделов), юридической (она посвящена договорам, соглашениям и т.д.) и проектной документацией. Кейс с билдами имеет отношение к последней.

Допустим, у нас есть дизайн-документ по механике лутбоксов. В версии 2.1.1 лутбокс выдавал не более четырех предметов. Со следующей версии количество предметов стало не лимитировано. Это вопрос к составу билда, а значит это следует зафиксировать в проектной документации.

При этом в дизайн-документе необязательно хранить всю историю обновлений. Мы просто обновляем документ, указывая как работает или должна работать та или иная механика сейчас.

Если через пару лет разработчик захочет вернуться к старому балансу, то в этом случае у него должно быть то решение по работе с документами, в котором есть система контроля версий, позволяющая найти вариант документа за определенную дату.

Это еще один важный довод в пользу выбора специализированных систем ведения гейм-дизайнерской документации. В Google Docs или MS Word это будет сложно осуществить. Впрочем, я сталкивался с кейсами использования OneDrive и SVN для хранения документов.

Конечно, также всегда важно: кто должен все это заносить? Должна ли это быть отдельно оплаченная позиция или это позиция продюсера или «проджекта»?

Константин: Каждый имеет свою зону ответственности. Дизайнерская документация контролируется гейм-дизайнерами. И если она не актуальна, то должен именно к ним возникать вопрос — почему.

Проектная документация, касающаяся сроков, процессов сборки, заливки и проверки билдов, чаще всего готовится проджект-менеджером и руководителем QA.

Продюсер отвечает за свои документы — виденье проекта и состав версии, например.

Хорошей практикой является отвечать за написанный вами же документ. Кто автор — тот и следит за актуальностью. Но без выстроенных процессов информирования автора об изменениях, такая модель работает плохо.

Давай вернемся к началу нашего разговора. Представим, что команда только принялась за создание игры. Какой должна быть документация на первом этапе разработки, когда программист еще не садился за код? Что в ней должно быть, а что можно проигнорировать?

Константин: Краткой и понятной. Чем больше ваш документ, тем меньше вероятность, что его дочитают до конца. Документация не предполагает разночтений и двояких трактовок. На своих занятиях я всегда привожу пример идеального документа, который я встречал в своей жизни:

Сразу все понятно: что нужно делать, что не нужно, какие будут последствия, кто исполнитель…

Вся документация на начальном этапе разработки должна быть в первую очередь доступна и понятна читателю.

Из этого прямо следует еще один тезис: не нужно додумывать за исполнителя его работу. Прежде чем описать спецификации, именования конфигов, переменных, прописывать другие технические нюансы реализации, пообщайтесь с программистом и согласуйте, каким оно будет, что ему нужно знать о фиче, чтобы начать работу над ней.

Конечно, если ваша команда давно сработалась и сделала уже не одну игру, гейм-дизайнеры хорошо понимают, что нужно разработчикам. Но даже в таком случае могут быть нюансы, связанные со спецификой конкретного проекта.

Стоит ли работу над игрой вообще начинать с документации? Может, достаточно договориться на пальцах о структуре игрового процесса? Дескать, прикинули в Miro основные механики, цикл кора — и погнали?

Константин: Мне трудно представить себе игровой продукт, который можно начать делать без документации. Более того, до момента, когда потребуется писать продуктовую документацию, нужно провести огромное количество работы!

Как гейм-дизайнеру мне очень трудно писать дизайн-документ, не имея на руках исследования рынка и понимания конкурентов, целевой аудитории, возможностей нашей команды.

Как руководителю студии или бизнеса мне невозможно представить себе начало работы хотя бы без оценочных финансовых документов. Да, сроки, косты и механики продукта обязательно изменятся в процессе реализации. Скорее всего, в худшую сторону. Но без базового понимания, что такая игра вообще имеет шанс окупить свою стоимость, я бы вообще не рискнул браться за работу.

Что уж говорить о неоднозначности трактовок! Нарисовав в Miro схему геймплея и отдав ее программистам, вы получите не свой прототип, а то, как задачу увидели и поняли программисты.

Да, если мы говорим о прототипировании, то в некоторых случаях такое допустимо. Давно сработавшиеся команды, простые, к примеру, гипер-казуальные игры…

Но я всегда стараюсь готовить полноценную документацию, независимо от проекта.

Часто бывает сложно соблюсти баланс между наполненным перфекционизмом стремлением подготовить всеобъемлющую и выверенную документацию и предпринимательским рвением сделать недорого и сейчас. Однако именно соблюдение баланса необходимо. Я не сталкивался с кейсами, когда эти крайности работали бы хорошо в коммерческой разработке.

Вот мы сейчас с тобой затронули тему с программистами и их видением. Давай тогда на этом остановимся. Как работать с программистами? Особенно на начальным этапах. Я сталкивался с ситуациями, когда задачу для них формулировали максимально расплывчато, чуть ли не ограничиваясь только направлением, а дальше «отпускались вожжи». Это распространенная практика?

Константин: К сожалению, это более чем распространенная практика.

Сам факт того, что на начальном этапе у нас нет точного видения продукта, — это абсолютно нормально. Четкое техническое задание можно написать без поисков только в том случае, если мы делаем клон.

Если же мы хотим привнести в жанр хоть немного уникальные механики, я уже не говорю про USP, у нас всегда будет неясность в том, как выглядит, играется и ведет себя продукт.

Более того, продюсеру может казаться, что он точно знает и видит игру. Но без реальных плейтестов это лишь видение.

Но это не значит, что у нас не должно быть точного технического задания и мы просим программиста сделать «как-то так». Это значит, что у нас много технических заданий. Мы делаем один вариант, оцениваем его, сверяемся с критериями, опытом, ощущениями. Если понимаем, что это не то, пишем новое техническое задание и снова по кругу.

Видения может до какого-то момента не быть, но техническое задание быть должно.

Мне всегда казалось, что если гейм-дизайнер умеет программировать, то это большая удача. Он сам можем запилить механику, тут же ее опробовать, тут же выкинуть или, наоборот, решить, что она годится. Что делать, если гейм-дизайнер этого не умеет? Как оценить придуманную механику, которая существует исключительно в виде блок-схемы и пары таблиц в Excel?

Константин: Я стараюсь никогда не просить гейм-дизайнеров писать код. На мой взгляд, есть понятная парадигма: программист пишет логику и инструментарий, гейм-дизайнер создает игровой опыт.

Важно этой парадигмы придерживаться и держать в голове: не программист настраивает ощущения от выстрела или расставляет в движке объекты. Всю работу с контентом делает гейм-дизайнер. Он придумал, как хочет, чтобы игрок стрелял, значит он должен настраивать оружие, понимать его свойства и считать баланс.

Задача программиста — предоставить инструментарий для того, чтобы, не зная C#, C++ или иного языка, гейм-дизайнер мог настроить выстрелы так, как он хочет.

Что касается самостоятельной оценки геймплея, то для этого есть Unity Bolt, UE Blueprints, скриптовые языки JSON, XML, LUA, YAML…

Иногда можно сделать бумажный прототип —- настолку, иногда самому собрать в простых движках, типа Buildbox или GameMaker. Но многие вещи можно спрототипировать, только привлекая к работе программистов.

Давно, когда я хотел показать продюсеру и коллегам свои задумки, я делал прототип в Adobe Flash и оживлял его с помощью Action Script. Потому перешел на HMTL5 и JS. Это отличный способ сэкономить время, объяснить, чего ты хочешь добиться от команды, но очень часто механику невозможно оценить без полноценной реализации, сбалансированного контента и визуальной составляющей.

Представим, что механику программисту мы объяснили, он его классно реализовал… И тут возникает вопрос: а в какой момент в документацию приходит математика, формулы, баланс? Нужно ли о них думать, серьезно к ним относиться на первых этапах разработки?

Константин: Если вы серьезные корпоративные ребята, обладающие некоторым запасом времени и финансов, вы можете себе позволить с самого начала расписать хорошую математическую модель, отдавая себе отчет в том, что в дальнейшем она все равно претерпит изменения. Я грешу именно этим и с трудом перестраиваюсь с корпоративного прошлого на подход инди-разработчика.

Если вы тот самый инди, на начальном этапе вам часто достаточно общего понимания, какие примерно формулы будут использоваться. Иногда даже можно заменять точные и сложные модели заглушками (некоторые из них доживут до релиза).

Пример формулы из игры Shadows of Vengeance

Я большой фанат математики и сюжета, поэтому приходится себя останавливать, когда берусь за проработку таблиц с балансом или пишу сценарии.

Но вот то, что точно стоит добавлять в продуктовую документацию на самом раннем этапе — примеры использования механики. Допустим, вы пишете большой дизайн-документ по механике заклинаний. Покажите парочку заклинаний, которые вы хотите видеть в игре. Не полный список, не математически выверенный баланс, а именно пример контента, который будет реализован на этой механике.

Хорошо, математику на первых этапах можно опустить, а что ты скажешь про скрин-фейки, по которым можно понять, какой будет игра, когда будет готова. Сейчас, насколько я понимаю, это распространенная практика. Но действительно ли они нужны?

Константин: Фейк-скрины — важная история. Они нужны:

• чтобы произвести впечатление на инвесторов. Это нормальная практика, т.к. оценить потенциальный продукт без визуализации довольно трудно;
• для маркетинга, чтобы команда смогла протестировать, может ли выбранный подход к графике заинтересовать аудиторию, есть ли отклик;
• для внутреннего пользования. В этом контексте я бы назвал их таргет-артом. Чтобы выработать визуальный стиль своего продукта, очень важно иметь картинку, которая устраивает нас по качеству и отражает наши производственные возможности. Для инди это не всегда актуально. Также как и для тех, кто точно определился со стилем, мудбордом и работает по уже готовому гайдлайну.

Соответственно, если мы принялись рисовать фейк-скрины, есть ли место в документации подробному описанию визуального стиля, элементов интерфейса, вот этому всему или лучше накидать примеров, общих пожеланий художнику, а затем уже дотюнить результат?

Константин: В разных студиях принята разная практика. Когда я работал в компаниях, оперирующих большими бюджетами, мы составляли подробную документацию по арту. В студиях поменьше можно ограничиться мудбордом — презентацией или доской в Figma, на которой собраны арты из сети или сгенерированные ИИ изображения, отражающие наше видение ключевых ассетов игры: персонажей, строений, визуальных эффектов, элементов интерфейса, магии, материалов и т.д.

Фрагмент мудборда из игры автора

Представим, что наша разработка убежала вперед. Документация тоже прилично распухла. О чем стоит думать/помнить в этот момент, на какие вещи в ее ведении следует обращать внимание?

Константин: Как мы уже отметили, в первую очередь документация должна оставаться актуальной.

Большие проекты часто страдают наличием десятков устаревших статей, и лишь гейм-дизайнер знает, что в этом хаосе следует читать, а что можно пропустить.

Чтобы такого не происходило, должны быть правила обновления документации и ответственные, с которых можно спросить.

В какой-то момент может потребоваться реструктуризация разделов Confluence, которые уже не отражают разросшейся структуры проекта и стали неудобны для навигации.

Один из ключевых принципов ведения корпоративной документации на продукт — удобство поиска и чтения превыше удобства написания.

Есть и другой подход. Когда вы инди-команда, часто удобно сказать ОК, этот документ выполнил свою задачу, мы переносим его в архив и движемся вперед.

И последний вопрос: как считаешь, как сильно зависит успех проекта (в данном случае — доведение его до релиза) от грамотной документации?

Константин: Игры — это венчур. Их коммерческий успех зависит от всего сразу и ни от чего в полной мере. Нет такой документации, которая гарантирует успех, как нет такой конституции, что защитит демократию.

Что же касается доведения проекта до готовности к релизу, то здесь зависимость от качественной документации совершенно прямая. И что очень важно, не только качество, глубина проработки и лаконичность документов играют свою роль. Сам процесс работы с документацией, прививающий ответственность, — крайне важная часть разработки.

Но как всегда в геймдеве везде есть исключения. Если вы инди-одиночка, невероятная целеустремленность часто бывает важнее выверенной документации, единственным читателем которой часто являетесь вы сам.