Управление сетевой релевантностью: передавать каждому клиенту нужную часть мира

Определить потребности каждого соединения

Управление релевантностью выбирает объекты или данные, нужные каждому клиенту. Авторитетный мир может оставаться значительно больше реплицируемого представления любого клиента. Правила могут учитывать расстояние, владельца, команду или участие в матче. Mirror описывает эти варианты, а Unreal оценивает релевантность акторов для каждого соединения. Одной видимости камеры недостаточно: снаряд вне экрана или слышимый противник всё ещё может влиять на игрока. [1][2]

Рассматривать смену набора как жизненный цикл

При входе в релевантный набор нужно передать достаточно начального состояния для создания пригодного клиентского представления. Последующие дельты должны ссылаться на базовое состояние, которое у этого клиента действительно есть. Выход требует определённой операции скрытия или удаления представления; авторитетный объект при этом не обязательно удаляется. Сетевая видимость Unity прямо управляет созданием, удалением и трафиком объектов на клиентах. [3]

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

Расчётный пример: экономия данных и колебания у границы

Рассмотрим условный сервер с 1000 динамических объектов. Передача 64 байт полезной нагрузки на объект с частотой 20 обновлений в секунду требует 1000 * 64 * 20 = 1280000 байт в секунду для одного клиента. Если этому клиенту нужны 80 объектов, та же модель требует 80 * 64 * 20 = 102400 байт в секунду. Это расчёты полезной нагрузки без заголовков, сжатия, начального состояния и повторных передач.

Для обычного отбора по расстоянию предположим, что объекты входят в набор в пределах 100 метров, но остаются в нём до удаления более чем на 120 метров. Такой гистерезис уменьшает повторное создание около границы. Он также удерживает дополнительные объекты; выбирайте запас с учётом скорости движения, частоты обновления и стоимости входа. Проверяйте разрешения на информацию до этого вспомогательного пространственного правила, чтобы увеличенный радиус выхода никогда не раскрывал запрещённого противника.

Построить и измерить обработку релевантности

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

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

Понимать ограничения

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

Источники

• [1] Interest Management — Mirror Networking contributors.
• [2] Actor Relevancy — Epic Games, Unreal Engine documentation.
• [3] Object Visibility — Unity Technologies, Netcode for GameObjects documentation.