Хочу в геймдев!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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