Играю в игры, пишу в блог

Как мы масштабируем строительство: миллионы элементов в Pax Dei

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

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

В настоящее время наиболее активные зоны домашних долин содержат примерно 400 000 строительных элементов. С общим количеством 24 домашних долин на мир, каждый мир включает в себя несколько миллионов элементов. Обычно игроки добавляют около 10 000 новых элементов в неделю в одной домашней долине.

Система репликации

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

В настоящее время данные строительства для одной домашней долины составляют около 30 МБ. Это может показаться незначительным, но при 100 игроках общий объём данных, который должен обрабатывать сервер, клиенты и система репликации, достигает 3 ГБ.

Этот огромный объём требует особого подхода на каждом этапе игрового конвейера. Поскольку система репликации Unreal Engine используется для геймплея, её нельзя применять для зданий. Поэтому основой репликации строительства является пользовательский сервер бэкенда под названием «Repli», который передаёт данные о строительстве из мировой базы данных клиентам и серверам.

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

Добавление строительного элемента: что происходит за кулисами

Добавление строительного элемента включает несколько этапов за кулисами, когда игрок использует свою киянку:

  1. Клиент отправляет запрос на строительство серверу Unreal.
  2. Сервер выполняет проверку прав, чтобы убедиться, что запрос на строительство допустим.
  3. Если одобрено, сервер пересылает запрос на строительство на бэкенд.
  4. Бэкенд проводит собственную проверку для одобрения или отклонения запроса на строительство.
  5. После одобрения строительный элемент добавляется в основную мировую базу данных.
  6. Событие строительства отправляется из базы данных на пользовательский сервер бэкенда Repli.
  7. Repli распределяет событие строительства как серверу, так и клиенту.
  8. Сервер и все клиенты в зоне (в данном случае домашняя долина) создают строительный элемент.
  9. Сервер выполняет проверку целостности, чтобы убедиться, что структура остаётся стабильной.
  10. Клиент также рассчитывает целостность для отображения в пользовательском интерфейсе.

Сделать здание видимым для всех

Сделать здания видимыми для всех игроков представляет дополнительные сложности помимо массовой репликации данных. После того как клиент получил все 400 000 элементов домашней долины (упомянутый ранее пакет в 30 МБ), эти элементы нужно отобразить на компьютере игрока — что является значительной задачей.

Отрисовка 400 000 элементов последовательно непрактична. Поэтому необходимы специальные решения. Двумя ключевыми элементами являются инстанцированные статические меши (ISM) и менеджеры областей.

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

Менеджеры областей — представленные в виде параллелепипедов — контролируют все объекты и строительные элементы в своих регионах. Они отвечают за создание и уничтожение строительных элементов и объектов, расчёты целостности и управляют ISM.

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

Однако на этом задача не заканчивается. Помимо зданий, есть контейнеры, ремесленники и декоративные элементы для отображения, многие из которых имеют собственные игровые функции. Эти объекты являются стандартными актёрами Unreal, но в отличие от зданий, видимых издалека, они появляются только вокруг персонажа в пределах дистанции стриминга.

Менеджеры областей также контролируют видимость этих объектов в зависимости от позиции персонажа и дистанции стриминга клиента. Они активируют или деактивируют видимость объектов соответственно.

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

Существует ещё один тип объектов, требующий особого подхода: источники света. Когда персонаж находится рядом с ними, свет обрабатывается через систему освещения Lumen Unreal — динамическую систему глобального освещения в Unreal Engine 5 — для улучшения погружения. На определённом расстоянии источники света переключаются на легковесные световые карты для повышения производительности. В некоторых долинах одновременно может быть видно более 20 000 источников света!

Конечно, существуют и ограничения на стороне сервера. Один сервер Unreal Engine может поддерживать максимум 150—200 игроков. Если большее число игроков хочет быть в одной деревне, требуются дополнительные серверные инстансы. И здесь вновь на помощь приходят пользовательские системы. Их система репликации позволяет зданиям быть видимыми во всех серверных инстансах в реальном времени. Если игрок строит в одном серверном инстансе, все игроки в других инстансах видят изменение здания одновременно.

Несколько завершающих слов

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

Это объясняет, почему при входе в игру игроки часто сначала видят ландшафт, затем здания и, наконец, объекты.

Игроки строят с более высокой скоростью, чем изначально предполагалось. Вся система прошла множество этапов оптимизации, и планируются дальнейшие улучшения. Текущая система должна функционировать хорошо до примерно 500 000 элементов. После этого появятся новые задачи, которые необходимо решить. Хорошие новости: уже существуют планы по масштабированию системы до 1 000 000 элементов на зону — но это тема для другого раза.

Дальше