Как Highstreet Market масштабировал VR MMO с ECS для Unity

Highstreet: Calamity — это городская часть MMORPG следующего поколения Highstreet Market. Команда выпустила её для игрового сообщества, чтобы протестировать основные функции, такие как бой и прогресс.

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

Highstreet: Calamity: Пример использования Unity

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

Когда они начали настраивать свою сетевую игру, команда столкнулась с двумя основными проблемами: неэффективностью вычислений и рендеринга.

«С точки зрения вычислений, нашей главной задачей было эффективно обрабатывать вычисления. «Это особенно верно для нашего сервера, который отвечает за симуляцию мира», — говорит Джек Цяо, технический директор Highstreet. «Когда мы добавили больше игроков и сетевых сущностей, сервер struggled to efficiently process all of them.»

С точки зрения рендеринга, создание больших, иммерсивных VR миров является сложной задачей. «VR требует увлекательной среды с множеством объектов и точек интереса для исследования игроками», — объясняет Цяо. «Но автономное VR-оборудование имеет ограниченную мощность GPU по сравнению с современными GPU ПК, что ограничивает то, что мы можем рендерить.»

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

Результаты

Достиг 72 fps в наиболее оптимизированных игровых зонах

Сократил количество вызовов отрисовки Scriptable Render Pipeline (SRP) с 80 до пяти

Уменьшил количество треугольников в одной сетке с двух миллионов до 500 000

Принятие ECS для Unity для сетевой эффективности

Сначала команда построила пользовательский сервер на основе транспортного слоя Mirror для обработки потока данных и игровой логики. «В то время большинство сетевых инструментов были разработаны для казуальных мобильных игр, а не для крупных MMO, поэтому нам пришлось создать свои собственные», — говорит Омар Слеам, главный технический архитектор Highstreet.

Когда Unity представила Netcode for Entities — готовую к производству структуру, созданную для производительности и масштабных игр — команда увидела возможность перейти на систему компонентов сущностей (ECS) Unity и Netcode for Entities. Разработанная с учетом масштабируемости, структура ввела деление на части, которое разбивает сложные игровые данные на более мелкие, более управляемые единицы — то, что команда считала необходимым для их MMO.

«С помощью Netcode for Entities данные отправляются только игрокам в пределах диапазона, а не транслируются на весь сервер», — объясняет Слеам. «Кроме того, он многопоточный, что делает операции сервера гораздо более эффективными.»

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

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

Для управления структурой игры, основанной на сессиях, команда опиралась на экосистему многопользовательских сервисов Unity. Multiplay Hosting обеспечивал динамическое распределение серверов, что было идеально для сессионной природы игры. «Автоматизация снизила нашу нагрузку на DevOps и позволила сосредоточиться на создании самой игры», - говорит Слим. Matchmaker использовался для группировки игроков на основе различных факторов, таких как настройки и местоположение, что помогало обеспечить сбалансированные и низколатентные матчи.

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

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

Улучшение модульности с ECS для Unity

Хотя команда столкнулась с крутой кривой обучения во время перехода от дизайна на основе GameObject к ECS для Unity, производительность значительно улучшилась, как только они начали работать.

«ECS для Unity снизил много накладных расходов – отчасти из-за своей архитектуры, а отчасти потому, что мы перешли к подходу дизайна сверху вниз», - говорит Цяо. «В отличие от GameObjects, которые часто приводили к дублированию логики, если не были тщательно спроектированы, ECS для Unity обеспечивал модульный, компонентный дизайн. Это естественным образом способствовало более чистым и поддерживаемым системам.»

Команда поделилась, что одним из самых больших преимуществ ECS для Unity является то, как легко было справляться с изменениями в игровом дизайне. «В старой системе изменения часто требовали редактирования нескольких скриптов MonoBehaviour. С ECS для Unity многие изменения можно внести, просто добавив или удалив компоненты, поскольку поведения управляются системами, связанными с этими компонентами», - говорит Цяо. «В целом, модифицируемость и масштабируемость значительно улучшились с ECS для Unity, и это сделало наш процесс разработки гораздо более эффективным.»

Команда также столкнулась с серьезной проблемой в архитектуре игры. В отличие от традиционного программного обеспечения, игровая логика зависит не только от кода, но и от того, где этот код находится. Например, прикрепление скрипта вращения к колесу автомобиля симулирует движение, но применение того же скрипта к небесному кубу может запустить цикл день-ночь. Эта пространственная и иерархическая зависимость означала, что команде нужен был способ проектировать системы не только в коде, но и с точки зрения размещения и иерархии.

Чтобы решить эту задачу, Мохамед Хамди, архитектор программного обеспечения в команде, разработал креативный графический подход для ECS для Unity. Этот метод позволил команде проектировать сущности, компоненты, авторинги и системы визуально, модульно, а также определять их размещение и настройку. Таким образом, небольшие повторно используемые блоки кода могли выполнять очень разные задачи в зависимости от того, где они применялись.

Система была позже расширена для интеграции не только сущностей ECS для Unity, но и MonoBehaviours, GameObjects, деревьев поведения и графа поведения Unity. Используя комбинацию диаграмм Lucidchart и таблиц Excel, команда наглядно и эффективно спроектировала и проверила всю архитектуру игры. Смотрев в будущее, они планируют создать специальный инструмент Unity, чтобы сделать этот метод архитектуры полностью видимым в редакторе с возможностью проверки его в соответствии с фактической реализацией.

Использование гибридной архитектурной системы

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

«Одно из ключевых преимуществ заключается в обработке анимаций скинненных мешей через анимацию вершин, которую ECS для Unity может обрабатывать гораздо эффективнее, чем традиционные системы на основе костей», - говорит Альвин Джоши, технический художник в Highstreet Market. «Однако в VR как ЦП, так и ГП ограничены, и чтобы в полной мере воспользоваться анимацией на основе ECS для Unity, нам сначала нужно было уменьшить сложность сцены, чтобы освободить ресурсы.»

Из-за сложных анимаций игры их рабочий процесс эволюционировал в гибридную систему, объединяющую ECS для Unity с MonoBehaviours через систему компонентов сущностей (ECS).

Чтобы визуализировать несколько персонажей на экране, они перенесли часть обработки на ГП. Поскольку было очевидно, что ЦП будет перегружен из-за сетевых и логических аспектов игрового цикла, они использовали Систему анимации Руханка.

«Для физики мы построили все на основном физическом мире, синхронизируя все физические сущности между сервером и клиентом», объясняет Слим. «Сначала это было сложно, так как сервер синхронизировал каждую физическую сущность. Затем мы исследовали возможность наличия нескольких физических миров и столкнулись с выбором между продолжением использования локального физического калькулятора в ECS для Unity или выполнением локальной физики в MonoBehaviour.»

MonoBehaviour позволяет интеграцию с сторонними VR-инструментами, такими как Hurricane и Freehand, которые обеспечивают реалистичные физические взаимодействия, такие как нажатие кнопок или предотвращение прохождения рук сквозь стены. ECS для Unity, с другой стороны, требовал от команды создания этих систем с нуля, так как не было доступных готовых сторонних инструментов в магазине, как в MonoBehaviour.

«В конце концов, мы использовали MonoBehaviour для взаимодействий VR на стороне клиента, таких как столкновения рук, чтобы обеспечить отзывчивость и погружение», говорит Слим. «Тем временем физика на стороне сервера обрабатывала критические игровые взаимодействия – такие как удар по монстру – для валидации.»

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

Снижение количества вызовов отрисовки для стабильной производительности VR

Хотя ECS для Unity и Руханка открывают возможности для масштабирования – такие как поддержка тысяч анимированных персонажей – одной из самых больших проблем команды в VR была оптимизация производительности, особенно при жестких ограничениях CPU/GPU.

«В отличие от традиционных игр, VR полностью нагружает как CPU, так и GPU», объясняет Джоши. «Перенос нагрузки не всегда является вариантом, если сцена не оптимизирована.»

После сборки проекта они сначала провели предварительную проверку производительности с помощью инструмента OVR stat на Meta Quest, чтобы выявить тяжелые области или падения кадров. Затем они создали сборки для разработки и подключили Meta Quest к Unity Profiler для анализа передачи данных CPU-GPU, использования текстурной памяти, иерархии рендеринга и времени отрисовки.

«Чтобы улучшить производительность, мы недавно сосредоточились на снижении разрывов вызовов отрисовки, вручную контролируя рендеринг. Освещение было большой проблемой – хотя мы изначально запекали световые карты с компрессией в стиле тона, смешивание объектов с запеченными и незапеченными светом вызывало проблемы с вариантами шейдеров», говорит Джоши. «Чтобы решить эту проблему, мы полностью отказались от световых карт и приняли полностью окруженческий тонированный шейдер. Это дало нам более стабильную производительность и лучший контроль над рендерингом.

Команда также использовала прожекторы с ступенчатым затуханием и минимизировала свои варианты шейдеров – всего один целый шейдер для непрозрачных и прозрачных клипов, а возможно, и для травы. Они вручную контролировали порядок отрисовки: непрозрачные объекты на слое 1, прозрачные объекты на слое 2 и клип-объекты на слое 3. Это помогло сократить разрывы вызовов отрисовки, поддерживая согласованность пакетирования.

«Чтобы поймать скрытые проблемы, которые разделяют вызовы отрисовки, мы сильно полагались на отладчик кадров Unity для проверки пакетирования и порядка отрисовки», – продолжает Джоши. «Профилирование GPU также было одним из наших основных инструментов для оптимизации рендеринга и снижения накладных расходов на вызовы отрисовки.»

Балансировка гибкости и производительности

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

«Наша цель – поддерживать 72 fps на устройствах, таких как Meta Quest 2, но даже при количестве треугольников менее 500 000 у нас возникают проблемы с производительностью», – говорит Джоши.

Они используют SRP Batcher для снижения переключений шейдеров GPU, но в автономном VR ограничения GPU гораздо строже, чем на ПК. «Мы обнаружили, что даже сцены с двумя миллионами треугольников рендерятся плавно – если это одна сетка с одним материалом. Но открытые вертикальные среды нашей игры делают такую упрощение непрактичным», – говорит Джоши.

Чтобы улучшить производительность, команда сосредоточилась на минимизации вызовов отрисовки, путем:

Пользовательская выпечка сетки командой художников

Группировка активов в подсетки для балансировки пакетирования с гибкостью материалов

Разделение мира на чанки и генерация LOD на уровне чанков, а не на уровне активов

Стриминг чанков с использованием ECS для системы, совместимой с Unity

Использование систем LOD само по себе помогло сократить сцены с около двух миллионов треугольников до 500 000.

Этот подход пожертвовал некоторой гибкостью и увеличил рабочую нагрузку для художников, но это было необходимо с учетом аппаратных ограничений – особенно на устройствах, таких как Meta Quest 2, где разработчики не могли обновить GPU.

«В конечном итоге, минимизация количества вызовов от 80 до пяти — это наша самая большая победа», — говорит Джоши. «Мы перестраиваем контент и рабочие процессы вокруг этого — даже если это ограничивает разнообразие материалов — потому что это самый жизнеспособный путь к стабильной производительности VR на текущем оборудовании.»

Масштабирование умным способом

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

«Если вы нацелены на крупномасштабное MMO с первого дня, вам понадобится ECS для Unity, чтобы справляться с большим количеством сущностей и одновременной сетью. Если у вас нет очень детализированного видения с самого начала, поэтапное масштабирование тоже хорошо работает», — говорит Цяо. «Сначала мы выбрали подход «0 до 100», оптимизируя на ранних этапах для пикового масштаба. Оглядываясь назад, мы слишком рано переусердствовали с инфраструктурой, потребляя ресурсы, которые могли бы пойти на игровой процесс и контент.»

С точки зрения графики команда осознает плюсы и минусы VR. «Органические, мягкие сетки потребляют значительные вычислительные ресурсы и плохо работают в VR. Наша игра использует стиль мультфильма с органическими элементами, что ограничивает наш графический бюджет для других областей, таких как персонажи или дизайн окружения», — говорит Цяо.

В целом команда рекомендует выбирать более чистые, низко детализированные, технические стили окружения, чтобы максимизировать производительность в вашей VR-игре. «С более чистым дизайном сцены и миростроением вы сможете иметь больше графики и бюджет на ресурсы и графику для других вещей, таких как дизайн персонажей и структурный дизайн. Ключевым моментом является проектирование с учетом производительности», — говорит Цяо.

Загрузите Unity Pro сегодня

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