Автостопом по мультиплееру. Часть 4: Авторитарность и Топологии

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

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

Для кого и для чего
Синглплеер и Мультиплеер
Клиент и Сервер
-> Авторитарность и Топологии
• Авторитарность
• Топологии
--• Клиенты + Игровой Сервер
--• P2P
--• P2P: Shared Mode / Distributed Authority
--• P2P: Клиенты + Хост
--• Смешанная
• Проблемы NAT
• Relay-сервер
• Выбор топологии
• Рекомендации
• Заключение
• Дополнительный контент
...

Следить за выходом новых статей и другого контента можно в моём блоге на VK / Telegram / Dtf.

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

Обычно в мультиплеере понятие авторитарности применяют:

Для управления (Input Authority): определяет, какой из клиентов является достоверным источником ввода для конкретного игрового объекта.
Для данных (State Authority): определяет, какой узел имеет право изменять определённые игровые данные и может быть достоверным источником этих данных.
Для создания и удаления объектов: определяет, какой узел имеет право создавать или уничтожать те или иные сетевые объекты. Для общности, будем далее считать, что это частный случай State Authority.

Эти виды авторитарности тесно связаны друг с другом. Клиент, кому принадлежит Input Authority над своим персонажем, должен отправить команду узлу, у которого есть State Authority над данными этого персонажа, чтобы обновить его данные после ввода: изменить позицию, сделать выстрел и пр.

Клиент сам может иметь State Authority над своими данными, может иметь State Authority над данными другого клиента, может иметь State Authority над частью данных игрового мира или над всеми его данными. Клиент может иметь и Input Authority, и State Authority одновременно. Может и не иметь вообще никакого Authority.

При этом границы Authority конкретного клиента могут изменяться динамически. Например, какая-то механика (типа способности "Контроля" или обработка временного дисконнекта) может на время у клиента отбирать его Input Authority и передавать другому клиенту или игровому серверу. Аналогично со State Authority.

Как правило, все игровые клиенты большую часть времени имеют Input Authority, иначе бы игра для пользователей не имела смысла. Наличие State Authority у клиента, с одной стороны, позволяет ему быстро изменять подконтрольные данные и оперативно реагировать на эти изменения, но с другой – открывает возможность изменять их несанкционированно, не "по правилам", получая преимущество над другими игроками. Поэтому, если необходимо защитить игровой процесс от мошенничества, приходится прибегать к одному из следующих решений:

Взаимная валидация данных: клиенты должны подтверждать корректность операций с данными у других клиентов. Чем больше клиентов сможет подтвердить корректность, тем надёжнее. Потому что действия читера может подтвердить и другой читер. А если в игре все читеры, то они в равных условиях – пусть развлекаются. Но такие проверки сильно усложняют общую систему и вносят дополнительные издержки в процесс синхронизации.
Передача State Authority доверенному узлу: клиенты сами с данными ничего не делают, а только отправляют команды выделенному доверенному неангажированному узлу (таким обычно и является игровой сервер), который по полученным командам производит корректные операции над данными, а затем отсылает клиентам обновлённые значения. Это может касаться как всех данных, так и только наиболее чувствительных.

То, как в проекте распределяется Authority между участниками, определяет вид топологии, на котором построено мультиплеерное взаимодействие. Обычно выделяют две группы:

Клиенты с выделенным игровым сервером.
Клиенты без выделенного игрового сервера (P2P / Peer-to-Peer).

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

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

По умолчанию клиенты имеют Input Authority, а сервер — глобальный State Authority. Для разного рода оптимизаций часть State Authority может быть передана и клиентам. Обычно это Authority над данными подконтрольного персонажа. Но Authority за спаун и деспаун объектов, как правило, принадлежит серверу.

🔗 Процесс подключения:

Подключение зачастую происходит через сервис матчмейкинга (см. следующую часть) и мастер-сервер (см. предыдущую часть). Подробнее разберём это позже, а пока для общности скроем эти детали за понятием Infrastructure.

Клиент отправляет запрос на получение игровой сессии. В запросе оставляет свои данные (рейтинг, уровень и пр.) и настройки сессии (режим игры, локация, сложность и пр.).
Инфраструктурная часть получает запрос и в течение некоторого времени ожидает запросы от других игроков.
Полученные запросы от игроков распределяются по сессиям в зависимости от данных игроков, их количества и настроек.
Проверяется наличие запущенных ожидающих игровых серверов, которые удовлетворяют параметрам.
Если среди доступных серверов каких-то не достаёт, то запускаются новые (здесь клиентам придётся подождать подольше, пока новый сервер подготовится).
Клиентам высылается адрес для дальнейшего подключения к целевому игровому серверу (или сообщение, что подключиться некуда).

Что происходит между сервером и клиентом, было рассмотрено в предыдущей части, поэтому в этой только кратко напомню.

💡 Особенности Сервера:

Не рендерит игру;
Управляет логикой;
Контролирует игровой мир;
Обрабатывает данные от клиентов;
Синхронизирует данные между клиентами;
Хранит данные об игровом процессе;
Обеспечивает честную игру.

💡 Особенности Клиента:

Рендерит игровой процесс;
Получает ввод от пользователя;
Отправляет данные о действиях игрока серверу;
Получает актуальные изменения данных от сервера.

💡 Особенности топологии:

Универсальность: эту топологию можно успешно использовать для любых многопользовательских игр (но это не всегда оправданно).
Централизованность логики и данных: все (обычно) данные хранятся и управляются на игровом сервере. У всех клиентов единый (обычно) и достоверный источник для синхронизации.
Поддержка большого количества игроков в сессии: полноценные MMO и Battle Royale на других топологиях реализовать не получится.
Безальтернативный вариант для быстрых PvP-игр: обеспечивает равные условия, честный геймплей и минимальные задержки.
Взаимодействие с другими узлами: т.к. сервер изолирован и не ангажирован, то он может обращаться к другим серверам (например, к профиль-серверу) с повышенными правами доступа, которые не может иметь обычный клиент (например, у клиента не может быть прав для обновления данных другого пользователя, но сервер такие права иметь может).

🟢 Достоинства топологии:

Масштабируемость: кол-во серверов можно динамически менять в зависимости от потребности в кол-ве сессий.
Адаптивность: мощность серверов можно корректировать в зависимости от нагрузки.
Минимизация задержек:
- Сервер обычно размещается в дата-центре с высокой пропускной способностью;
- Широкая сеть серверов может позволить игрокам подключаться к самым близким серверам;
- Такая топология позволяет использовать разнообразные технологии компенсации задержек.

Защищенность от мошенничества:
- Данные хранятся, обрабатываются, проверяются и управляются преимущественно сервером, к которому нет прямого доступа у клиентов, что снижает риск читерства и повышает безопасность;
- Данный вид топологии предоставляет широкий набор техник защиты от мошенничества.
Надёжность: сервер не зависит от клиентов и изолирован от них, поэтому сервер будет одинаково доступен для всех игроков, независимо от состояния подключения отдельных клиентов.

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

🔴 Недостатки топологии:

Инфраструктурные вопросы:

Экспертиза: для построения инфраструктуры или даже для настройки готовой, особенно эффективной и масштабируемой, требуется экспертиза в backend и devops.
Финансовые затраты:
- Аренда оборудования или его покупка с содержанием и последующим обновлением;
- ПО, электроэнергия, администрирование и пр.;
- Альтернатива: использование сервисов с услугами по предоставлению готовой настроенной инфраструктуры.
Поддержка: инфраструктура — это в т.ч. и код, который нужно поддерживать, совершенствовать и чинить.
Риски выхода из строя: игровой сервер запускается на железке, которая работает долго и на пределе возможностей, со временем постепенно деградирует и рискует "выгореть на работе". К этому нужно быть всегда готовым, иметь настроенные средства мониторинга и резервные узлы для оперативного перенаправления пользователей.
Кратное усложнение с увеличением сложности и масштабов проекта: без комментариев.

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

Такая модель может быть централизованной и децентрализованной, в зависимости от распределения State Authority между клиентами. У каждого вида есть свои отличительные особенности, достоинства и недостатки.

🔗 Процесс подключения:

Всё аналогично рассмотренному выше алгоритму, кроме того, что сессия ищется не среди игровых серверов, а среди клиентов, которые тоже ищут сессию или уже её запустили и имеют временное окно для подключения новых игроков.

💡 Особенности топологии:

Ограниченность: данный вид топологии подходит не для всех проектов.
Поддержка небольшого количества игроков в сессии: как правило, рекомендуют ограничиться на одну сессию ~10 игроками.

🟢 Достоинства топологии:

Инфраструктурные вопросы:
- Экономия: отсутствие необходимости арендовать и обслуживать игровые серверы.
- Упрощение: отсутствие игровых серверов значительно снижает сложность разработки и поддержки инфраструктуры.

🔴 Недостатки топологии:

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

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

⚠ Дисклеймер ⚠
С этой топологией у меня достаточно ограниченный опыт взаимодействия. Преимущественно только на уровне пет-проектов.

Это децентрализованная вариация P2P. В такой сети нет ведущего узла, ответственного за координацию всей системы, вместо этого клиенты взаимодействуют друг с другом "напрямую" (помним, что по факту это не совсем так).

Здесь State Authority полностью распределён между клиентами. Каждый клиент отвечает за данные своего персонажа и подконтрольных ему объектов. Но за данные игрового мира (мобы, время суток, случайные глобальные события и пр.) либо отвечает определённый мастер-клиент, либо ответственность так же распределена между клиентами (часть мобов — одному клиенту, часть — другому и т.д.).

Мастер-клиент — это некоторый переходящий "ярлык", дающий State Authority на данные игрового мира и/или право на координацию игроков в сессии. Он выдаётся одному из клиентов, обычно хозяину сессии (session owner), а затем передаётся другому, если хозяин сессии больше не может выполнять свои обязанности (например, отключился).

💡 Особенности топологии:

Ограниченность: хорошо подходит для игр с невысокими требованиями к задержкам:
- PvE;
- Мобильный гейминг.
- Детерминированные реализации могут ограниченно использоваться в PvP (например, в файтингах);
- Без детерминированности сложно компенсировать задержки и защищать от читерства.
Позиционирование клиентов: чем клиенты ближе друг к другу, тем лучше (при "чистом" P2P).

Равноправие узлов: каждый узел имеет одинаковый статус и может передавать и принимать данные от любого другого узла.
Распределение нагрузки: исполнение логики и соответствующая нагрузка распределены между всеми клиентами.
Защита от мошенничества:
- Игроки могут подтверждать действия друг друга;
- Кворум из честных игроков может выявить и подавить читера.

🟢 Достоинства топологии:

Более простая разработка:
- По сравнению с другими топологиями и без детерминированности;
- Возможно, с этого варианта будет проще начинать разработку своего первого мультиплеера.
Клиенты в равных условиях: никто не обладает никаким преимуществом.
Устойчивость: отсоединение одного из клиентов не фатально, игра на этом не закончится.

🔴 Недостатки топологии:

Проблемы NAT: актуально для всех клиентов.

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

Повышенная нагрузка:
- Серверную логику в отсутствии сервера необходимо выполнять клиентам;
- С увеличением количества клиентов нагрузка на каждого клиента возрастает.
Нестабильность:
- Все клиенты зависят друг от друга;
- Клиенты имеют нестабильное качество соединения (особенно в Mobile).
Риск мошенничества:
- Клиенты имеют доступ к игровым данным и имеют полномочия их изменять;
- Техники защиты от читерства для данной топологии менее эффективны.

Это централизованная вариация P2P топологии, где один из клиентов выступает одновременно как клиент и как игровой сервер, а остальные клиенты взаимодействуют с ним как с игровым сервером.

Такой клиент называется Хостом (Host).Обычно это тот, кто первым создал игровую сессию, или тот, у кого наилучшие условия для выполнения роли хоста (например, высокая пропускная способность).

State Authority в таком сценарии, по аналогии с игровым сервером, преимущественно принадлежит Хосту.

💡 Особенности топологии:

Ограниченность: не подходит для PvP, т.к. хост имеет преимущество.
Позиционирование клиентов: чем клиенты ближе к хосту, тем лучше (при "чистом" P2P).
Централизованность логики и данных: все (обычно) данные хранятся и управляются на хосте. У всех клиентов единый (обычно) и достоверный источник для синхронизации.

🟢 Достоинства топологии:

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

🔴 Недостатки топологии:

Проблемы NAT: актуально для хоста.

Незащищённость данных: хост имеет доступ ко всем данным и может их несанкционированно модифицировать (если имеет Authority над ними).
Преимущество хоста: т.к. хост является сервером, то у него "нулевой пинг" (т.е. нет задержки при общении с серверной логикой).
Повышенная нагрузка на хост:
- Хост вынужден просчитывать не только клиентскую, но и серверную логику, которая может быть тяжеловесной;
- С увеличением кол-ва игроков нагрузка на хост возрастает.
Зависимость только от хоста: качество игрового процесса и соединения безальтернативно зависят от хоста, который является обычным клиентом и может иметь плохую пропускную способность или слабое устройство.
Неустойчивость:
- Отключение хоста заканчивает игру для всех.Проблему решает миграция хоста (Host Migration), но не все фреймворки предоставляют такую возможность;
- Даже доступная из коробки миграция хоста требует значительных усилий для реализации;
- При отключении основного хоста может потеряться часть не засинхронизированных данных.

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

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

Грубо говоря, комбинируются достоинства двух подходов и их недостатки. И появляются новые. Например, такую систему весьма сложнее разработать и поддерживать.

NAT (Network Address Translation) — это технология преобразования сетевых адресов, которая позволяет нескольким устройствам внутри частной сети использовать один публичный IP-адрес для доступа к Интернету. Основная цель NAT — экономия IP-адресов и обеспечение безопасности внутренней сети.

🔎 Принцип работы NAT:

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

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

📝 Способы решения проблемы NAT:

Локальная сеть:
Очень эффективное и простое решение, но подойдёт разве что компьютерным клубам. Для массовой глобальной многопользовательской игры — не вариант.
VPN:
Организация локальной сети, только виртуально. По такому принципу работают программы по типу Hamachi. Уже позволяет не привязываться к конкретному месту, но требует от пользователя дополнительные сторонние настройки или установку дополнительного ПО. Не дружелюбно.
NAT Punch-through (обход NAT):
Два устройства пытаются установить прямое соединение, отправляя специальные пакеты через посреднический сервер (STUN-сервер). Если удается создать туннель через NAT, устройства начинают обмениваться информацией напрямую. Но это может и не удастся — никаких гарантий.
UPnP (Universal Plug and Play):
Протокол UPnP позволяет устройствам автоматически открывать порты на маршрутизаторе, облегчая установку прямого соединения. Работает не со всеми видами NAT и не всегда поддерживается оборудованием.
Relay-сервер:
Данные передаются через сервер-посредник (он же relay), который действует как мост между устройствами. Нужен дополнительный сервер, но это зато надёжно, универсально и скрыто от пользователя.

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

Relay-сервер — это сервер, через который проходят все данные между клиентами, если они не могут установить прямое соединение.

Т.е. в схеме P2P всё же появляется выделенный сервер. Но он не игровой, а оттого очень легковесный и неприхотливый в обслуживании. А сервисы, предоставляющие услуги Relay, обходятся намного дешевле сервисов, предоставляющих игровые сервера.

🟢 Достоинства:

Надёжность: даже если прямое соединение невозможно, клиенты всё равно могут общаться друг с другом через Relay.
Универсальность: подходит для любых типов NAT и брандмауэров.
Простота реализации: можно избежать сложных алгоритмов обхода NAT, сконцентрировавшись на разработке самой игры.
Незаметно для пользователя: не требует никакого участия или дополнительных действий.

🔴 Недостатки:

Финансовые затраты: расходы на аренду и поддержку сервера или сервиса для Relay.
Увеличение задержек: передача данных через посредника добавляет дополнительную задержку.

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

На сайте Photon можно найти квадрант топологий, где наиболее популярные жанры мультиплеерных игр распределены по наиболее подходящим решениям с обозначением очень верхнеуровневых pros & cons. Если опыта для самостоятельного выбора топологии не хватает, то эта схема поможет задать направление в нужную сторону.

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

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

И, исходя из своего опыта и опыта смежных команд, у меня есть несколько рекомендаций.

1. Синглплеер:

Не стоит никогда забывать о синглплеере, если жанр его допускает. Что бы ни говорило руководство, если для жанра синглплеер возможен – он рано или поздно появится. Делать из мультиплеера синглплеер так же сложно, как и из синглплеера мультиплеер. Так что лучше при разработке сразу закладывать работу в нескольких режимах.

2. Выделенный сервер и Хост:

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

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

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

3. Поддержка ботов:

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

Игрок долго ждёт начала игры, т.к. происходит длительный поиск участников сессии;
Игрок может по итогу играть в одиночестве.

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

Поэтому стоит при разработке учитывать возможность симуляции других игроков: подготовить удобное API для управления игровыми персонажами и разработать систему ИИ. Боты смогут быстро заполнить недостающие места в сессии и скрасят геймплей одиноким игрокам. Также это позволит создавать тренировочные или обучающие сессии, где игрок самостоятельно сможет ознакомиться с возможностями игры или отточить свои навыки.

4. Обработка дисконнекта:

Ещё один важный момент, о котором принято не задумываться сразу. Игроки могут покидать игру, по собственному желанию или под воздействием иных факторов.

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

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

За умышленный выход из матча можно накладывать штрафы или временный бан. А если игру покидает хост, то нужно ещё позаботиться о горячей смене хоста в сессии.

Это всё подразумевает разработку каких-то дополнительных систем, которые могут потребовать очень глубокого расположения в проекте. И закладывать такие системы намного легче на более ранних стадиях, чем на поздних.

Были рассмотрены наиболее часто используемые варианты топологий подключения и их особенности. С тем, какой вариант выбрать для своей игры и своего бюджета, должно стать немножко понятнее. Но со временем попробовать нужно будет каждый. Топология – это не то, что можно выбрать один раз и потом использовать в каждом проекте. Выбор придётся делать регулярно, взвешивая все "за" и "против" для каждого нового случая.

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

Network topologies: Unity Docs
Going multiplayer: YouTube Unite 2024
Your first multiplayer game: YouTube Unite 2024
Distributed Authority for multiplayer games: YouTube Unite 2024
Differences between P2P and dedicated game server: servers.com
Гибридные модели в сетевых играх: SkyPro
NAT для новичков: Habr
NAT на пальцах: Merionet
NAT Punch-through for Multiplayer Games: Keith Johnston
How to use Unity Relay: Youtube Code Monkey
Читы в гейм-индустрии: Habr
Как расправиться с читерами: Habr