Вячеслав Уточкин – Хочу в геймдев! Основы игровой разработки для начинающих (страница 22)
Раздел КОНФЛИКТЫ нужен, чтобы предусмотреть, как создаваемая фича или ее часть взаимодействуют с другими игровыми системами. Такая работа дает возможность заранее увидеть потенциальные конфликты и конкретные шаги по устранению проблем взаимодействия. В разделе, посвященном игровому балансу, мы детальнее рассмотрим примеры, когда отдельные элементы игры, будь то просто предметы экипировки или даже целые фичи, могут вступать в конфликт друг с другом. Такая ситуация часто приводит к дисбалансу по Гарфилду, о котором мы поговорим позже. Пока же просто представим себе ситуацию, что в игре есть ресурсы, один из которых – нефть. Это может быть, к примеру, тактическая онлайн-стратегия. Если на этом ресурсе базируется сразу несколько механик, они неизбежно будут конкурировать за него в голове игрока. Если использование обеих механик не обязательно для игрового процесса, то конфликта нет. В противном случае игрок будет находиться в ситуации неполноценности, пока не прокачает обе фичи. Стоит понимать, что единый ресурс для многих механик не является проблемой сам по себе. В целом это хорошая идея. Конфликт может быть создан конкретной реализацией.
В некоторых компаниях добавляют разделы с читами для 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 выглядит довольно просто. Сначала необходимо установить клиент этой системы на свой компьютер. После чего, зная адрес репозитория, у пользователя будет возможность получить в рабочую копию нужные ему файлы. Внеся изменения, например, в код игры, программист сможет отправить результаты своей работы на удаленный сервер.