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

Если накатывается много изменений, чтобы версия была стабильна, обычно договариваются о времени отсечки. Скажем, все изменения, внесенные после 17:00, не попадут в завтрашнюю версию. Таким образом, если обнаружатся какие-то проблемы, сегодня еще будет время для их устранения, и все сотрудники на следующий день получат рабочий билд, в который можно играть.

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

С точки зрения администратора, есть еще одна важная задача: решить, где, собственно, будет храниться репозиторий. Первое решение – личный компьютер. Это самый простой вариант, и его часто используют разработчики, работающие с Git, из-за логики локальных репозиториев, позволяющей никому не платить и работать, даже когда общий удаленный репозиторий по тем или иным причинам недоступен.

Второй вариант: поставить или арендовать отдельный компьютер под сервер, например, того же Git, который будет заниматься только этим; так делают почти все крупные компании. Это безопасно, никто извне не сможет посмотреть или получить информацию, но обычно дороже, чем другие варианты.

Можно разместить репозиторий у сторонней компании, например GitHub. Так как сервер располагается не у вас, у такой компании будет доступ к вашим файлам, но большинство инди-команд это не останавливает. Зато вы перекладываете всю работу по поддержке сервера на внешнюю фирму, что освобождает вашего системного администратора от обязанности следить за его состоянием. Большинство таких сервисов довольно надежные и не допускают у себя проблем, которые могут парализовать вашу работу.

Это решение часто бесплатное, но может налагать некоторые ограничения. Например, бесплатная версия может предполагать только публичное размещение вашего проекта или ограничить количество пользователей/объем данных и пр.

Еще одной базовой вещью при работе с репозиторием является система хуков (hooks). Это скрипты, срабатывающие при определенных событиях и проверяющие входящий коммит – операцию фиксации изменений. Например, мы можем заранее обозначить разрешение для текстур, чтобы исключить возможность ошибки художника. Или запретить создавать ссылки на несуществующие файлы. Крупные студии могут создавать более сложные правила проверки, например, чтобы вносимые изменения не могли нарушить сложные отношения игровых сущностей. Такая автоматизированная проверка помогает избежать лишней работы по исправлению вручную, ведь всегда проще предотвратить, нежели потом чинить.

Другая проблема заключается в том, что сборка крупного проекта в билд, в который можно поиграть, может быть долгой. Неэффективно, когда каждый сотрудник студии для ознакомления с новой версией игры должен вручную запускать сборку и ждать, пока компьютер обрабатывает ее сорок минут. В этом случае на помощь приходят билдеры – программы, позволяющие непрерывно собирать версию (например, Teamcity). Обычно такой софт бесплатный и несложный в настройке.

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

Игровой баланс

Какие ассоциации вызывает у вас термин «игровой баланс»? Если вы давно играете в игры, особенно мидкорные и хардкорные, вы, вероятно, вспомните про честность, правила, равные условия для всех игроков и наличие шанса на победу у каждого. Разработчики же обычно смотрят на баланс шире.

Итак, игровой баланс – это равновесие между элементами игрового процесса, объектами и средствами достижения целей. Работа с балансом – не чистая математика, это все еще работа с геймплеем. Важно знать правила своей игры, понимать ход развития событий. Лучше работать над балансом вплотную после утверждения базовых механик, чтобы не пересчитывать все характеристики заново. Только определившись с правилами, логикой и ограничениями, которые лягут в основу игры, есть смысл приступать к расчетам и плейтестам.

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

Еще на этапе создания прототипа были использованы и проанализированы первые пробные значения. Допустим, в игре есть орки и эльфы. Что они должны уметь? Образ может диктовать характеристики: ловкие, но плохо защищенные эльфы, сильные, но медлительные орки. Или наоборот: сначала у вас есть некие способности и характеристики, а образ подбирается уже под них.

Изначально важны не сами цифры, а их соотношение, базирующееся на геймплее. Что будет, если увеличить или уменьшить эти значения вдвое? Скажется ли это на геймплее? Результаты этих исследований на прототипах – ваши входные данные для дальнейшего расчета баланса. Если продукт еще не готов, можно попробовать в него поиграть хотя бы мысленно, чтобы ответить на вопросы: «Сколько атак в среднем нужно для убийства такого-то монстра?», «На каком уровне игрок способен справиться с боссом?», «Сколько максимально ресурсов может получить игрок за одну игровую сессию?» и пр.

Давайте подумаем, какого баланса вы хотите как игрок? Идеального или не очень? Чтобы это понять, необходимо определить, какой же баланс мы считаем идеальным. К примеру, если в MOBA-игре есть 100 персонажей, то идеальный баланс предполагает равные шансы победы независимо от того, какого персонажа вы выбрали. То есть на бесконечном количестве игр каждый персонаж покажет винрейт[62] 50 %.

Чтобы убедиться, что мы создали именно таких персонажей, можно запустить автотесты с ботами, которые сыграют очень много матчей и соберут нам статистику. После нескольких итераций, правок и тестирований разработчику удается добиться, чтобы винрейт у каждого персонажа с заданной точностью стремился к 50 %.

И вот долгожданные герои попадают к игрокам. И какие же отзывы получает игра? Баланса нет, уйду в «Доту»! Статистика подтверждает негативные комментарии. Один персонаж показал значительно лучшие шансы на победу, другой непопулярен, несмотря на высокий винрейт, а третий настолько часто проигрывает, что совершенно никому не нужен. Гейм-дизайнеры начинают работу над ошибками. Оказалось, что интересный лор и яркий визуал увеличил используемость некоторых героев, и они в среднем имеют более низкий винрейт, так как за них играет больше новичков. Другие герои стали популярны лишь в умелых руках, а третьи просто выпали из игры. Да и автобот, тестировавший стратегии, был