Почему в Creative Modes пинг увеличивается вдвое: архитектурные решения для Multiplayer Game Server Ping Optimization

Ваша основная очередь Matchmaking для battle royale работает с отличным пингом менее 30 мс, но как только игроки загружаются в созданную пользователями сессию Creative Mode, задержка удваивается до 60 мс или более. Этот «штраф за задержку в Creative Mode» — известная проблема для студий, выпускающих sandbox-игры, но её причины всё ещё плохо понимают. Это прямое следствие динамической оркестрации серверов, динамической загрузки ассетов и неоптимальной региональной маршрутизации. Чтобы решить эту проблему, разработчикам необходимо перейти от статических архитектур Matchmaking к современным стратегиям Multiplayer Game Server Ping Optimization.

Почему в Creative Modes возникает штраф за задержку

В стандартных Multiplayer-матчах игровые серверы предварительно «разогреты» (pre-warmed) и сгруппированы в основных высококлассных региональных дата-центрах. На этих серверах запущены оптимизированные карты игрового мира, доступные только для чтения, которые требуют минимальной динамической инициализации акторов или репликации ассетов. Алгоритмы Matchmaking группируют игроков из близких регионов, гарантируя, что выбранный Dedicated Server физически находится рядом со всеми участниками лобби.

Creative Modes и sandbox-режимы полностью разрушают эту парадигму. Вместо использования pre-warmed серверов эти режимы выделяют контейнеры Dedicated Server по запросу (on-demand), когда лидер группы запускает сессию. Поскольку эти инстансы запускаются динамически, оркестратор вынужден отдавать приоритет доступности серверов, а не сетевой задержке.

Если ближайший основной дата-центр перегружен, уровень оркестрации направит сессию во вторичную зону доступности или более дешевый удаленный регион. Этот динамический сдвиг мгновенно добавляет от 20 до 40 мс физической задержки передачи по оптоволокну к подключению игрока. Кроме того, sandbox-окружения позволяют игрокам создавать кастомные уровни с тысячами динамических объектов, пользовательских скриптов и интерактивных устройств. Эти объекты вызывают огромный оверхед на репликацию, замедляя основной поток (main thread) сервера и снижая его tick rate.

Влияние падения Tick Rate на воспринимаемую задержку

При падении FPS сервера цикл сетевой репликации также замедляется. Если сервер нацелен на tick rate в 30 Гц, ожидаемое время кадра составляет 33,3 мс. Если клиент отправляет пакет, который приходит сразу после того, как сервер начал выполнять свой такт (tick), этот пакет должен находиться в сетевом буфере до начала следующего такта.

Если неоптимизированные sandbox-скрипты снижают tick rate сервера с 30 Гц до 15 Гц, время кадра увеличивается до 66,6 мс. Эта задержка обработки автоматически добавляет 33,3 мс к клиентскому RTT. Внутриигровой сетевой интерфейс клиента регистрирует эту локальную задержку обработки как пинг сети, хотя физическая задержка в оптоволокне остается неизменной.

Кроме того, динамический стриминг пользовательского контента (UGC) заставляет сервер сериализовать и отправлять огромные объемы данных подключающимся игрокам. Этот всплеск сетевого трафика вызывает переполнение буфера (buffer bloat) на домашних роутерах и сетевых интерфейсах, что приводит к образованию очередей пакетов. Когда пакеты ждут в очереди, пинг резко возрастает, а потеря пакетов увеличивается.

Когда неоптимизированные UGC-скрипты перегружают CPU, падение tick rate может перерасти в полные зависания сервера. Если вы сталкиваетесь с огромными скачками задержки под нагрузкой, ознакомьтесь с нашим server crash fix protocol, чтобы стабилизировать ваш Netcode.

Роль MTU и фрагментации пакетов при загрузке UGC

Когда игроки загружаются на кастомную sandbox-карту, сервер должен реплицировать состояние сотен кастомных акторов. Эта синхронизация состояния часто превышает стандартный размер Maximum Transmission Unit (MTU) в 1500 байт. Когда UDP-пакеты превышают этот лимит, сетевой уровень должен фрагментировать их на несколько более мелких IP-пакетов.

Если в пути теряется хотя бы один фрагмент, весь UDP-пакет отбрасывается сетевым стеком клиента. Это вызывает повторную отправку пакетов (packet retransmission), что приводит к сильному джиттеру и скачкам воспринимаемого пинга игрока. Поскольку карты в Creative Mode содержат очень динамичные структуры, эта фрагментация происходит гораздо чаще, чем в статических сессиях battle royale.

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

Механика динамической маршрутизации серверов и холодных стартов

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

Поскольку этот IP является временным, он не может использовать глобальную Anycast-маршрутизацию. Вместо этого пакеты игрока должны проходить через публичный интернет, пересекая узлы множества неоптимизированных транзитных провайдеров и локальных провайдеров (ISP). Это резко контрастирует с основными очередями Matchmaking, которые направляют игроков через edge-прокси с поддержкой Anycast.

Эти прокси терминируют клиентские соединения в ближайшей точке присутствия (Point of Presence, PoP) и туннелируют данные по частным магистральным сетям напрямую к контейнеру игрового сервера. Динамическое выделение ресурсов также приводит к холодным стартам (cold starts). Если контейнер сервера запускается слишком долго, игроки могут столкнуться с ошибками подключения. Чтобы исправить это, вам необходимо понять, как диагностировать проблемы с драйверами и тайм-аутами соединений, как описано в нашем руководстве по resolving session launch timeouts.

Технический разбор: измерение сетевой задержки ICMP против RTT игрового цикла

Чтобы точно реализовать Multiplayer Game Server Ping Optimization, необходимо различать физическую задержку транзита сети (ICMP/UDP ping) и время кругового обхода прикладного уровня (RTT). Первое измеряет время, за которое необработанный сетевой пакет доходит до сервера и возвращается обратно. Второе включает в себя задержку обработки кадра сервером, время сетевой сериализации и задержку интерполяции на стороне клиента.

Основная проблема с отображением пинга на стороне клиента заключается в том, что оно измеряет общее время, прошедшее между отправкой пакета и получением подтверждения (ACK). Если сервер испытывает нехватку ресурсов CPU из-за Garbage Collection или сложных физических расчетов, он задерживает отправку ACK. Клиент не может отличить эту локальную задержку сервера от задержек маршрутизации, что приводит к ложным отчетам о высоком пинге сети.

Выполняя проверку пинга на уровне сетевого драйвера и сравнивая ее с tick rate основного игрового потока (main thread), разработчики могут изолировать эти узкие места. Это позволяет команде оркестрации Backend определить, нужно ли им оптимизировать код или изменить маршруты сети. Давайте посмотрим, как мы можем реализовать такой агент мониторинга.

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

// PingMonitor.h
#pragma once

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "PingMonitor.generated.h"

USTRUCT(BlueprintType)
struct FNetworkQualityStats
{
    GENERATED_BODY()

    UPROPERTY(BlueprintReadOnly, Category = "Network Quality")
    float NetworkPingMS;

    UPROPERTY(BlueprintReadOnly, Category = "Network Quality")
    float FrameProcessingDelayMS;

    UPROPERTY(BlueprintReadOnly, Category = "Network Quality")
    float TotalEffectiveRTT;

    FNetworkQualityStats()
        : NetworkPingMS(0.0f)
        , FrameProcessingDelayMS(0.0f)
        , TotalEffectiveRTT(0.0f)
    {}
};

UCLASS()
class MULTIPLAYERGAME_API APingMonitor : public AActor
{
    GENERATED_BODY()

public:
    APingMonitor();

protected:
    virtual void BeginPlay() override;

public:
    virtual void Tick(float DeltaTime) override;

    UFUNCTION(BlueprintCallable, Category = "Network Quality")
    FNetworkQualityStats GetCurrentNetworkStats() const;

private:
    float LastPingTime;
    float HeartbeatInterval;
    float ServerTickRate;
    
    TMap<int32, double> SentHeartbeats;
    int32 HeartbeatSequenceId;
    FNetworkQualityStats CachedStats;

    void SendHeartbeat();
    void HandleHeartbeatAck(int32 SequenceId);
};

// PingMonitor.cpp
#include "PingMonitor.h"
#include "GameFramework/PlayerController.h"
#include "Engine/World.h"

APingMonitor::APingMonitor()
    : HeartbeatInterval(1.0f)
    , ServerTickRate(30.0f)
    , HeartbeatSequenceId(0)
{
    PrimaryActorTick.bCanEverTick = true;
    PrimaryActorTick.TickInterval = 0.1f;
}

void APingMonitor::BeginPlay()
{
    Super::BeginPlay();
    LastPingTime = GetWorld()->GetTimeSeconds();
}

void APingMonitor::Tick(float DeltaTime)
{
    Super::Tick(DeltaTime);

    float CurrentTime = GetWorld()->GetTimeSeconds();
    if (CurrentTime - LastPingTime >= HeartbeatInterval)
    {
        SendHeartbeat();
        LastPingTime = CurrentTime;
    }
}

void APingMonitor::SendHeartbeat()
{
    HeartbeatSequenceId++;
    double SendTimeStamp = FPlatformTime::Seconds();
    SentHeartbeats.Add(HeartbeatSequenceId, SendTimeStamp);
}

void APingMonitor::HandleHeartbeatAck(int32 SequenceId)
{
    if (SentHeartbeats.Contains(SequenceId))
    {
        double SendTime = SentHeartbeats[SequenceId];
        double ReceiveTime = FPlatformTime::Seconds();
        float RTT = static_cast<float>((ReceiveTime - SendTime) * 1000.0);

        float FrameTimeMS = GetWorld()->GetDeltaSeconds() * 1000.0f;
        float ExpectedTickTimeMS = 1000.0f / ServerTickRate;
        float ProcessingDelay = FMath::Max(0.0f, FrameTimeMS - ExpectedTickTimeMS);

        CachedStats.NetworkPingMS = RTT - ProcessingDelay;
        CachedStats.FrameProcessingDelayMS = ProcessingDelay;
        CachedStats.TotalEffectiveRTT = RTT;

        SentHeartbeats.Remove(SequenceId);

        UE_LOG(LogNet, Log, TEXT("RTT: %.2fms | NetPing: %.2fms | FrameDelay: %.2fms"),
            CachedStats.TotalEffectiveRTT, CachedStats.NetworkPingMS, CachedStats.FrameProcessingDelayMS);
    }
}

FNetworkQualityStats APingMonitor::GetCurrentNetworkStats() const
{
    return CachedStats;
}

Этот класс рассчитывает FrameProcessingDelayMS, сравнивая фактическое дельта-время (delta time) такта сервера с целевым tick rate. Если задержка обработки высока, разработчик понимает, что нужно оптимизировать выполнение скриптов на стороне сервера, а не винить сетевого провайдера. Запустив эту систему на тестовых серверах, вы сможете отслеживать метрики качества сети в реальном времени.

Проектирование динамического оркестратора с низкой задержкой

Чтобы вручную решить проблему штрафа за задержку в Creative Mode, вам придется перепроектировать уровень оркестрации серверов. Типичная архитектура опирается на три основных столпа: географически распределенный «разогрев» серверов (pre-warming), edge-маршрутизация с использованием Anycast и агрессивное удаление неиспользуемых ассетов (asset stripping).

Во-первых, внедрите оркестратор с поддержкой pre-warming, используя такие инструменты, как Agones на Kubernetes. Вместо запуска контейнеров с нуля поддерживайте небольшой пул свободных, «теплых» инстансов серверов в 8–12 регионах по всему миру. Система Matchmaking должна постоянно отслеживать плотность игроков и динамически масштабировать эти пулы, чтобы не допускать направления игроков в удаленные регионы в часы пик.

Во-вторых, разверните сеть edge-прокси перед вашими игровыми серверами. Эти прокси должны использовать Anycast IP-маршрутизацию для приема UDP-соединений от клиентов на ближайшей границе сети. Затем прокси туннелирует игровой трафик через выделенную приватную магистраль с низкой задержкой (например, AWS Global Accelerator) к конкретному контейнеру сервера. Это позволяет обойти неоптимизированные общедоступные сетевые маршруты, которые создают проблемы для unicast-соединений по требованию.

В-третьих, оптимизируйте сборки серверов. Удалите все ненужные клиентские ассеты — такие как текстуры высокого разрешения, аудиофайлы и скелетные меши (skeletal meshes) — из сборки Dedicated Server. Это уменьшит размер образов контейнеров с нескольких гигабайт до менее чем 200 МБ, сокращая время скачивания контейнера. Благодаря этому холодный запуск (cold boot) может завершиться менее чем за 500 мс при исчерпании емкости pre-warmed серверов.

Оптимизация Edge-маршрутизации и хостинга с помощью horizOn

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

Вместо написания кастомных Load Balancing решений или управления кластерами Kubernetes в нескольких облаках вы можете просто развернуть сборки серверов на платформе. Используя субсекундное время запуска контейнеров horizOn и встроенные edge-базы данных, вы устраняете тайм-ауты холодного запуска и неэффективность маршрутизации. Это гарантирует, что ваши игроки получат такую же низкую задержку в творческих sandbox-сессиях, как и в структурированных лобби Matchmaking.

4 Best Practices для Multiplayer Game Server Ping Optimization

Если вы хотите сохранить задержки низкими, а tick rate стабильным в ваших творческих режимах игры, внедрите эти четыре проверенные на практике стратегии:

1. Внедрите агрессивное чередование репликации (Replication Interleaving): сгруппируйте некритичные обновления акторов (такие как косметические предметы или отдаленный декор в sandbox) и реплицируйте их каждый 3-й или 4-й кадр вместо каждого кадра. Это уменьшит размер сетевой нагрузки и предотвратит переполнение буфера (buffer bloat) на роутерах клиентов.
2. Ограничьте лимиты времени такта для UGC (UGC Tick Budgets): установите строгие лимиты на выполнение пользовательских скриптов. Если пользовательский остров игрока превышает 5 мс процессорного времени на выполнение скриптов за кадр, ограничьте или отключите низкоприоритетные скрипты, чтобы предотвратить падение tick rate сервера ниже 30 Гц.
3. Используйте edge-авторизацию для подключений (Edge-Based Connection Handshakes): проверяйте авторизацию игроков и токены сессий в ближайшей edge-точке PoP перед маршрутизацией на игровой сервер. Это защитит процессор сервера от обработки вредоносных запросов авторизации, вызывающих задержки в очередях пакетов для активных игроков.
4. Разверните динамическое масштабирование Tick Rate: когда сервер Creative Mode простаивает или содержит только одного игрока, снижайте его tick rate до 10 Гц для экономии ресурсов CPU. Динамически увеличивайте tick rate обратно до 30 Гц или 60 Гц, как только к сессии подключаются другие игроки, обеспечивая плавный геймплей во время активного Multiplayer.

Заключение и следующие шаги

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

Готовы оптимизировать свою Multiplayer-инфраструктуру? Разверните следующую сборку на horizOn, чтобы получить автоматическую edge-маршрутизацию и глобально распределенные игровые серверы с низкой задержкой. Или изучите их документацию по API, чтобы узнать больше об интеграции баз данных edge-сети в архитектуру вашего Backend.

---

Источник: Higher ping especially in creative