Внутри многопользовательской сетевой инфраструктуры Survival Kids

Этим летом, Survival Kids был запущен в день релиза для Nintendo Switch™ 2. Игра была полностью создана на Unity 6, что стало первым проектом полного цикла для Unity, в котором мы тесно сотрудничали с партнером-издателем KONAMI.

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

Это первый выпуск продолжающейся серии за кулисами, исследующей уроки команды, полученные в процессе работы над Survival Kids.

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

Survival Kids была создана очень небольшой командой внутри Unity. Основная группа состояла из около 10 разработчиков различных специальностей (художников, инженеров и дизайнеров). На пике мы были около 20, так как к нам присоединились люди из других команд Unity. Например, Стивен, наш инженер по рендерингу, много работал с нами, но он не всегда был на проекте.

Как небольшая команда, у нас были некоторые преимущества, однако. Инженеры были очень опытными — большинство из нас пишут игры уже около 20 лет, в основном в AAA-сегменте, так что мы усвоили много уроков и сделали много ошибок. И, конечно, мы действительно опытны в Unity, потому что большинство из нас здесь уже некоторое время.

Некоторые из нас также работали над проектами клиентов в рамках команд поддержки Unity, таких как Профессиональные услуги/Accelerate Solutions, теперь Unity Studio Productions. Мы консультируем клиентов о том, как оптимизировать их проекты и даже встраиваемся в проектные команды, чтобы работать вместе с ними и помогать решать их сложные технические проблемы, так что мы довольно хорошо осведомлены о тех ошибках, которые студии часто совершают, и о том, как их исправить. Работая над Survival Kids, мы могли спроектировать проект и направить его на правильный путь с самого начала, потому что знали, где будут все подводные камни, и это сэкономило нам много времени и ресурсов.

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

Дети выживания можно играть несколькими способами: в одиночку, в локальном кооперативе и онлайн с друзьями. На Nintendo Switch™ 2игроки также могут использовать GameShare, чтобы транслировать видео на другой Nintendo Switch 2 или даже на оригинальный Switch, а затем играть в многопользовательском режиме с кем-то на телевизоре или устройстве, что действительно круто.

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

Для этого мы решили использовать Netcode for Entities. Как только мы представили концепцию для Дети выживания KONAMI, мы сразу же перешли к прототипированию, чтобы найти интерес для нашей многопользовательской игры. Мы использовали существующий проект в качестве отправной точки, тот, который я ранее написал как доказательство концепции того, как мы могли использовать Netcode for Entities в качестве сетевого бэкенда, а затем написать слой GameObject поверх него, чтобы воспользоваться преимуществами Prefabs и анимаций. Не все в команде имели опыт работы с Entities, поэтому мы решили использовать GameObjects и MonoBehaviour вместе.

Мы также хотели сохранить игровую логику в GameObjects и MonoBehaviours, потому что они действительно упрощают прототипирование – эта настройка позволяет вам быстро собирать вещи и писать скрипты, загружать скрипты из интернета или использовать пакеты Asset Store для прототипирования. Мы хотели быструю итерацию и свободу, но нам также нравилось, что Netcode for Entities предоставлял нам производительный сетевой слой. Я уже использовал его в нескольких клиентских проектах и личных исследовательских проектах, поэтому я знал, что его уровень качества может обеспечить тот уровень игрового процесса, который мы хотели.

Когда мы только начали, около трех лет назад, Netcode for GameObjectsсуществовал, но ему все еще не хватало некоторых функций, которые мы хотели, особенно предсказания на стороне клиента. С предсказанием на стороне клиента, если когда-либо возникает задержка между сервером и клиентом, клиент предсказывает, что сервер собирается сделать, и делает это мгновенно – так что управление игроками ощущается отзывчивым, даже когда есть задержка. Вам не нужно ждать, пока сервер скажет вам, что игрок переместился или что-то в этом роде – вы уже это делаете. Это то, что Netcode for Entities имел с самого начала.

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

Мы задали себе вопрос: Что людям нравится в создании и сборе ресурсов? Что их не интересует? Это помогло нам определить, как игроки получают ресурсы, как они перемещают их из одного места в другое, как они занимаются созданием. Мы разобрались с этим, быстро прототипируя и итеративно используя GameObjects и MonoBehaviours.

Поскольку мы начали с этого небольшого демонстрационного прототипа, мы могли подключаться по интернет-адресу с самого начала. Можно было подключиться, используя IP-адрес компьютера, но мы также использовали сервис Unity Relay, который позволяет вам хостить игру на сервере Relay в облаке. С помощью Relay любой может присоединиться к этой игре, используя код для присоединения, и люди могут подключаться из дома или офиса без VPN или известного IP. Это означало, что мы могли войти в ритм еженедельных тестов игры – и мы проводили их на работе и в наших домашних сетях, что позволило нам протестировать нашу сетевую архитектуру вместе с игровым процессом при всех возможных скоростях соединения. В конце концов, мы оставили Relay в производстве.

Мы старались оставаться как можно ближе к публично выпущенным пакетам. Если мы находили ошибку в одном из пакетов, мы бы идентифицировали ее, забрали пакет локально и пытались бы исправить. Иногда мы заходили в Slack после и отправляли сообщение команде Netcode Unity, чтобы объяснить проблему и наше исправление, чтобы они могли это взять и сделать PR – и иногда включить это в финальную версию. Мы не были непосредственно вовлечены в исправление, но, работая в производственной среде, мы нашли некоторые проблемы, которые они еще не обнаружили (хотя иногда у них уже было лучшее исправление, чем то, что мы придумали, или они говорили нам, что мы используем это неправильно).

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

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

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

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

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

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

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