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