Создание Вестероса для мобильных устройств в игре «Игра престолов»: Драконий огонь
Для Warner Bros. Компании Games Boston для того, чтобы перенести мир Вестероса на мобильные устройства, потребовалось нечто большее, чем просто адаптация популярной франшизы. На основе сериала «Дом дракона» сериал «Игра престолов»: Dragonfire сочетает в себе масштабную Multiplayer-стратегию и сражения с драконами в бесплатной игре, разработанной специально для современных мобильных устройств.
Игроки берут на себя роль потомка валирийцев, которому предстоит выводить из яиц, выращивать и командовать драконами, соревнуясь с тысячами других игроков за власть над Железным Троном. Чтобы воплотить эту идею в жизнь, потребовалось обеспечить баланс между высококачественной графикой, масштабируемой производительностью и системами Multiplayer в реальном времени на широком спектре устройств.
Мы поговорили с техническим директором Ара Йессаяном и старшим техническим художником Тайей Ли о создании драконов для мобильных устройств, обеспечении игрового процесса в масштабных стратегиях и использовании Unity для воплощения мира Вестероса в жизнь.
Каковы были ваши основные цели и ограничения при разработке первого игрового сеанса?
Ара Ессаян: В первом сеансе нам важно удержать внимание игрока и избежать любых заминок, которые могут нарушить его погружение в игру. Важно постепенно знакомить зрителей с основами нашей игры и с историей, которую мы хотим рассказать в мире «Дома дракона».
Какие стратегии вы использовали для сокращения времени загрузки как для новых, так и для постоянных игроков, и чем отличаются эти подходы?
AY: При новой установке главное — свести к минимуму объем данных, требуемых на начальном этапе. Мы изучили методы, позволяющие сократить объем данных, которые необходимо загрузить или занести в память перед тем, как перенести игроков к началу нашего игрового опыта, а также рассмотрели возможность использования переходов для маскировки части этих загрузок. Чтобы восстановить данные о вашем персонаже и разместить вас в нужном месте на карте, нам потребуется больше информации. Хотя исходная задача схожа (свести к минимуму время ожидания данных), эти методы в большей степени сосредоточены на затратах на десериализацию и стратегических подходах, позволяющих сократить объем данных, запрашиваемых на начальном этапе.
Как вы выявили основные узкие места, связанные со временем загрузки, в процессе разработки?
AY: Чтобы сократить время загрузки, мы применили несколько подходов. Чтобы получить общее представление о том, где именно возникали узкие места, мы настроили пользовательские события профилирования для каждого этапа процесса загрузки, результаты которых записывались в файл CSV. Мы обобщили данные по нескольким сеансам, чтобы определить, какие этапы являются наиболее проблемными. Кроме того, мы преобразовали их в события Chrome Trace и трассировки OpenTelemetry, чтобы лучше визуализировать, как эти этапы загружаются параллельно.
Затем мы углубились в изучение конкретного этапа. Модуль CPU в Unity Profiler позволил нам глубже проанализировать неэффективный код, который мы смогли оптимизировать. В некоторых случаях запись нескольких профилей и использование инструмента Unity Profile Analyzer помогли нам оценить, как настройка определенных параметров загрузки улучшала (или ухудшала) время загрузки.
Профилировщик ЦП регулярно приходил на помощь при анализе кадров с сильными задержками, позволяя выяснить причины падений частоты кадров и помогая нам находить более эффективные методы.
Помимо оптимизации загрузки, модуль Rendering помог нам выявить неэффективность в процессе рендеринга во время работы игры, а RenderDoc стал еще одним инструментом, который мы использовали для более глубокого анализа проблем, возникающих во время выполнения.
Наконец, чтобы сеансы продолжали работать, нам нужно было следить за тем, чтобы объем используемой памяти не выходил за пределы допустимого. С помощью снимков Memory Profiler мы выявили ненужную загрузку ресурсов и объектов, в частности связанную с картой и маршами, что, в свою очередь, позволило снизить системные требования для запуска игры.
Как вы использовали Memory Profiler в Unity для анализа использования памяти наборами ресурсов, в том числе для выявления дубликатов и проверки выгрузки ресурсов? Не могли бы вы привести конкретный пример?
Тайя Ли: Обычно мы используем Memory Profiler для выявления случаев, когда ресурсы загружаются в неожиданных местах игры и остаются в памяти. Например, такая ситуация может возникнуть, когда текстура используется в нескольких местах, но находится в одном пакете, в результате чего загружается весь пакет, хотя требуется только эта одна текстура.
Это ещё одна причина, по которой мы стремимся создавать специальные общие пакеты, чтобы предотвратить подобную ситуацию. Этот инструмент также помогает выявить приложения, наиболее интенсивно использующие память, особенно те, о которых мы, возможно, не подозревали или которые занимают больше памяти, чем ожидалось.
Какие самые неожиданные проблемы с производительностью вам пришлось столкнуться на ранних этапах, в частности в плане доставки контента и производительности игрового процесса?
AY: Одним из неожиданных моментов стало то, сколько памяти потребовалось для загрузки данных файла карты, определяющих её структуру. В сериале «Игра престолов»: В игре «Dragonfire» игроки используют свои армии и драконов, чтобы захватывать территории (клетки) на карте. Они помогают игроку добывать ресурсы и ограничивают возможности размещения его армий, поскольку требуют, чтобы он сам или другой член его фракции владел соседней клеткой.
Мы знали, что для загрузки контента нам нужно разбить данные карты на фрагменты. Эти данные были необходимы игре для того, чтобы определить, что находится в каждой точке координат, особенно с учётом дополнительных данных, которые нам нужно было сохранять для узлов, охватывающих несколько клеток. Загрузка всех структур, связанных с картой размером 2000×4000, потребовала столько памяти, что привела к сбою некоторых устройств.
По мере того как мы внедряли усовершенствования и оптимизации, позволяющие загружать только нужные участки карты вместо всей карты целиком, эта работа позволила значительно сократить время загрузки для наших постоянных игроков.
Еще один метод, который мы использовали для дальнейшей оптимизации карты, заключался в замене объектов GameObject, отображавших рельеф на карте, на прямую визуализацию сетки. Это позволило нам избежать затрат памяти, связанных с созданием экземпляров этих GameObjects. В сочетании со стратегической загрузкой только тех мешей и моделей, которые необходимы для ближайшего окружения, это позволило повысить производительность как при входе на карту, так и при прокрутке.
Как вы определяете, какой контент должен быть доступен при запуске, а какой можно будет загрузить или просмотреть позже?
AY: Первый шаг — определить, что необходимо для обеспечения удобства первых шагов пользователя (FTUE), прежде чем игроки перейдут к Multiplayer-режиму нашей игры. Это дает нам возможность загружать любые данные, которые игроки используют при входе в полную версию игры.
Существуют и другие типы контента, связанные с текущими операциями или функциями на поздних этапах разработки, которые также можно загрузить на более поздних этапах процесса. Мы хотим, чтобы игроки могли наслаждаться игрой с самого момента знакомства с той или иной системой.
При последующей загрузке необходимо соблюдать тонкий баланс между загрузкой элементов на начальном этапе (что может увеличить время загрузки) и тем, что мы загружаем асинхронно (что может привести к появлению индикатора загрузки перед переходом на экран или в область). Мы продолжаем работать над этим направлением, чтобы обеспечить пользователям максимально удобный интерфейс.
Как вы организовали и автоматизировали процесс подготовки наборов ресурсов, чтобы обеспечить оптимальный баланс между размером загружаемого файла, объемом занимаемой памяти и гибкостью при выполнении?
ПЕРЕВОД: Как правило, мы стремимся, чтобы размер наших наборов ресурсов не превышал 8 МБ, за некоторыми исключениями, обусловленными конкретными сценариями использования и набором необходимых ресурсов. Это побудило нас организовать пакеты таким образом, чтобы ресурсы, которые обычно используются вместе во время выполнения, были доступны одновременно.
С другой стороны, мы избегаем чрезмерно больших пакетов, в которых используется лишь часть активов. У нас есть наборы, сгруппированные по областям игры, функциям или типам общих ресурсов. Например, на нашей карте представлены различные биомы, и для каждого из них предусмотрены отдельные ресурсы, соответствующие конкретной локации.
Не нужно объединять в один набор северные заснеженные горы и южные пустынные горы. Однако некоторые сетки и текстуры используются в нескольких биомах, поэтому эти ресурсы помещаются в общий пакет.
Это баланс, который требует понимания того, где в игре используются ресурсы, чтобы обеспечить оптимальную производительность. Как и в случае с любой онлайн-игрой, это непрерывный процесс, который нам необходимо анализировать и корректировать по мере добавления новых функций.
AY: До появления Addressables мы самостоятельно разработали набор инструментов, которые помогали нам решать многие из тех задач, с которыми сейчас справляется Addressables. Некоторые из этих внутренних инструментов позволяют нам отслеживать состав наших пакетов и использовать передовые методы загрузки патчей для их обновления (мы называем это «бинарным патчением»).
С какими компромиссами или трудностями вы сталкивались при работе с наборами ресурсов и как вы их преодолевали?
ПЕРЕВОД: Самая большая проблема, с которой мы сталкиваемся, заключается в том, что размеры наборов ресурсов могут резко увеличиваться, если кто-то редактирует существующий префаб или добавляет много новых ресурсов, не осознавая, как это может повлиять на размер и структуру наборов.
У нас были случаи, когда размер пакетов увеличивался сразу более чем на 5 МБ, причем пользователи об этом даже не подозревали, а в худшем случае это приводило к тому, что размер нашего файла .aab превышал установленный лимит для подачи в магазин. С тех пор мы добавили в наш конвейер сборки оповещения, позволяющие выявлять такие случаи, и помогли разработчикам лучше понимать, в каких случаях их изменения могут привести к неожиданному увеличению размера пакетов.
Как вы решаете проблему зависимостей между ресурсами, чтобы избежать излишних загрузок и ненужного использования памяти?
ПЕРЕВОД: В нашей внутренней системе управления наборами ресурсов мы можем обнаружить дубликаты ресурсов в разных наборах. В целом мы не хотим, чтобы было много дублирующихся ресурсов, особенно крупных, поэтому мы добавляем такие ресурсы непосредственно в пакет, а не позволяем им подключаться в качестве зависимостей из нескольких пакетов. Нам нужно убедиться, что он добавлен в пакет, который можно использовать в разных местах, но обычно мы создаем отдельный общий пакет.
Какие методы вы использовали для снижения пиковых нагрузок на процессор или задержек, вызванных десериализацией ресурсов при запуске приложения?
AY: Один из методов, которые мы применяем при работе с данными проектирования, заключается в использовании для хранения формата Protocol Buffers (Protobuf) вместо стандартного JSON. Protobuf (бинарный формат, используемый в gRPC) обеспечивает более компактное хранение данных и более быструю десериализацию.
Используя соответствующий файл структурированной схемы, мы можем загружать данные в память гораздо быстрее, не анализируя содержимое строк JSON и не разбивая их структуру на токены. Мы рассмотрели и другие варианты, такие как BSON и Odin Serializer, для более эффективного хранения и десериализации данных, но возможность использовать gRPC для более эффективного взаимодействия с нашими серверами сделала его для нас оптимальным выбором.
Кроме того, чрезвычайно важно эффективное управление потоками. Определите, какие операции можно перенести из основного потока Unity, чтобы сосредоточиться на загрузке ресурсов и сцен именно там, где это можно сделать.
Как оптимизировать размер сборки и конвейеры развертывания, чтобы обеспечить более быстрое установление исправлений и обновление контента?
AY: Мы используем несколько методов. Прежде всего, мы стремимся найти оптимальный баланс между необходимыми ресурсами, встроенными в бинарный файл игры, и теми, которые можно будет загрузить позже. В нашей игре есть учебное руководство, прохождение которого занимает всего несколько минут; это позволяет нам загружать дополнительные ресурсы по мере необходимости, не отрывая игроков от процесса при первом входе в игру.
Использование функции Play Asset Delivery в Android также помогло нам с самого начала получить доступ к большему количеству ресурсов. Мы начали включать в игровой клиент отдельные таблицы динамических данных, предполагая, что часть из них будет устаревшей. Загружая только те таблицы, в которых произошли изменения, мы сократили время загрузки.
Затем мы применили нашу технологию исправления бинарных файлов, что позволило нам загружать более компактные бинарные диффы и исправлять измененные файлы, а не скачивать сразу новую версию. Мы можем использовать этот подход и с наборами ресурсов, обновляя игровой контент по мере необходимости для новых событий в режиме реального времени.
Если оглянуться назад, какое изменение, внесенное вами, оказало наибольшее влияние на сокращение времени загрузки для игроков?
AY: Простой ответ заключается в том, чтобы игроки загружали только то, что им нужно. Еще до предварительного запуска мы определили, что карта является одним из основных факторов, замедляющих загрузку. В то время игра загружала все ресурсы карты сразу, до того как мы приступили к оптимизации, направленной на отображение только тех областей, которые окружают базу игрока.
Определив, что нам необходимо, и внедрив механизмы асинхронной загрузки остального контента, мы сократили время загрузки даже на самых мощных устройствах на несколько секунд. Наша команда выполнила поставленную задачу по сокращению времени загрузки для игроков и заложила основу для улучшения пользовательского опыта, и я не могу не выразить им огромную благодарность за их усердную работу.
Чтобы узнать больше о проектах, Made with Unity, посетите страницу «Ресурсы».