Сетевое взаимодействие в режиме разделенного экрана и GameShare в Survival Kids

Этим летом Unity выпустила свою первую игру, созданную в тесном сотрудничестве с издателем KONAMI. Survival Kids — это увлекательное обновление классической детской игры, которая вышла в день запуска Nintendo Switch™ 2.

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

Посмотрите первую часть истории многопользовательской сети для Survival Kids, где мы делимся тем, как основы сетевой архитектуры игры соединились. Этот пост расширяет эту базу, чтобы показать, как команда построила разделенный экран и возможности GameShare для Nintendo Switch 2.

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

После того как мы решили множество проблем в сетевой архитектуре игры, мы начали думать о том, как мы собираемся сделать разделенный экран, который не предоставляется из коробки в Netcode for Entities. Это была другая задача. С разделенным экраном должно быть больше одного игрока, но эти игроки принадлежат клиенту.

Netcode for Entities предполагает, что на одного клиента приходится один игрок — если есть отдельная игра с отдельной консолью, подключенной к ней, то у нее один игрок. Когда это меняется и на самом деле есть два или три игрока, нет способа отправить ввод для каждого отдельного игрока. Их нужно отправлять как одно целое.

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

В игре игроки не управляют своим вводом. Воображаемый виртуальный игрок ввода говорит им, какой ввод для кадра. Ранее Netcode for Entities предполагал, что игрок отвечает за получение своего ввода и использование его для всех своих движений, но здесь есть другой игрок, который не делает никаких движений, но удерживает все вводы для всего остального.

Разделенный экран был главной проблемой с точки зрения сети. Чтобы избежать проблемы с несколькими камерами, мы начали с того, что второй игрок бегал вокруг, пока камера оставалась с первым игроком. Это быстро соединилось, но затем мы столкнулись с другими проблемами, такими как как настроить вторую камеру? Как удерживать одну камеру слева от экрана, а другую справа от экрана? Нам также пришлось решить проблемы с пользовательским интерфейсом, потому что есть довольно много интерфейса, который может видеть только один игрок. Например, если один игрок стоит перед бревном, он увидит небольшую кнопку подсказки, которая говорит: "Эй, нажми X, чтобы поднять это бревно", но, конечно, вы не хотите, чтобы другой игрок это видел.

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

Одной из функций во время разработки для Nintendo Switch 2 является GameShare. Вы фактически отправляете видеопоток на другую консоль – на самом деле, это просто разделенный экран с точки зрения сети – за исключением того, что система отправляет одну камеру на другую консоль вместо рендеринга ее на экране.

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

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

Одной из действительно полезных функций, которую мы добавили, была команда отладки. У нас есть меню разработчика, так что вы можете нажать кнопку, вызвать меню и затем ввести команды в него. Это было удобно, потому что позволяло нам запускать множество отладочных вещей – все это было исключено из финальной игры, так что, конечно, никто не мог сделать это в финальной игре, которую люди покупают и играют. Но один из режимов, который у нас был в сплит-скрине, заключался в том, что вы могли дублировать основного игрока – это позволяло вам иметь сплит-скрин, где один контроллер управляет обоими игроками. Это был отличный способ протестировать сплит-скрин, не нуждаясь в множестве контроллеров, и это облегчало тестирование.

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

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

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

Netcode for Entities также имеет инструменты игрового режима для симуляции плохих сетевых соединений. Вы можете указать и смоделировать определенный уровень пинга – скажем, 300 миллисекунд пинга, действительно ужасный круговой путь, чтобы смоделировать, каково это играть с другом, который подключил свой телефон к ноутбуку в аэропорту и подключился к игре таким образом. Затем вы можете протестировать это в редакторе, чтобы узнать, насколько это задержка или нестабильно. Иногда это не работает на сетевом соединении, которое теряет данные и теряет пакеты, и мы могли легко смоделировать это.

Это тестирование происходило все время. В течение некоторого времени у нас было правило, что никто не мог играть в редакторе с отключенным симулятором – все должны были играть с какой-то симулированной задержкой, так как ни один из наших игроков не собирался играть на идеальном соединении. Таким образом, мы никогда не могли обмануть себя, веря, что супербыстрый офисный широкополосный интернет является репрезентативным.

В конце концов, все эти тесты оправдали себя – мы смогли предоставить плавную, производительную игру на 60 fps в различных сетях и многопользовательских настройках. С момента выхода игры несколько недель назад мы видели, как игроки продолжают взаимодействовать онлайн через Лобби и Реле, надеясь на бесшовный и надежный игровой опыт, независимо от условий их домашней сети.

Посмотрите другие выпуски нашей серии блогов, углубляющихся в Survival Kids производство:
- "Советы по графике и рендерингу от Survival Kids"
- "Макет уровней и рабочие процессы местности в Survival Kids"
- "Внутри многопользовательской сетевой инфраструктуры Survival Kids"

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