Оптимизация Sonic Dream Team для достижения целевых значений fps на устройствах Apple Arcade

Sonic Dream Team — это платформер, разработанный Hardlight и изданный SEGA. Игра, являющаяся частью серии Sonic the Hedgehog, имеет Соника и его друзей, мчащихся через извращенные сны злого Доктора Эггмана, чтобы помешать его стремлению к мировому господству.

Apple Arcade требует, чтобы студии достигали одинаковых целевых показателей производительности на всех поддерживаемых устройствах, что создает дополнительное давление на команду для оптимизации, чтобы игра выглядела отлично на всем, от iPhone 6s Plus до iPhone 16. Вот как они достигли необходимой частоты кадров как на устройствах начального, так и на устройствах высокого класса.

Sonic Dream Team: Пример использования Unity

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

После 10 лет с ёжиком Hardlight захотела нового вызова, усилив сюжет, добавив больше персонажей и смешав стили экшена и приключений с высококачественной графикой, которая отлично смотрелась на всех устройствах, на которых можно играть в игры Apple Arcade. Работая над достижением этих целей, команда столкнулась с проблемами производительности, связанными с ЦП и ГП, что побудило их продолжать оптимизацию.

Результаты

Сокращение времени кадра ЦП с 52 мс до 16 мс на устройствах средней и высокой мощности

Уменьшил размер сборки на iOS с 4 ГБ до 2 ГБ

Сократил память на выполнение вариантов шейдеров с более чем 1 ГБ до менее 100 МБ

Решение проблем с рендерингом

Для анализа производительности команда использовала различные инструменты анализа, предлагаемые Unity, в частности, Профайлер, Отладчик кадров и Профайлер памяти. Это помогло команде лучше понять, откуда возникли проблемы, чтобы достичь 30 fps и 60 fps на различных устройствах.

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

«Мы выбрали Универсальный рендеринг (URP) из-за его современного подхода к рендерингу и его дальнейшей поддержки в будущем от Unity», - говорит Фрейзер Хатчисон, технический художник в Hardlight. Команда приоритизировала такие функции, как пакетирование SRP и Shader Graph, чтобы позволить новые способы улучшения визуальных эффектов на мобильных устройствах. «Пакетировщик SRP выполнил много тяжелой работы за нас и дал нашим художникам гибкость не беспокоиться о ограничениях материалов, как это было с обычным статическим пакетированием», - продолжает Хатчисон. «В среднем у нас было 100-200 пакетов, в основном в непрозрачной очереди, что работало хорошо.»

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

Из-за размера их уровней они реализовали собственную иерархическую систему отсечения объемов, чтобы уменьшить накладные расходы на рендеринг. «Каждый уровень был разделен на большие части, которые мы называем 'островами', и отключался или включался в зависимости от положения игрока», - говорит Хатчисон. «Это также означало, что мы могли отключать аниматоры и эффекты частиц для этих островов тоже. В целом, это было легкое решение, которое хорошо соответствовало нашим потребностям.»

«Художники команды хотели графику высокого качества с множеством уникальных данных меша, эффектов шейдеров и постобработки, чтобы помочь передать мечтательное качество мира, который они создавали. С URP наличие таких функций, как встроенная постобработка, означает, что мы можем быстро создавать визуальные эффекты, не всегда нуждаясь в полностью индивидуальных решениях.» – Саймон Дью, арт-директор, Hardlight

Снижение времени кадра ЦП

Чтобы обеспечить стабильный игровой процесс на всех устройствах iOS, команда Hardlight установила частоту физики на 60 Гц, а не на стандартные 50 Гц. Они использовали FixedUpdate, чтобы обеспечить ожидаемый временной шаг между обновлениями конкретного объекта для повышения детерминизма.

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

«В конечном итоге симуляция не смогла обработать все необходимые обновления вовремя, что привело к еще более длительному времени кадра», — говорит Луис Макаан, главный инженер-программист Hardlight. Влияние одинакового временного шага физики привело к увеличению количества вызовов FixedUpdate на кадр на устройствах начального уровня, которые запускают игру на 30 fps.

Чтобы поддерживать хорошую частоту кадров на старых устройствах, таких как iPhone 6s Plus, команда оптимизировала каждый FixedUpdate. При профилировании отдельного вызова FixedUpdate они отметили, что подавляющее большинство времени FixedUpdate занимали вызовы обновления от сотен экземпляров скриптов. Хотя эти скрипты быстро выходили через условие раннего выхода, вызовы FixedUpdate все равно выполнялись.

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

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

Улучшение систем частиц игры

Команда также заметила, что чрезмерное количество систем частиц в сцене влияло на производительность CPU. В рамках системы пула частиц команда включала или отключала системы частиц, используя API ParticleSystemRenderer через компонент ParticleEffectsWrapper. С более чем 500 обновлениями систем частиц, обрабатываемыми на основном и рабочем потоках, это занимало около 5,2 мс времени кадра CPU.

«Граф визуальных эффектов Unity не был для нас вариантом в этом проекте, так как многие из наших устройств начального уровня не поддерживают вычисления на GPU, от которых зависит эта система», — говорит Хатчисон. «Если бы мы могли его использовать, мы бы извлекли выгоду из его лучшей технологии отсечения и инстансирования.»

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

«С процедурной системой Unity может безопасно отсекать систему частиц и все связанные с ней процессы, когда она вне экрана, а затем просто перематывать её в правильное состояние, когда она снова становится видимой», — говорит Хатчисон. «Это может привести к значительным приростам производительности. Однако это часто является упускаемой частью создания эффектов частиц, и очень легко случайно сделать эффект непроцедурным.»

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

«С большим количеством систем частиц в сцене стало важно убедиться, что как можно больше систем были процедурными, а если нет, то их границы рендеринга были установлены в компоненте ParticleEffectsWrapper», — говорит Макаан. «Это предотвратило ненужные вычисления и вызовы отрисовки, что значительно улучшило производительность.»

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

Столкновение с узкими местами GPU

Видение для Sonic Dream Team требовало продвинутой графики и быстрого игрового процесса. Для настройки они использовали функции рендеринга для определенных эффектов, таких как Ambient Occlusion в пространстве экрана, пользовательские эффекты на весь экран и декали в пространстве экрана. Это создало задержки рендеринга и проблемы с памятью.

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

Предварительный прогрев шейдеров также был проблемой, с значительными всплесками CPU/GPU на протяжении уровней, вызывающими подергивания. «Чтобы эффективно предварительно прогреть шейдеры на Metal, шейдеры должны содержать все необходимые ключевые слова и иметь конкретную группу вершинного макета для каждой сетки, на которой они будут рендериться. Это означало, что кэширование только в редакторе было невозможно», - говорит Хатчисон.

Чтобы справиться с этим, инженеры Hardlight создали систему для «мгновенного рендеринга» всех объектов перед камерой во время загрузки, за экраном загрузки.

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

Хотя они довольны своими результатами в преодолении предварительного прогрева шейдеров, Хатчисон рассматривает другие варианты на будущее. «С момента выхода игры Unity выпустила кэширование PSO и предварительный прогрев через GraphicStateCollections, которые мы хотим использовать в будущем.»

Снижение размера памяти с помощью Addressables

Во время разработки игра использовала 1,35 ГБ памяти во время выполнения. Учитывая, что iPhone 6s Plus имел всего 2 ГБ физической памяти, это могло привести к проблемам, включая риск завершения работы операционной системы приложения.

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

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

На ранних этапах разработки команда использовала одну группу Addressable и настраивала ее на отдельную упаковку. Это означало, что каждый актив в группе имел свой собственный отдельный AssetBundle. Хотя это было полезно в определенных случаях, такой детализированный подход также привел к большому количеству дублированных активов. Обеспечение того, чтобы все активы были Addressable и наличие структурированного подхода к Addressable Groups сократило размер сборки на iOS с 4 ГБ до 2 ГБ.

Снижение памяти для вариантов шейдеров

Варианты шейдеров были важной областью внимания команды на протяжении всей разработки игры, при этом память шейдеров во время выполнения увеличивалась до более чем 1 ГБ. Количество вариантов также увеличивало время сборки. Они решали проблему с помощью различных методов – в основном, удаления шейдеров с помощью IPreprocessShaders, предварительной фильтрации Unity, динамической загрузки шейдеров Unity и уменьшения ветвления шейдеров.

«Мы использовали нашу собственную реализацию удаления IPreprocessShaders, которая глобально удаляла ключевые слова шейдеров из всех шейдеров и локальный подход через Shader Control из Unity Asset Store», - говорит Хатчисон. «Более целенаправленное использование ключевых слов в шейдерах также было большим достижением.»

Их шейдеры использовали Shader Graph, который по своей сути включает ключевые слова, предопределенные Unity, и добавление дополнительных ключевых слов к ним имело экспоненциальный эффект. Замена некоторой логики на динамические ветви или полное удаление ключевых слов значительно сократила общее количество вариантов.

«С учетом всех этих методов мы снизили память для вариантов шейдеров во время выполнения до среднего значения 100 МБ или меньше», - говорит Хатчисон. «Мы также использовали Project Auditor от Unity, который предоставляет глобальный обзор всех активов и настроек в сборке. Используя это в сочетании с Memory Profiler, мы выявили текстуры и модели, которые выиграли от улучшенных пресетов импорта. Это еще больше снизило нагрузку на память от художественных и аудио активов.»

Отмечая победы и смотря в будущее

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

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

Sonic Dream Team доказывает, что старого ёжика все еще можно научить новым трюкам. И, как и Соник, Hardlight и Unity имеют сильный послужной список и светлое будущее.

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

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