Вячеслав Уточкин – Хочу в геймдев! Основы игровой разработки для начинающих (страница 23)
Если операция проходит успешно, его работа сохраняется на удаленном сервере, и теперь все другие сотрудники смогут забрать новую версию игры с внесенными изменениями.
В некоторых случаях система может не принять работу. Например, возникли технические проблемы на сервере или у сотрудника нет прав вносить изменения в конкретное место и т. д.
Могут случаться и конфликты, если над одним файлом одновременно работал кто-то еще и внес противоречащие изменения. В этом случае можно отменить свою работу, пересекающуюся с работой другого специалиста, либо, наоборот, признать свою работу приоритетной, либо же открыть файл и вручную, осознанно править его. Художники обычно работают над своим артом самостоятельно, поэтому это более актуально для программистов и гейм-дизайнеров, выполняющих общие задачи.
Работа с GIT выглядит так: есть удаленный репозиторий, локальный репозиторий и рабочая копия. Это значит, что появляется один дополнительный по сравнению с SVN шаг – синхронизация локального репозитория с удаленным. Это дает большое преимущество – возможность работать сразу над несколькими задачами. Пока изменения, которые вы вносите, находятся в промежуточном состоянии и могут «сломать» версию, они сохраняются в локальном репозитории, не создавая проблем остальным. Так что сотрудник может в любой момент вернуться к выполнению задачи.
Допустим, мы работаем над чем-то рискованным: например, решили поменять всю игровую физику. Чтобы не мешать остальным сотрудникам, имеет смысл создать отдельную ветку. Ветка – это последовательность изменений, параллельная ветка репозитория. Она не влияет на главную версию, так что сотрудники могут работать над своими задачами одновременно, не боясь что-то сломать.
Дизайнеры и художники могут, например, спокойно работать в основной ветке, а программисты – в своей. Во многих студиях существует правило: «Одна задача – одна ветка», что позволяет экономить время на тестировании вносимых изменений.
В SVN тоже можно создать отдельные ветки, только в общем репозитории. Но Git позволяет работать с ветками гораздо быстрее и удобнее.
Когда все будет протестировано и принято, изменения можно будет внести в основной проект.
Ответвление позволяет также решить вопрос, как показывать билд, например, инвестору или на конференции. Всегда существует вероятность, что какое-то изменение сломает билд, а нам нужно показать работающую игру или ее часть. Вместо того чтобы ничего не делать, боясь что-то испортить (что ведет к простою и потере времени), просто создают отдельную ветку, где программисты работают только над устранением багов. В то же время их коллеги могут спокойно дальше разрабатывать игру, не рискуя потерей рабочего билда.
Continuous Integration, то есть практика разработки, при которой рабочие копии постоянно сливаются в основную ветку, предполагает, что никто не работает «в стол», а как можно быстрее отдает свою работу в общий проект. При таком подходе версия игры не должна собираться раз в месяц, все должно быть собрано хотя бы за последние пару дней. Живая версия, в которую сотрудники могут поиграть, интегрируется непрерывно, чтобы вовремя отследить возможные проблемы.
Если накатывается много изменений, чтобы версия была стабильна, обычно договариваются о времени отсечки. Скажем, все изменения, внесенные после 17:00, не попадут в завтрашнюю версию. Таким образом, если обнаружатся какие-то проблемы, сегодня еще будет время для их устранения, и все сотрудники на следующий день получат рабочий билд, в который можно играть.
По сути, работа в системе контроля версий для рядовых сотрудников – это несколько операций: забрать из репозитория данные, отправить обратно свои изменения или сменить ветку и, если нужно, посмотреть работу других специалистов. Для новичков все это может выглядеть довольно страшно, но в большинстве случаев хватает рабочего дня, чтобы более или менее разобраться, что к чему, и приступить к работе.
С точки зрения администратора, есть еще одна важная задача: решить, где, собственно, будет храниться репозиторий. Первое решение – личный компьютер. Это самый простой вариант, и его часто используют разработчики, работающие с Git, из-за логики локальных репозиториев, позволяющей никому не платить и работать, даже когда общий удаленный репозиторий по тем или иным причинам недоступен.
Второй вариант: поставить или арендовать отдельный компьютер под сервер, например, того же Git, который будет заниматься только этим; так делают почти все крупные компании. Это безопасно, никто извне не сможет посмотреть или получить информацию, но обычно дороже, чем другие варианты.
Можно разместить репозиторий у сторонней компании, например GitHub. Так как сервер располагается не у вас, у такой компании будет доступ к вашим файлам, но большинство инди-команд это не останавливает. Зато вы перекладываете всю работу по поддержке сервера на внешнюю фирму, что освобождает вашего системного администратора от обязанности следить за его состоянием. Большинство таких сервисов довольно надежные и не допускают у себя проблем, которые могут парализовать вашу работу.
Это решение часто бесплатное, но может налагать некоторые ограничения. Например, бесплатная версия может предполагать только публичное размещение вашего проекта или ограничить количество пользователей/объем данных и пр.
Еще одной базовой вещью при работе с репозиторием является система хуков (hooks). Это скрипты, срабатывающие при определенных событиях и проверяющие входящий коммит – операцию фиксации изменений. Например, мы можем заранее обозначить разрешение для текстур, чтобы исключить возможность ошибки художника. Или запретить создавать ссылки на несуществующие файлы. Крупные студии могут создавать более сложные правила проверки, например, чтобы вносимые изменения не могли нарушить сложные отношения игровых сущностей. Такая автоматизированная проверка помогает избежать лишней работы по исправлению вручную, ведь всегда проще предотвратить, нежели потом чинить.
Другая проблема заключается в том, что сборка крупного проекта в билд, в который можно поиграть, может быть долгой. Неэффективно, когда каждый сотрудник студии для ознакомления с новой версией игры должен вручную запускать сборку и ждать, пока компьютер обрабатывает ее сорок минут. В этом случае на помощь приходят билдеры – программы, позволяющие непрерывно собирать версию (например, Teamcity). Обычно такой софт бесплатный и несложный в настройке.
И Git, и SVN позволяют настроить интеграцию с различными таск-трекерами. Это помогает сразу видеть, кто, когда и по какой задаче внес те или иные изменения, что сильно облегчает процесс отслеживания работы сотрудников.
Игровой баланс
Какие ассоциации вызывает у вас термин «игровой баланс»? Если вы давно играете в игры, особенно мидкорные и хардкорные, вы, вероятно, вспомните про честность, правила, равные условия для всех игроков и наличие шанса на победу у каждого. Разработчики же обычно смотрят на баланс шире.
Итак, игровой баланс – это равновесие между элементами игрового процесса, объектами и средствами достижения целей. Работа с балансом – не чистая математика, это все еще работа с геймплеем. Важно знать правила своей игры, понимать ход развития событий. Лучше работать над балансом вплотную после утверждения базовых механик, чтобы не пересчитывать все характеристики заново. Только определившись с правилами, логикой и ограничениями, которые лягут в основу игры, есть смысл приступать к расчетам и плейтестам.
Первые цифры, скорее всего, есть уже на этапе идеи. Жанр, платформа и особенности игры обычно сразу позволяют выявить соотношение основных сущностей. Например, мобильные игры из-за размера экрана не позволяют оперировать большими числами; если игроку нужно считать в уме, тоже стоит задуматься об упрощении; чтобы показать ценность эпического предмета перед обычным, разница в их числовых характеристиках должна быть очевидной и т. д.
Еще на этапе создания прототипа были использованы и проанализированы первые пробные значения. Допустим, в игре есть орки и эльфы. Что они должны уметь? Образ может диктовать характеристики: ловкие, но плохо защищенные эльфы, сильные, но медлительные орки. Или наоборот: сначала у вас есть некие способности и характеристики, а образ подбирается уже под них.
Изначально важны не сами цифры, а их соотношение, базирующееся на геймплее. Что будет, если увеличить или уменьшить эти значения вдвое? Скажется ли это на геймплее? Результаты этих исследований на прототипах – ваши входные данные для дальнейшего расчета баланса. Если продукт еще не готов, можно попробовать в него поиграть хотя бы мысленно, чтобы ответить на вопросы: «Сколько атак в среднем нужно для убийства такого-то монстра?», «На каком уровне игрок способен справиться с боссом?», «Сколько максимально ресурсов может получить игрок за одну игровую сессию?» и пр.