Как Wishfully выпустила Planet of Lana II одновременно на всех платформах

Планета Лана II - это кинематографическое приключение-головоломка, разработанное шведской инди-студией Wishfully, основанной в 2018 году в Гётеборге. Обеспечение такого опыта на ПК, Xbox, PlayStation®, и Nintendo Switchᵀᴹ, включая следующее поколение оборудования, представляет собой значительную техническую проблему.

Мы поговорили с соруководителем студии и креативным директором Адамом Стьернлюсом, старшим программистом Эдвардом Рутстрёмом и ведущим программистом Маттиасом Варгреном, чтобы узнать, как они объединили свою базу кода, масштабировали свою сборку и оптимизировали игру для достижения 60 кадров в секунду на большинстве платформ, одновременно выпуская её на ПК и консолях.

*Nintendo Switch является товарным знаком Nintendo.

Не могли бы вы поделиться обзором Планеты Лана II и ее масштабом как многоплатформенного проекта?

Адам Стьернльюс: Планета Лана II расширяет оригинальную игру, увеличивая контент примерно вдвое и расширяя её масштабы. В отличие от первой игры, которая вышла на Xbox и PC, прежде чем мы перенесли ее на другие платформы, мы разработали сиквел для одновременного многоплатформенного релиза на PC, Xbox One и Xbox Series X|S, PlayStation 4 и PlayStation 5, а также на системах Nintendo Switch. Мы выпустили ее 5 марта 2026 года.

Это по-прежнему игра в жанрах головоломка и приключение, в которой Лана и её спутник Муи отправляются в сюжетное путешествие, сочетающее в себе головоломки, платформер и стелс. Основное внимание в геймплее уделяется взаимодействию между Ланой и Муи, а сюжет расширяет мир и конфликт из первой игры.

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

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

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

Как ваша техническая архитектура поддерживала эффективные кроссплатформенные сборки и развертывание без создания изолированных участков кода для каждой платформы?

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

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

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

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

Эдвард Рутстрём: Мы с самого начала уделили приоритетное внимание системе сборки, начав с локальной настройки с использованием TeamCity и выделенных агентов сборки, чтобы не загружать машины разработчиков и избежать конфликтов. На поздних этапах проекта мы перешли на инфраструктуру, размещенную у издателя, с большим количеством агентов сборки, что позволило автоматизировать ночные сборки на всех платформах и сократить узкие места.

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

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

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

MW: Мы достигли стабильности, объединив общие уровни качества с мощными инструментами проверки. Мы реализовали режимы качества, учитывающие платформу, которые мы могли моделировать непосредственно в редакторе Unity, что позволило дизайнерам и художникам предварительно просмотреть, как контент будет вести себя на разном оборудовании, не разветвляя проект.

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

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

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

Вместо этого мы использовали более контролируемый конвейер активов. Мы обрабатывали аудио с помощью изолированных банков в FMOD и визуальные элементы с помощью Sprite Atlases. Чтобы оптимизировать работу на разных уровнях оборудования, мы сосредоточились на удалении активов и ограничении размеров атласов, что позволило сократить использование памяти без дополнительного дублирования.

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

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

ER: Мы использовали систему задач C# и компилятор Burst в нескольких целевых системах, в первую очередь в системе моделирования элементов, которая обрабатывала огонь, тепло и воду, а также в системе деформации снега.

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

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

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

ER: Мы начали с базового прохода с низкими требованиями к спецификациям и устранения узких мест в работе ЦП, а иногда и узких мест в работе GPU, с оптимизациями, которые сохраняли визуальное качество. Эта работа продолжалась и помогла нам достичь 60 кадров в секунду на большинстве целевых платформ. Мы также активно использовали профилирование памяти для управления загрузкой активов и объемом памяти.

AS: Это была непрерывная петля. Мы проводили профилирование, выявляли проблемы, такие как вызовы отрисовки и снижение частоты кадров, оптимизировали и повторяли процесс. Со временем это вылилось в рабочий процесс, в котором дизайнеры раньше понимали ограничения производительности, что сократило количество переделок на поздних этапах.

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

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

Оглядываясь назад, что бы вы сделали по-другому и какой совет вы бы дали командам, пытающимся одновременно запустить несколько платформ?

ER: Одно из изменений, которое мы бы внесли, — это автоматизация создания патчей в сборке. Ручной процесс был трудоемким и не масштабировался.

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

Чтобы узнать больше о проектах, созданных с помощью Unity, посетите сайт Страница ресурсов.