Как правильно составить дизайн документ

Советы новичкам от опытного геймдизайнера

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

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

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

Тут важно отдельно выделить человеческий фактор. Даже при самом идеально написанном техническом задании (далее, ТЗ) будут те, кто его поймёт не так. Кто-то неправильно интерпретирует очевидный вам оборот. Кто-то не будет знать термина или будет знать его омоним (которые в индустрии встречаются довольно часто). Кто-то просто пропустит строчку, читая по диагонали. Действовать с такими людьми жёстко — с высокой вероятностью угробить собственную компанию.

Некоторые, желая сэкономить, нанимают геймдизайнера только для написания документации — результат обычно плачевный. Фильмы не снимают без режиссёра, даже когда из Marvel уволила гениального Эдгара Райта и он оставил после себя максимально полные раскадровки, они всё равно наняли другого человека, чтобы тот доделал фильм. Хотя раскадровки Райта, конечно, лезут из всех щелей и теоретически можно было бы работать по ним.

Теперь о том, как писать сам ГДД. Крупные компании используют для этого сервисы вроде Confluence, но я, поработав в них, нахожу их не особо удобными, по сравнению с самым доступным способом ведения документации — Google Docs. Легко заполнять, легко делиться, легко ориентироваться, да ещё и бесплатно. Если вы беспокоитесь за безопасность, всегда есть возможность сделать корпоративный аккаунт Gmail и тогда никто за пределами студии не зайдёт в вашу документацию.

Следующий большой вопрос — ГДД в одном файле, или как набор ТЗ. Скажу прямо — оба варианта имеют право на жизнь. Первый вариант имеет смысл использовать если у вас небольшой проект вроде match-3 или подобной игры. ГДД до 20 страниц объективно удобнее хранить одним куском. Если же у вас есть гора различных режимов или контента, например миллиард различных танков для WoT, или подробное описание каждого уровня для шутера, то лучше это всё распихать по разным документам, оставив главному лишь структуру.

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

Оглавление

В малом проекте с этим всё просто — оно делается штатными средствами документов. Или не делается вообще, что тоже бывает. Если же у вас крупный проект, да ещё и с иерархией, то в главном файле лучше расписать всю его структуру со ссылками на все остальные файлы. Если у вас в проекте есть иерархия, то не стоит ложить ссылку на самое дальнее ТЗ только в промежуточном.

В мой первый месяц работы у меня случилась неприятность: я выложил спецификации по самолётам для World of Warplanes в один подраздел (за давностью лет не помню уже в какой), а программисты искали его в соседнем (художники, кстати, не промахивались). Сначала я хотел продублировать ссылки, чтобы их можно было найти везде, но потом я понял, что правильнее просто выложить все ссылки в виде структуры прямо в главном документе. Тогда сразу появляется понимание структуры проекта и не нужно делать лишних кликов для перехода на нужную страницу.

Вступление

Место для краткого описания игры. Фактически краткая выжимка концепт-документа: название, технологии, платформы, аудитория. Это информация не для вас и не для вашей команды, а для продюсеров, которые, открывая ваш документ, должны мгновенно понять, что у них в руках. И заодно понять, не лажанулись ли вы с позиционированием и своими возможностями.

Базовый геймплей

Необходимо выделить для себя, какая часть игры у вас является базовой, то есть, в чём игрок будет проводить больше всего времени. Например, в нашумевшей Gardenscapes игрок в основном играет в match-3, хоть это и не подчёркивается. Там создатели делают упор на обустройство сада, а match-3 как бы второстепенное занятие, служащее для зарабатывания звёзд. Но на самом деле в этом разделе нужно описывать именно его.

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

На этом этапе часто встаёт вопрос: как структурировать написанное так, чтобы программисту его было легко читать. Перепробовав множество разных вариантов, я пришел к выводу, что лучше всего поступить так: в каждом разделе использовать свою нумерацию с иерархией. То есть, пишете утверждение. Под следующим номером другое утверждение. Если у вас есть уточнение или дополнение к основному утверждению, то переходите на один уровень вглубь и пишите там. Например: 1. Персонаж двигается в изометрии при помощи WASD. 1.1 Если игрок направляет персонажа в стену, тот останавливается при столкновении со стеной. 2. При нажатии на ЛКМ игрок стреляет. И так далее.

Важно описать всё не красиво, а точно, не упустив ни малейшего аспекта. Баг, сделанный программистом, чинится им же в ограниченное время. Дизайнерский баг (непродуманный момент) может разом перечеркнуть многие месяцы работы команды. «Не ошибается тот, кто ничего не делает» — отличная фраза для такой ситуации, потому что не реально предусмотреть всё, но одно дело не продумать один экран, а совсем другое — ошибка в базовой механике, из-за которой всё неиграбельно.

В первые три-четыре года работы геймдизайнером и в первые три-четыре месяца на новом рабочем месте вы обязаны подружиться с лидом программистов, чтобы скидывать ему свеженаписанные ТЗ с вопросом: «Нормально?». Это значительно повышает их качество и снижает время, потраченное на разбирательства.

На минутку вернувшись к теме хорошего геймдизайнера, могу сказать, что он ежесекундно должен ставить себя на место других людей и задавать себе вопросы: «Что мне понятно из этого экрана?», «Что будет понятно обычному геймеру?», «Куда бы я нажал, если бы открыл это меню в первый раз?», «Как может человек интерпретировать эту иконку?» и ещё около миллиарда таких же. Главный же вопрос гейм-дизайнера (если уходить в дебри) это «Почему?» . От «Почему PUBG такой популярный?» до «Почему эта фича, которую я придумал, будет востребованной?».

HUD или интерфейс базовой игры

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

На самом деле искусство создания хорошего HUD — это огромная наука, специалистов в которой очень мало. Лучше всего составлять его совместно с арт лидом и быть готовым, что переделывать его наверняка придётся.

Интерфейсы и главное меню

Этот раздел статьи я хочу начать с рассказа о том, что такое мокап. Или варфрейм. В индустрии очень часто одни и те же сущности в разных студиях называются по-разному и если у вас что-то из того, что я называю в статье, называли по-другому — это проблема отсутствия единого профессионального словаря. Итак, это — схематичный набросок, сделанный в графическом редакторе человеком, максимально далёким от рисования. Здесь не стоит задача сделать красиво, здесь стоит задача сделать понятно. Чтобы художник без лишних вопросов гармонично расставил кнопки и всё остальное.

Лично я для этого использую программу Pencil Project, но вы вольны выбирать всё, что угодно. Хоть карандашом на бумаге рисовать и фотографировать. Вместо картинок — прямоугольники, кружочки, стрелки. Минимализм.

Теперь о том, что этими самыми программами мы будем рисовать. Начать лучше всего со схемы экранов. Возьмите все ваши экраны и окна и разложите на экране. Проведите стрелочки: откуда куда игрок может переходить. Это своего рода интерфейсное оглавление, которое поможет собирать проект.

Дальше идут мокапы всех окон, начиная с главного меню, и заканчивая самым маленьким окошком с кнопкой «Ок» . Не забывайте про то, как из них выходить! Под каждым мокапом должно быть краткое и понятное описание каждой кнопки и другого элемента окна и что они делают. Лайфхак для сложных экранов: возле каждого элемента поставить кружок с числом, а снизу пронумерованные пункты.

Когда художник отрисует это окно, рекомендую наложить эти же кружочки на его рисунок и подменить его в ГДД. Это поддерживает актуальность и понятность, особенно если в процессе отрисовки что-то изменилось, например, положение кнопок.

Остальные фичи

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

Функциональные разделы

В конце ГДД можно вставить несколько разделов, которые являются очень полезными для некоторых жанров.

Балансировка — описание того способа, которым гд будет балансировать игру. Нужен практически для всех игр, особенно f2p. Оптимальным вариантом для меня является xml-файл, который конвертится и заливается по специальному адресу. Потенциально ужасный вариант — веб-интерфейс, в котором каждый параметр нужно вводить ручками.

Админка — возможность банить и поощрять пользователей через веб-интерфейс. Необходима для он-лайн игр.

Сбор статистики — жизненно необходимая вещь для f2p. Перечислить все точки сбора статистики и формат её получения.

Minimum Value Product или MVP — описание минимально играбельной версии, которую можно выложить на общий доступ, чтобы проверить, насколько ваш базовый геймплей востребован. Необходимо если вы делаете f2p и придумали оригинальный геймплей.

Чего НЕ должно быть в ГДД?

Прежде всего — описаний анимаций. Это самая частая ошибка новичков. Называйте действия конкретно: «Пушка стреляет». Да, у вас мультяшный стиль и пушка перед выстрелом надувается, будто тужится — всё это не важно программисту, а аниматор лучше вас знает особенности движка и как сделать всё атмосферно. А пожелания лучше передавать ему лично.

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

Текстов. Выделите под них отдельный файл, желательно xml, чтобы программисты легко могли подтянуть его прямо в игру. А потом его же будете локализовывать.

Литературных описаний — никто не оценит.

А что дальше?

После того, как вы написали все ТЗ и лид программистов уверенно сказал «Нормально», вы переходите на главную часть работы геймдизайнера — коммуникации. Если эта статья вам понравится, то я напишу ещё одну — как правильно выдавать работу разным специалистам и принимать результаты.

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

Научитесь: Профессия Геймдизайнер с нуля до PRO
Узнать больше

Как написать диздок

Запрос «как написать диздок», заданный в любой поисковик, даёт немало ответов, представляющих собой как перевод западных статей, так и авторские размышления на эту тему из России, или даже дизайн проекта «Курочка Ряба». В воображении читателя предстает большой единый документ, описывающий идею и геймплей игры с перечислением всех ее фич. Возможно, читатель однажды приходит с такими идеями работать геймдизайнером в крупную российскую или западную компанию, на крупный проект… И обнаруживает, что таких документов больше не существует.

О том, как написать диздок, который существует в крупных компаниях (автор этих строк работал с документацией Obsidian Entertainment, Allods Team, Raven Software, The Workshop, Slightly Mad Studios, преподает курс проектной документации в геймдизайне в Высшей школе бизнес-информатики НИУ ВШЭ на программе профессиональной переподготовки Менеджмент игровых интернет-проектов), и будет эта краткая статья. Разумеется, кому-то описанное в ней может показаться очевидным. Она рассчитана на тех, кто как раз ищет ответы на вопросы «как написать диздок» или хочет устроиться работать геймдизайнером в крупную компанию-разработчика.

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

Почти всегда это вики-движок. Наиболее популярен Atlassian Confluence, но можно встретить и MediaWiki, как правило, с множеством плагинов и используемый в «старых» компаниях, и DocuWiki для небольших pet-project’ов или для маленьких студий. Поэтому готовность работы с документацией крупных проектов стоит начинать с умения работать с принятым на проекте вики-движком. То, что описывается как “диздок”, обычно заменено тремя отдельными документами в вики:

• Концепт-документ – краткое изложение самой идеи игры. Вида «У нас будет онлайн-игра про запуск и перехват ядерных ракет с бесконечным геймплеем, зрелищными спецэффектами и асинхронным PvP!». В нём описывается идея и основные составляющие игрового процесса (очень кратко), а также пара самых ключевых USP («unique selling point», то, что «продаст» идею игроку и уникально на рынке).
• Vision – это уже более развернутый документ, описывающий то, что хочется получить в итоге. Не сам игровой процесс, а всю игру, как конечный бизнес-продукт.
• Feature List (может быть обёрнут в другие документы в зависимости от модели разработки) – список с кратким описанием фичей, того, из чего состоит игра. К примеру, сборка ядерных ракет, аркадный перехват, асинхронное PvP, клановая система, система достижений, и так далее, как правило, со ссылками на отдельные документы с подробным описанием геймдизайна (об этом далее). Также в нем каждой фиче выставляется приоритет, стоимость и последовательность разработки.

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

Теперь переходим к Vision. Этот документ уже масштабнее, и обычно включает в себя следующие элементы:

1. Краткое описание игры. Здесь уже не только основная идея, а игра в целом.
2. Жанр игры.
3. Целевая аудитория и исследование рынка.
4. Примеры подобных игр на рынке и отношение к ним: конкуренты они или нет, есть ли пересечение аудитории, заимствование или противопоставление идей.
5. USP (Unique Selling Points) игры – то, что выделит игру на рынке, и что использует маркетинг для привлечения трафика / новых игроков.
6. «Формула успеха» – какие элементы игры будут самыми качественными / важными. Это может быть революционная графика, честная физика и т.д. Здесь в отличие от USP нужна не уникальность, а качество.
7. Составляющие геймплея, вкратце.
8. Сеттинг и стиль игры. Например, жестокий киберпанк в жёлто-серых тонах, светлое эпичное фэнтези в аниме-стиле, только куда подробнее и с примерами арта;
9. Бизнес-модель, в том числе монетизация.

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

Третий же документ Feature List представляет собой «разбор» описанной двумя предыдущими документами игры на компоненты. Это мостик к, собственно, разработке. Сообразно описанному в нем, продюсер или иной руководитель может составлять планы, рассчитывать майлстоуны, спринты и многое другое, но эта тема достойна отдельной статьи.

Простой же геймдизайнер, утроившись на работу в крупную компанию, вряд ли будет составлять вышеописанные три документа, но прочитать и запомнить их придётся. Основное время геймдизайнера уходит на последующий уровень — самый масштабный по объему. Это диздоки конкретных фичей, описанных в Vision и Feature List’е. К примеру, дизайн ездовых животных или дизайн нанесения клановых эмблем на броню… Впрочем, есть и куда более масштабные: дизайн системы характеристик персонажа или дизайн развития базы игрока.

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

Однако в любой крупной компании нужно сочетать три вещи:

• Шаблоны. Да, шаблоны и творчество могут казаться трудно совместимыми, но если на проекте несколько геймдизайнеров, и каждый пишет, как ему вздумается, продюсерам и исполнителям это радости не добавит.
• Связи с другими документами, фичами и задачами. Каждый диздок – это не просто сферический текст в вакууме. Он входит в какую-то группу (например, PvP-фичи), ссылается на другие документы, содержит в себе список задач (в JIRA/Bugzilla/Trello/GitHub/…), оценки готовности, ссылки на отчеты тестеров и результаты плейтестов.
• Собственно, фан и геймплей! За всеми слоями структуры диздока важно не потерять то, что игра все-таки должна быть интересной и увлекательной, фича должна работать в плюс всей игре, а не просто выполнять оторванную от общей идеи задачу.

Что же стоит описать в диздоке? Помимо просто описаний самой фичи, есть немало других элементов:

• Автор и статус (черновик, в работе, сделано, отказались, устарело). Когда на вики сотни диздоков, и за долгие годы работали десятки геймдизайнеров, без этих простых разделов понять, какой диздок актуален, затруднительно.
• Текущая задача. Что хочется получить. К примеру, обеспечить игроков развлечением, пока тренируются войска в казармах.
• Причины возникновения задачи и необходимости решения. Важный пункт, наличие которого спасает от фичей «чтобы круто было» или «у конкурентов есть». Последнее – бич многих геймдизайнеров, когда фичи копируются подчистую, даже несмотря на то, что многие их элементы в разрабатываемой игре лишние, не будут работать или работают в минус, даже если у конкурента это USP и приносит огромный доход.
• Краткое описание решения. Чтобы можно было охватить общую идею.
• Развернутый дизайн. Подробное описание реализации.
• Ожидаемое поведение игрока, типовая сессия. Нужна для того, чтобы ответить на вопрос «А как в это играть?» с позиции игрока. Без этого легко получить фичу, которая вроде бы и имеет смысл, но игроки на форумах пишут “И что это вообще такое?”.
• Место фичи в игре и связь с другими фичами. Очевидно, фича должна поддерживать и дополнять другие фичи или общий геймплей игры, а не повторять или подавлять их собой.
• Задачи на реализацию и ассет лист. Список того, что нужно сделать, чтобы фича заработала: какие функции на уровне кода, что нарисовать художнику, нужно ли написать тексты реплик персонажей сценаристу и т.д. Иногда это составляет продюсер, но нередко и сам геймдизайнер.
• Требуемая статистика. Какую информацию собирать и анализировать с плейтестов и серверов. Как много времени игроки проводят в геймплее фичи? Ездят ли они на лошадях или автомобилях в фиче о средствах передвижения, стреляют ли из Сайги или Вепря в ближнем бою шутера?
• Требуемое тестирование (+ edge cases). На что QA-отделу обратить особенное внимание при проверке фичи. QA могут такое составлять и сами, но нередко только геймдизайнер может сходу сказать, что «если вдруг игрок эксплоитами типа сложения эликсиров наберёт 1000 навыка Торговли, то сможет продать товар дороже, чем купил, и сломает всю экономику! Поэтому нужно убедиться, что такое невозможно даже теоретически».
• Deployment и оперирование. Раздел для оператора. Как описать фичу в patch notes? Нужно ли выложить о ней статью в энциклопедию игры? Требуется ли что-то отобрать у игроков и выдать компенсацию для запуска фичи?
• Планы на будущее. Собственно, все идеи, которые могут улучшить фичу в будущем.

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

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

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

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

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

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

Какой итог?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• MediaWiki;
• DokuWiki;
• Markdoc;
• Sphinx.

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

Помимо 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 ведем на каждом проекте полноценный глоссарий, в котором приведены утвержденные названия всех сущностей.

Итог

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

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

• Как написать хороший дизайн-документ?
• Бенчмаркинг в игровой разработке или с чего начать создание игры?