Сетевая игра-кооператив по физике: LEGO® Voyagers

Основанная в 2020 году, Light Brick Studio — это независимая команда, ориентированная на мастерство и понимание игроков. Их последний релиз, LEGO Voyagers, — это кооперативное приключение о двух друзьях, преследующих свою мечту стать космонавтами. Он был запущен 15 сентября 2025 года на нескольких платформах. Опыт основан на звуке и взаимодействии, а не на диалогах, что позволяет игрокам прочувствовать историю через игру.

Функция онлайн-кооператива была добавлена на поздней стадии разработки, что создало уникальные проблемы для команды. Мы поговорили с Каспером Хонненсом де Лихтенбергом, ведущим программистом LEGO Voyagers, и Даниэлем Застроу, программистом, о модернизации онлайн-кооператива в проекте с интенсивным использованием физики.

Какова была основная цель при разработке LEGO Voyagers?

Каспер Хонненс де Лихтенберг (KHdL): Мы поставили перед собой цель создать увлекательную игру, которая вызывает эмоции и способствует укреплению сотрудничества.

Дэниел Застроу (DZ): Наша цель заключалась в том, чтобы передать суть игры LEGO — весело провести время с другом, почувствовать себя как можно ближе к настоящему кубику LEGO и отправиться в приключение, где вы вместе переживаете историю.

Какие системы были наиболее сложными с технической точки зрения?

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

DZ: Самым сложным было подключение системы крепления к сети. Любой кирпичик можно соединять бесчисленным количеством способов, и два игрока могут взаимодействовать одновременно. Поскольку мы не создавали игру для онлайн-игры, я переписал большую часть логики, чтобы хост мог проверять действия, пока клиенты ждут. Я также сгладил переходы между кирпичами, чтобы скрыть задержку.

Как NVIDIA PhysX помогла синхронизировать несколько отдельных кубиков LEGO в сети?

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

Как Netcode for GameObjects и Relay оптимизировали ваш сетевой рабочий процесс?

KHdL: Netcode for GameObjects и Relay позволяет нам быстро запустить онлайн-кооператив, не создавая сетевую инфраструктуру с нуля. Поскольку онлайн-игра была добавлена на поздней стадии разработки, нам нужен был стабильный стек, который позволил бы нам сосредоточиться на игровом процессе. Возможность открыть и настроить пакет была крайне важна, особенно для ускорения автоматического преобразования сцен, когда рабочие процессы НПО предполагали ручные изменения. Эта гибкость помогла нам исправить ошибки и решить проблемы на поздних этапах разработки и, в конечном итоге, выпустить игру.

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

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

KHdL: Поскольку LEGO Voyagers в значительной степени зависит от физики, производительность напрямую влияла на стабильность сети. На Nintendo Switchᵀᴹ мы поставили цель достичь 30 FPS для физики, что означало тщательную оптимизацию всего вокруг: разрушающиеся модели, использование менее детализированных ресурсов и теней, а также упрощение более тяжелых функций, таких как вода. Освещение и разрушение моделей были автоматичными, но запускались вручную.

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

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

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

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

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

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

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

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

KHdL: Это баланс. Если бы мы начали этот разговор раньше, как команда, это сэкономило бы нам много боли.

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

DZ: Разделите выполнение и проверку. Позвольте клиентам выполнять действия, но сохраняйте проверку на хосте или сервере. Когда эти обязанности переплетаются, сетевая работа становится гораздо сложнее и приводит к созданию неустойчивого, чрезмерно сложного кода. Не навязывайте 100% детерминизм, если он вам не нужен. Стремитесь к согласованности, которая выглядит и ощущается правильно.

KHdL: Также важно разработать дизайн с учетом контекста вашей игры. LEGO Voyagers — это непринужденная кооперативная игра, которая позволяет нам быть гибкими. Идеальная синхронизация не всегда необходима.

Чтобы узнать больше о проектах, Made with Unity, посетите страницу «Ресурсы».

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