UE-разработка в рамках Gorilla Warfare

Gorilla Warfare — это мультиплеерная PvP-игра на Unreal Engine, построенная вокруг коротких динамичных матчей, хаотичных сражений между обезьянами, гранат, интерактивного окружения и нескольких игровых режимов.

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

В течение года моя работа была сосредоточена на технической основе проекта: сетевой логике, игровых режимах, настройках матча, системах раунда, интерактивных объектах и поддержке стабильности проекта.

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

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

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

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

После базового подключения сессий появилась задача сделать фильтр для поиска серверов, чтобы в списках лобби не было чужих игр. Это было сделано через параметры Steam Sessions: перед отображением лобби проверяется название игры и версия билда. Благодаря этому игрок видит только совместимые сессии Gorilla Warfare, без чужих проектов и серверов другой версии.

Старт раунда проходит через отдельную логику ожидания игроков на сервере. Матч не начинается, пока все участники не подключились на карту.

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

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

В Banana King игрок возвращается в матч после смерти, потому что режим построен вокруг постоянного сбора бананов и изменения счета.

В Straftat смерть работает иначе: игрок выбывает до конца раунда, потому что там выигрывает последний выживший.

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

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

Отдельно была реализована система очков. Данные о текущем счете игроков хранятся в PlayerState, а общая информация о ходе матча и правилах подсчета находится на стороне сервера в GameState и GameMode. Благодаря этому каждый клиент получает актуальные значения через репликацию и использует их только для отображения в UI.

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

Еще один важный элемент матча — система улучшений. Сейчас она подготовлена как техническая база для будущей механики между раундами.

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

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

Игровые режимы построены через наследование от общего класса GM_Gameplay. В нем находится логика, которая одинакова для всех режимов: запуск и завершение матча, переходы между состояниями, работа с игроками и базовые сетевые события.

Конкретные режимы — GM_Banana_King и GM_Straftat — наследуют эту функциональность и переопределяют только ту часть логики, которая отвечает за правила игры. Таким образом общая структура матча остается единой, а подсчет очков, обработка смерти игрока и условия победы реализуются отдельно для каждого режима.

Banana King — режим, где победитель определяется по количеству собранных бананов в конце раунда.

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

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

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

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

Матч продолжается до заданного количества побед, которое выбирается в настройках лобби. За счет этого Straftat работает не как один короткий раунд, а как серия раундов с понятным условием завершения.

Выбор режима происходит в лобби до загрузки карты. Система берет путь выбранного уровня из Data Table, формирует ServerTravel-команду и передает нужный GameMode через параметр «? game=`». Именно поэтому Banana King и Straftat запускаются на выбранной карте через одну общую логику перехода, без ручной смены GameMode в настройках уровня.

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

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

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

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

После систем матча и игровых режимов отдельным направлением стала работа с объектами на уровнях. В Gorilla Warfare арена не должна быть просто статичной площадкой: окружение должно влиять на движение игроков, создавать опасные ситуации и давать дополнительные игровые возможности.

Одним из таких объектов стали поезда. Они работают как динамическая опасность на уровне: движение строится по spline, через который задаются начальная и конечная точки маршрута, а сам поезд перемещается между ними с заданной скоростью.

Основные параметры вынесены в переменные прямо на объекте, поэтому их можно менять при размещении на уровне: скорость, дистанцию движения, остановки, плавность перемещения и появление предметов на остановках. Благодаря этому один и тот же Blueprint можно использовать в разных ситуациях, не создавая отдельную логику для каждого поезда.

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

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