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

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

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

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

В некоторых компаниях добавляют разделы с читами для 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 и имеет множество полезных функций: например, есть возможность заводить отдельные каналы для разных обсуждений, здесь удобная система тегов по группам, «напоминалки», текст сообщений можно сразу конвертировать в задачу и многое другое.

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

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

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

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