Текст книги "Хочу в геймдев! Основы игровой разработки для начинающих"

Документация: гейм-дизайн-документ

Итак, вы сумели создать vertical slice, поработали над отдельными фичами, и вас ждет этап полноценного производства. Теперь необходимо, чтобы по каждой фиче мы имели полное описание от гейм-дизайнеров и грамотные оценки от исполнителей и продюсера. На этом этапе вам предстоит составить гейм-дизайн-документ.

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

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

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

ГДД – это развернутое описание, как вы ведете пользователя к нужным ощущениям, для отдельной системы или для проекта целиком. На основании этого документа формируется (как часть ГДД) практическая инструкция для исполнителей – техническое задание (сокращенно ТЗ). Здесь хранится вся информация для программистов, художников, тестировщиков и т. д.

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

В шапке ГДД на отдельную фичу всегда обозначен человек, ответственный за нее, – FEATURE OWNER, – чтобы при возникновении вопросов любой член команды знал, к кому можно обратиться за пояснениями. Если фича уже реализована и по ней проведена аналитика, ссылку на ее результаты также прикрепляют в начале документа. Это конкретные, заранее продуманные метрики любых взаимодействий с фичей и их последствия. В некоторых компаниях заранее, еще на этапе составления ГДД, записываются метрики, которые должны отслеживаться; а когда готов аналитический отчет, он закрепляется в шапке или рядом.

Далее ГДД содержит ИНФОРМАЦИЮ ОБ ИТЕРАЦИЯХ, чтобы можно было сразу понять, на каком этапе находится работа над фичей. Например, итерация 0 – базовое описание функционала, итерация 1 – что нужно поменять/добавить и т. д. Для разных итераций могут заводить отдельные ГДД.

Итак, первым делом необходимо обозначить КОНКРЕТНЫЕ ЦЕЛИ, почему вы хотите ввести ту или иную фичу. Цели должны быть достижимыми и измеримыми, чтобы впоследствии проверить, достигли мы их или нет. Это нужно бизнесу и менеджменту, чтобы иметь информацию для принятия решения, делать их или нет, исполнителям, желающим лучше понять, для чего они работают над той или иной задачей, и вам, чтобы восстановить ход размышлений спустя какое-то время. Четкие цели помогают экономить время и не читать все ГДД в поисках ответа, зачем же делали ту или иную фичу.

Причиной возникновения фичи не должны быть аналоги у конкурентов или «мне кажется, будет круто». Без анализа «зачем» нельзя понять, насколько реализация необходима. «Повысить Retention», «увеличить конверсию в платящих игроков», «снизить процент отваливающихся через неделю игроков» – хорошие цели, основанные на конкретных метриках. Еще лучше, когда есть объяснение, почему выбрано это решение, а не другое, и почему оно должно понравиться разным категориям игроков. Сюда прилагают результаты опросов, аналитики, любые данные, подтверждающие вашу гипотезу. Этот пункт должен предполагать методы проверки, насколько успешной окажется фича после завершения работы над ней.

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

К описанию важно прилагать РЕФЕРЕНСЫ. Гифки, видео, картинки помогают понять, о чем идет речь, намного быстрее, чем длинный текст. Когда вы смотрите на готовые решения и видите некоторое количество отличий от собственных предложений, вы можете задуматься, а почему решение реализовано именно так, а не иначе. Ответ на этот вопрос – еще один шаг к проверке собственной идеи.

Можно составить ЮЗЕР-СТОРИ, то есть описать, как игрок будет взаимодействовать с каким-то игровым элементом: как узнает о новой опции, как поймет принцип ее работы и взаимодействия с другими элементами, а также, например, как защититься, если игровые соперники применяют новую опцию против него. Описание самой фичи здесь минимально, все внимание сосредоточено на ходе мыслей игрока, сталкивающегося с ней, с самой первой встречи. Цель – воссоздать эмоции и цепочку возможных рассуждений игрока, сформулировать желаемую мотивацию. Не просто ввести новую фичу, но понять, почему она станет ценной.

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

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

ЮЗЕР-КЕЙСЫ – это примеры конкретных взаимодействий игрока с фичей. Юзер-кейсы должны покрывать весь предлагаемый функционал. Это описание последовательности игровых изменений, зависящих от действий игрока. Например, нажимая на эту красную кнопку, игрок видит такое-то сообщение (всплывающее окно), в верхнем левом углу появляется таймер; когда время заканчивается, таймер начинает пульсировать; по истечении времени он со взрывом исчезает. Важно описать, как система должна реагировать на все возможные варианты действий игроков, включая негативные, когда игрок делает что-то не по плану гейм-дизайнера.

Если юзер-стори описывает ситуации глазами игрока, то юзер-кейсы описывают происходящее с точки зрения системы. Тестировщик будет проверять, что все работает так, как вы задумали, исходя именно из ваших юзер-кейсов. Грамотно составленный список юзер-кейсов не позволяет QA[61]61
  . QA (от англ. quality assurance – «обеспечение качества») – тестировщик.


[Закрыть] пропустить какую-то проблему функционала.

Раздел КОНФЛИКТЫ нужен, чтобы предусмотреть, как создаваемая фича или ее часть взаимодействуют с другими игровыми системами. Такая работа дает возможность заранее увидеть потенциальные конфликты и конкретные шаги по устранению проблем взаимодействия. В разделе, посвященном игровому балансу, мы детальнее рассмотрим примеры, когда отдельные элементы игры, будь то просто предметы экипировки или даже целые фичи, могут вступать в конфликт друг с другом. Такая ситуация часто приводит к дисбалансу по Гарфилду, о котором мы поговорим позже. Пока же просто представим себе ситуацию, что в игре есть ресурсы, один из которых – нефть. Это может быть, к примеру, тактическая онлайн-стратегия. Если на этом ресурсе базируется сразу несколько механик, они неизбежно будут конкурировать за него в голове игрока. Если использование обеих механик не обязательно для игрового процесса, то конфликта нет. В противном случае игрок будет находиться в ситуации неполноценности, пока не прокачает обе фичи. Стоит понимать, что единый ресурс для многих механик не является проблемой сам по себе. В целом это хорошая идея. Конфликт может быть создан конкретной реализацией.

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

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

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

ИНСТРУМЕНТЫ УПРАВЛЕНИЯ

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

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

Если в вашей команде есть человек, ответственный за управление командой, JIRA – самый популярный в игровых компаниях инструмент. Наиболее эффективно Jira работает с плагинами, но почти все они – платные. Кроме того, Jira сама платная после достижения определенного количества пользователей. Если команда небольшая, вполне можно обойтись простым и бесплатным Trello.

TRELLO – очень популярное решение для небольших (до восьми человек) команд. Классическая модель предлагает три колонки: список задач, задачи в работе и выполненные задачи: To Do, In Progress, Done. Можно завести отдельную доску под бэклог, чтобы собирать там все идеи по проекту, а после планирования спринта перекидывать выбранные строки в To Do.

Можно настроить, кто имеет право двигать задачи между колонками. Обычно только Scrum Master, если такой есть в команде, двигает задачи из бэклога в список того, что нужно сделать. Человек, который берет ответственность за какую-то задачу, лично перетаскивает ее в раздел «в работе», а Scrum Master переносит ее в «выполнено», когда убедится, что результат соответствует ожиданиям.

CONFLUENCE – это база знаний, открытая для совместного доступа к документам и их редактированию. Если вы используете Jira, оно станет для вас удобным инструментом, так как они интегрированы. Если вы не рассматриваете для себя платный софт, вполне нормально пользоваться Trello и GOOGLE-ДОКУМЕНТАМИ.

Нередко встречается, что документация по всему проекту ведется в одном огромном doc-файле. В этом случае лучше сделать отдельную страничку, содержащую ссылки с описаниями на все остальные части файла, чтобы любой член вашей команды мог легко найти нужную информацию. Записывайте краткое резюме всех встреч и звонков и сделайте для этого отдельный документ (взять на себя эту обязанность может Scrum Master).

Последнее, что вам понадобится, – это какой-либо мессенджер. Выбирайте любой привычный. Хочется отметить здесь SLACK, так как он интегрирован с Trello и имеет множество полезных функций: например, есть возможность заводить отдельные каналы для разных обсуждений, здесь удобная система тегов по группам, «напоминалки», текст сообщений можно сразу конвертировать в задачу и многое другое.

ТЕХНИЧЕСКИЕ ЗАДАНИЯ

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

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

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

Обычно ТЗ ставится ведущим специалистам направления, а те уже распределяют задачи между своими сотрудниками. Гейм-дизайнер редко может лучше поставить задачу, например на написание кода, чем руководитель программистов.

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

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

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

Контроль версий

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

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

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

Систем контроля версий довольно много. Самые известные: Git, SVN, Perforce, Mercurial и др. В отличие от смены игрового движка, перейти с одной системы контроля версий на другую несложно.

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

Рассмотрим подробнее SVN и Git.

SVN – это две сущности: репозиторий (хранилище данных), который лежит на удаленном сервере, и рабочая (локальная) копия проекта, с которой взаимодействует сотрудник.

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

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

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

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

Рис. 16. Схема SVN

Commit – сохранение, фиксация (в архиве, репозитарии и др.) изменений в программном коде. Update – сверка текущей версии кода у сотрудника с версией в репозитории и обновление её в случае наличия более новых файлов на сервере.

Работа с GIT выглядит так: есть удаленный репозиторий, локальный репозиторий и рабочая копия. Это значит, что появляется один дополнительный по сравнению с SVN шаг – синхронизация локального репозитория с удаленным. Это дает большое преимущество – возможность работать сразу над несколькими задачами. Пока изменения, которые вы вносите, находятся в промежуточном состоянии и могут «сломать» версию, они сохраняются в локальном репозитории, не создавая проблем остальным. Так что сотрудник может в любой момент вернуться к выполнению задачи.

Допустим, мы работаем над чем-то рискованным: например, решили поменять всю игровую физику. Чтобы не мешать остальным сотрудникам, имеет смысл создать отдельную ветку. Ветка – это последовательность изменений, параллельная ветка репозитория. Она не влияет на главную версию, так что сотрудники могут работать над своими задачами одновременно, не боясь что-то сломать.

Рис. 17. Схема Git

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

В SVN тоже можно создать отдельные ветки, только в общем репозитории. Но Git позволяет работать с ветками гораздо быстрее и удобнее.

Когда все будет протестировано и принято, изменения можно будет внести в основной проект.

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

Continuous Integration, то есть практика разработки, при которой рабочие копии постоянно сливаются в основную ветку, предполагает, что никто не работает «в стол», а как можно быстрее отдает свою работу в общий проект. При таком подходе версия игры не должна собираться раз в месяц, все должно быть собрано хотя бы за последние пару дней. Живая версия, в которую сотрудники могут поиграть, интегрируется непрерывно, чтобы вовремя отследить возможные проблемы.

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

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

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

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

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

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

Еще одной базовой вещью при работе с репозиторием является система хуков (hooks). Это скрипты, срабатывающие при определенных событиях и проверяющие входящий коммит – операцию фиксации изменений. Например, мы можем заранее обозначить разрешение для текстур, чтобы исключить возможность ошибки художника. Или запретить создавать ссылки на несуществующие файлы. Крупные студии могут создавать более сложные правила проверки, например, чтобы вносимые изменения не могли нарушить сложные отношения игровых сущностей. Такая автоматизированная проверка помогает избежать лишней работы по исправлению вручную, ведь всегда проще предотвратить, нежели потом чинить.

Другая проблема заключается в том, что сборка крупного проекта в билд, в который можно поиграть, может быть долгой. Неэффективно, когда каждый сотрудник студии для ознакомления с новой версией игры должен вручную запускать сборку и ждать, пока компьютер обрабатывает ее сорок минут. В этом случае на помощь приходят билдеры – программы, позволяющие непрерывно собирать версию (например, Teamcity). Обычно такой софт бесплатный и несложный в настройке.

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