Как создать качественный дизайн-документ: советы от Rocket Jump

Зачем вести документацию при разработке игры, как это делать правильно и каким инструментарием для этого пользоваться, – рассказал ведущий гейм-дизайнер студии Rocket Jump Антон Подакин.

Доклад, по мотивам которого публикуется материал, был прочитан в начале октября в Высшей школе бизнес-информатики НИУ ВШЭ.

Антон Подакин

Почему важно писать дизайн-документ?

За 8 лет в игровой индустрии я сталкивался с разными точками зрения насчет создания гейм-дизайнерской документации. До работы в Rocket Jump, где мы выстроили грамотную структуру работы с ГДД, доводилось слышать достаточно много негатива в адрес диздоков. Гейм-дизайнеры находили разные изобретательные оправдания, чтобы не вести документацию. Вот некоторые из них:

Какой итог?

Вы получаете от исполнителя (например, художника) не то, что хотели.
В свою очередь, продюсер тоже получает от вас не то, что было нужно.
Вы тратите время на лишние объяснения и дополнения, которых можно было избежать.
Вы забываете, какие решения были приняты. В этом случае, скорее всего, придется продумывать фичу заново. А сроки уже поджимают, да и результат, скорее всего, получится не таким, как задумывалось изначально.

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

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

описание игры (ЦА, платформы, жанр);
схема геймплея;
описание механик и интерфейса;
используемые в разработке технологии;
требования к графике/арт-дизайну/звуку;
сюжет/лор;
заметки гейм-дизайнера.

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

Документация пишется для упрощения всех процессов внутри команды. Так или иначе к ней будут обращаться представители почти всех отделов разработки и поддержки проекта:

гейм-дизайнер;
продюсер;
QA;
программист;
UI-дизайнер;
сценарист;
художник;
маркетолог / комьюнити-менеджер;
новый сотрудник компании.

В каждом случае человек «выдергивает» из документа нужную ему информацию. И именно от гейм-дизайнера зависит ее качество и целостность.

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

Три всадника ГДД-апокалипсиса

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

Неоднозначность/непонятность

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

Неграмотность

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

Информация не по существу

В творческом процессе гейм-дизайнеру достаточно легко позволить себе лирическое отступление, когда дело касается любимого персонажа, механики или предмета. Помните о «скелете» — тех вещах, которые обязательно должны быть указаны в диздоке (например, если мы говорим о юните — урон, дальность атаки, описание боевой механики и так дадее). И ничего больше. Все новые идеи и дополнения можно оставить для заметок. В основном документе их быть не должно.

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

Выбор инструментария

Существует множество инструментов для работы с документацией. Из них можно выделить группу wiki-движков:

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

Помимо wiki-движков используются следующие системы:

Google Docs (или аналоги — например, офисный пакет iCloud);
Evernote;
GitHub.

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

Мы в Rocket Jump используем связку Confluence и JIRA. Первый сервис — инструмент для ведения документации, второй — известный таск-менеджер. Оба очень хорошо дополняют друг друга — например, в статью в Confluence можно интегрировать задачу из JIRA, отслеживать ее статус. При использовании других систем могут возникнуть сложности при интеграции таск-трекера с документацией.

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

Советы из практики

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

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

2). Для оформления документов лучше всего создать отдельный небольшой регламент, по которому все будут понимать, как нужно оформлять ГДД. Сюда — утвержденные шрифты, тонкости касательно форматирования, что в документе означает курсив, что нужно выделять «болдом» и так далее. В будущем это ускорит навигацию по диздоку и упростит коммуникацию в команде.

3). Стоит разработать единый для вашей команды стиль оформления ГДД и его структуру. Ниже — упрощенная структура документации, которой мы пользуемся в Rocket Jump:

4). Работая с конфигами, пропишите в диздоке те механизмы и структуры, которые вы в будущем захотите варьировать во время настройки механик. Если не сделать это заранее, велик шанс, что потом придется просить программистов «вытаскивать» из кода то, что можно было сразу вывести на поверхность. Вот пример одной из страниц нашей документации, где приведен кусок кода, с которым нам нужно будет иметь дело в будущем:

5). В работе с таблицами рекомендуется убирать под кат сгруппированные элементы таблицы, а также выделять шапки (чтобы всегда было ясно, какой тип данных записан в столбце/строке) и грамотно структурировать данные. Здесь как с кодом — если с вашими данными будет работать другой человек, позаботьтесь, чтобы он не погряз там в дебрях. Ну и не стоит пользоваться вложенными таблицами — это лишние усложнения.

6). Прописывая формулы, обязательно приводите пояснения (легенду) — за что отвечает каждая переменная, и как она взаимодействует с другими элементами формулы. В дальнейшем, если вы будете использовать одну переменную в разных точках ГДД (а такое будет), это сильно упростит работу.

7). Соблюдайте единство нейминга. Договоритесь «на берегу» и зафиксируйте в документации, как в команде будут называться юниты, предметы и прочее. Это благотворно повлияет на дальнейшую работу с локалями и не приведет к недопониманиям и лишним поискам. Никому не хочется накануне сборки патча узнать, что один и тот же юнит у четырех сотрудников называется по-разному:

Именно поэтому мы в Rocket Jump ведем на каждом проекте полноценный глоссарий, в котором приведены утвержденные названия всех сущностей.

Итог

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

Читайте также: