Как SEED рендерит мир, игроки никогда не перестают строить

Вы не можете предсказать, что построят игроки. В SEED — в этом и весь смысл, и основная задача рендеринга.

SEED — это постоянный MMO-песочница от Klang Games, созданная на Unity. Это происходит на далекой планете, где игроки управляют автономными персонажами под названием саженцы, строят дома и предприятия, торгуют в Economy, управляемой игроками, и организуют общества со своими ролями и законами. Мир продолжает существовать после выхода игроков, и он постоянно растет. Каждый новый дом, магазин, дерево и саженец оказывает большее давление на производительность рендеринга Unity на оборудовании от высокопроизводительных ПК до телефонов.

Сама симуляция работает на серверах Klang Games. Задача клиента Unity — отрисовывать любое состояние, которое передает сервер, поэтому его нагрузка зависит от того, что построили игроки, а не от того, что планировала команда.

«Поскольку SEED — это полностью серверно-авторитетная игра, клиент в основном считывает и отрисовывает состояние и пересылает взаимодействия игрока, такие как нажатие или движение камеры», — говорит Artem Dyadichkin, инженер по графике в Klang Games.

Мы поговорили с Дыадичкиным и Никитой Фетисовым, старшим инженером по геймдеву, о рендеринге обществ, созданных игроками, с использованием Universal Render Pipeline (URP), сохранении дешевизны тысяч мелких объектов и использовании реальных данных игроков для поиска узких мест на PC и мобильных устройствах.

Мир, построенный из крошечных частей

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

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

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

Здания доводят подход до крайности. Вместо того чтобы рассматривать каждую структуру как единую большую сетку, SEED строит здания из множества маленьких, похожих на кирпичи модулей: стен, полов, кровельных краев и углов на сетке в один метр. Игроки размещают грубые строительные блоки (воксели), и игра расширяет каждый из них примерно до 15 модулей, примерно половина из которых формирует внешний корпус здания, а половина — его внутреннее пространство, которое генерируется только тогда, когда игрок заглядывает внутрь. Самое большое общество на одном из самых оживленных островов SEED насчитывает 172 здания, состоящие примерно из 12 500 вокселей или 190 000 модулей.

«Мы используем BatchRendererGroup для их рендеринга и пакетной обработки, и мы выполняем эти пакеты через задания», — говорит Дыадичкин. «Несмотря на то, что нам нужно отрендерить очень много модулей, сами здания никогда не были узким местом с точки зрения чистой производительности рендеринга».

Эти задания выполняются на C# Job System, а команда компилирует их с помощью Burst compiler. Дьядичкин говорит, что они почти всегда идут рука об руку в клиентском коде SEED’.

Оставаться на пути по умолчанию в URP

SEED использует URP для масштабирования на PC и мобильных устройствах, и Klang Games намеренно придерживается настроек по умолчанию в Unity.

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

Это важно, потому что команда обновляет Unity примерно раз или два в год – SEED в настоящее время работает на Unity 6.3, внедряя новые функции рендеринга по мере роста проекта. Там, где игре нужен какой-то кастомный функционал, команда расширяет URP, а не заменяет его, используя кастомные функции рендерера для эффектов и взаимодействий, специфичных для игры.

Их использование Shader Graph следует тому же принципу. Природные объекты используют стандартный Lit shader, в то время как персонажи и объекты используют шейдеры Unlit с пользовательским проходом освещения. В любом случае, команде не нужно беспокоиться о нарушении функций производительности URP.

«Вы можете быть уверены, что если вы создадите Shader Graph, он не нарушит пакетную обработку SRP [Scriptable Render Pipeline] и не нарушит GPU Resident Drawer», — говорит Дыадичкин. «Быть уверенным, что все основные функции URP по-прежнему поддерживаются, при этом у вас остается возможность настроить все, что вы хотите в шейдере, — это очень мощно».

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

Взаимодействие с тысячами объектов

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

Когда игроки приближены, SEED использует пиксельно-точный выбор. Функция пользовательского рендерера рисует объекты в отдельный целевой буфер рендеринга, текстуру вне экрана, в которую GPU отрисовывает вместо экрана. Каждый объект закодирован уникальным идентификатором, который могут прочитать как ЦП, так и ГП. Клиент считывает пиксель под курсором, чтобы точно определить, над каким объектом наведен игрок.

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

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

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

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

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

«Это позволяет нам делать всякие вещи – отключать или включать GameObjects, или устанавливать правильные слои рендеринга для управления световой ситуацией», — объясняет Дыадичкин.

Профилирование игроков мира, которых на самом деле построили

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

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

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

Загрузка снимка большого города локально выявила неожиданное узкое место рендеринга CPU на PC.

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

Используя Unity Profiler, Дьядичкин обнаружил, что рендерный поток тратит больше времени, чем ожидалось, на отправку вызовов отрисовки. Команда использует GPU Resident Drawer, поэтому Дыадичкин ожидал, что он инстанцирует эти объекты. Frame Debugger показал обратное.

«Мы по-прежнему использовали пакетную обработку SRP, а не гибридную», — говорит Дыадичкин. Оказалось, что GPU Resident Drawer не захватывал все эти объекты, потому что почти все наши Префабы имеют группы LOD.

Разница имеет значение в масштабе SEED. SRP Batcher снижает затраты ЦП на настройку каждого вызова отрисовки, но по-прежнему отправляет один на объект. GPU Resident Drawer идет дальше, группируя объекты, имеющие общий меш и материал, в инстансные вызовы отрисовки, которые Frame Debugger помечает как гибридные батчи. С тысячами мелких объектов — вот разница между множеством легковесных вызовов отрисовки и несколькими крупными.

Виновником пропущенных объектов было анимационное переключение LOD. Эффект выглядел лучше, но он не выводил объекты на путь GPU Resident Drawer.

Мы отключили анимационную часть. «У нас все еще есть кроссфейдинг, но теперь с вручную заданными переходами», — говорит он. «Теперь вызовы отрисовки инстансированы снова, что снизило нагрузку на наш поток рендеринга ЦП».

Создание зрелого общества в мобильной памяти

На мобильных устройствах рендеринг SEED столкнулся с другим ограничением. «На мобильной стороне мы не ограничены ЦПУ — мы ограничены памятью», — говорит Фетисов. Это главная проблема нашего проекта.

Зрелое общество может содержать огромное количество зданий, уличных объектов, персонажей и мешей. Каждая сетка и материал, которые клиент рендерит, должны сначала поместиться в память. Klang Games в значительной степени полагается на Memory Profiler и memory snapshot comparisons, чтобы отследить, куда уходит память. Команда обнаружила, что текстуры хранились трижды из-за сломанной ссылки, зависимостей Addressables, дублирующих один и тот же материал, и коллекций C#, которые были намного больше, чем требовалось.

«Появилось много случаев, когда на десктопе всё было нормально, и люди этого особо не замечали, но на мобильных устройствах это была большая проблема», — говорит Фетисов. Мы в значительной степени полагались на Unity Memory Profiler, особенно на различия снимков [памяти].

Даже без текстур геометрия складывается.

«Некоторые сетки были довольно грубыми, особенно деревья», — говорит Фетисов. «Если загрузить все уровни детализации (LOD), одно дерево может занимать мегабайты памяти, а у нас много вариаций деревьев».

Поскольку команда собирает Addressables для каждой платформы, она может отправлять упрощенные деревья на мобильные устройства без изменения кода игры. «Тот же код, который загружает стул на десктопе, загружает стул и на мобильном», — объясняет Фетисов. "Но сами Addressables могут быть оптимизированными для мобильных устройств ассетами."

Более крупным изменением стала полная замена групп LOD на мобильных устройствах. Классические LOD означали хранение нескольких мешей для каждого типа объектов в памяти — те же затраты, которые описывает Фетисов в отношении деревьев. Mesh LOD, представленный в Unity 6.2, вместо этого хранит каждый уровень детализации внутри одной сетки, и мобильные варианты SEED теперь используют его исключительно. Это также снизило нагрузку на небольшую художественную команду Klang Games.

«Переход от LOD к Mesh LOD стал решающим шагом в возможности рендеринга игрового мира на мобильных устройствах», — говорит Фетисов.

Проектирование с учетом того, что игроки построят дальше

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

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

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

SEED доступен в раннем доступе. Посмотрите больше историй от разработчиков Unity в Unity Blog и Resource Hub.