Por que Creative Modes sofrem com o dobro de Ping: Correções arquiteturais para Otimização de Ping em Multiplayer Game Servers

Sua fila principal de Matchmaking de battle royale roda com um ping nítido abaixo de 30ms, mas no momento em que os jogadores carregam uma sessão de Creative Mode gerada por usuários, a latência dobra para 60ms ou mais. Essa 'penalidade de latência do Creative Mode' é um problema notório para estúdios que lançam jogos sandbox, mas ainda é pouco compreendido. É uma consequência direta de orquestração dinâmica de servidores, carregamento dinâmico de assets e roteamento regional subótimo. Para resolver isso, os desenvolvedores devem transicionar de arquiteturas de Matchmaking estáticas para estratégias modernas de otimização de ping em Multiplayer Game Servers.

Por que Creative Modes enfrentam uma penalidade de latência

Em partidas Multiplayer padrão, os game servers são pre-warmed e agrupados em clusters nos data centers regionais primários de alto nível. Esses servidores rodam mapas de jogo otimizados e apenas para leitura, que exigem o mínimo de inicialização dinâmica de actors ou replicação de assets. Os algoritmos de Matchmaking aguardam para agrupar jogadores de regiões semelhantes, garantindo que o servidor selecionado esteja fisicamente próximo de todos no lobby.

Os modos Creative e sandbox quebram esse paradigma completamente. Em vez de usar servidores pre-warmed, esses modos provisionam instâncias de containers dedicadas on-demand quando o líder da party inicia uma sessão. Como essas instâncias são inicializadas de forma dinâmica, o orquestrador é forçado a priorizar a disponibilidade do servidor em detrimento da latência de rede.

Se o data center primário mais próximo estiver operando no limite de capacidade, a camada de orquestração roteará a sessão para uma zona de disponibilidade secundária ou para uma região mais distante e barata. Esse desvio dinâmico adiciona instantaneamente de 20ms a 40ms de tempo bruto de trânsito por fibra óptica à conexão do jogador. Além disso, ambientes sandbox permitem que os jogadores criem níveis customizados com milhares de objetos dinâmicos, scripts customizados e dispositivos interativos. Esses objetos causam um overhead de replicação massivo, desacelerando a main thread do servidor e reduzindo o seu tick rate.

O impacto da degradação do Tick Rate na latência percebida

Quando o frame rate de um servidor cai, o loop de replicação de rede também desacelera. Se um servidor tem como alvo um tick rate de 30Hz, o tempo de frame esperado é de 33,3ms. Se um cliente envia um pacote que chega logo após o servidor começar a executar seu tick, esse pacote deve aguardar no buffer de rede até que o próximo tick comece.

Se scripts de sandbox não otimizados derrubarem o tick rate do servidor de 30Hz para 15Hz, o tempo de frame sobe para 66,6ms. Esse atraso de processamento adiciona automaticamente 33,3ms ao round-trip time (RTT) do cliente. A UI de rede in-game do cliente registra esse atraso de processamento local como ping de rede, mesmo que a latência física da fibra permaneça inalterada.

Além disso, o streaming dinâmico de conteúdo gerado por usuários (UGC) força o servidor a serializar e enviar payloads massivos para os jogadores que estão entrando. Esse pico de tráfego de rede causa buffer bloat nos roteadores domésticos e interfaces de rede, levando ao enfileiramento de pacotes. Quando os pacotes esperam em uma fila, a latência dispara e o packet loss aumenta.

Quando scripts de UGC não otimizados sobrecarregam a CPU, as quedas de tick rate podem evoluir para congelamentos completos do servidor. Se você está enfrentando picos massivos de latência sob carga, confira nosso protocolo de correção de crash do servidor para estabilizar seu Netcode.

O papel do MTU e da fragmentação de pacotes no carregamento de UGC

Quando os jogadores carregam um mapa sandbox personalizado, o servidor deve replicar o estado de centenas de actors customizados. Essa sincronização de estado frequentemente excede o tamanho padrão de Maximum Transmission Unit (MTU) de 1500 bytes. Quando os pacotes UDP excedem esse limite, a camada de rede deve fragmentá-los em vários pacotes IP menores.

Se apenas um único fragmento for perdido em trânsito, todo o pacote UDP será descartado pela stack de rede do cliente. Isso dispara a retransmissão de pacotes, causando severos jitters e picos no ping percebido pelo jogador. Como os mapas criativos contêm configurações altamente dinâmicas, essa fragmentação ocorre com muito mais frequência do que em sessões estáticas de battle royale.

Para mitigar isso, os desenvolvedores devem implementar técnicas de serialização personalizadas para compactar os dados de actors de forma mais eficiente. Mantendo os payloads de replicação abaixo do limite de 1200 bytes, você pode evitar completamente a fragmentação de IP. Essa alteração simples estabiliza os caminhos de trânsito de rede e melhora significativamente a qualidade da conexão.

A mecânica de roteamento dinâmico de servidores e Cold Starts

O roteamento IP padrão depende de configurações estáticas de caminho que funcionam bem para localizações estáveis de servidores. Mas quando instâncias de servidor são geradas dinamicamente em uma nuvem distribuída, o roteamento IP unicast padrão falha em escolher o caminho de menor latência. Um jogador que inicia uma sessão criativa recebe um IP unicast dinâmico associado a um nó de container recém-criado.

Como esse IP é temporário, ele não pode aproveitar o roteamento Anycast global. Em vez disso, os pacotes do jogador devem viajar pela internet pública, passando por múltiplos provedores de trânsito não otimizados e saltos de roteamento de ISPs locais. Isso contrasta fortemente com as filas de Matchmaking primárias, que roteiam os jogadores por meio de um proxy de borda habilitado para Anycast.

Esses proxies finalizam as conexões do cliente no Point of Presence (PoP) mais próximo e tunelam os dados através de backbones privados diretamente para o game server. O provisionamento dinâmico também introduz cold starts. Se um container de servidor demorar muito para inicializar, os jogadores podem se deparar com falhas de conexão. Para corrigir isso, você deve entender como diagnosticar problemas de driver e de timeout de conexão, conforme detalhado em nosso guia sobre resolução de timeouts de lançamento de sessão.

Mergulho técnico: Medindo a latência de rede ICMP vs. RTT do Game Loop

Para implementar com precisão a otimização de ping de Multiplayer Game Servers, você deve distinguir entre a latência física de trânsito de rede (ping ICMP/UDP) e o round-trip time (RTT) a nível de aplicação. O primeiro mede o tempo que um pacote de rede bruto leva para viajar até o servidor e voltar. O segundo inclui o atraso de processamento de frame do servidor, o tempo de serialização de rede e a latência de interpolação no lado do cliente.

O principal desafio com as exibições de ping no lado do cliente é que elas medem o tempo total decorrido entre o envio de um pacote e o recebimento de sua confirmação. Se o servidor estiver enfrentando um gargalo de CPU devido ao Garbage Collection ou a cálculos complexos de física, ele atrasará o envio do ACK. O cliente não consegue distinguir esse atraso local do servidor dos atrasos de roteamento, levando a relatórios falsos de ping de rede alto.

Ao executar a verificação de ping no nível do driver de rede e compará-la com o tick rate da main thread do jogo, os desenvolvedores podem isolar esses gargalos. Isso permite que a equipe de orquestração de Backend determine se precisa otimizar o código ou alterar seus caminhos de roteamento de rede. Vamos ver como podemos implementar esse agente de monitoramento.

A seguinte classe C++ compatível com Unreal Engine demonstra como rastrear o ping de rede bruto e separá-lo do overhead de processamento do game loop. Ao calcular essa diferença, você pode determinar se o ping alto de um jogador é causado por um roteamento de rede ruim ou por um frame rate do servidor sobrecarregado.

// 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;
}

Esta classe calcula o FrameProcessingDelayMS comparando o delta time real do tick do servidor com o tick rate alvo. Se o atraso de processamento for alto, o desenvolvedor sabe que precisa otimizar a execução de scripts no lado do servidor, em vez de culpar o provedor de rede. Ao rodar esse sistema em servidores de teste, você pode acompanhar as métricas de qualidade de rede em tempo real.

Arquitetando um orquestrador dinâmico de baixa latência

Para resolver manualmente a penalidade de latência do Creative Mode, você precisa reprojetar sua camada de orquestração de servidores. Uma arquitetura típica se baseia em três pilares fundamentais: pre-warming geograficamente distribuído, roteamento de borda facilitado por Anycast e remoção agressiva de assets.

Primeiro, implemente um orquestrador de pre-warming usando ferramentas como Agones no Kubernetes. Em vez de inicializar containers do zero, mantenha um pequeno pool de instâncias de servidor warm e ociosas em 8 a 12 regiões globais. O sistema de Matchmaking deve monitorar continuamente a densidade de jogadores e escalar dinamicamente esses pools para evitar que os jogadores sejam roteados para regiões distantes durante os horários de pico.

Segundo, posicione uma rede de proxies de borda à frente dos seus game servers. Esses proxies devem usar roteamento IP Anycast para aceitar conexões UDP do cliente na borda de rede mais próxima. O proxy então tunela o tráfego do jogo por meio de um backbone privado dedicado de baixa latência (como o AWS Global Accelerator) até o container real do servidor. Isso contorna os caminhos de roteamento públicos não otimizados que afetam as conexões unicast on-demand.

Terceiro, otimize suas builds de servidor. Remova todos os assets desnecessários do lado do cliente — como texturas de alta resolução, arquivos de áudio e skeletal meshes — da build do Dedicated Server. Isso reduz os tamanhos de imagem de container de vários gigabytes para menos de 200MB, encurtando os tempos de pull do container. Isso permite que cold boots sejam concluídos em menos de 500ms quando a capacidade pre-warmed se esgota.

Simplificando o roteamento de borda e hospedagem com horizOn

Construir e manter um orquestrador geograficamente distribuído com roteamento de borda Anycast exige uma equipe de operações dedicada e milhares de dólares em overhead de infraestrutura em nuvem. É uma tarefa complexa de engenharia que desvia um tempo valioso do desenvolvimento de gameplay. É aqui que o horizOn oferece uma solução turnkey para estúdios indie e de médio porte.

Em vez de escrever load balancers personalizados ou gerenciar clusters Kubernetes em várias nuvens, você pode fazer o deploy das suas builds de servidor na plataforma. Ao aproveitar os tempos de inicialização de container subsegundo e os bancos de dados de borda integrados do horizOn, você elimina timeouts de cold-start e ineficiências de roteamento. Isso garante que seus jogadores experimentem a mesma baixa latência em sessões de sandbox criativo que teriam em lobbies de Matchmaking estruturados.

4 Melhores Práticas para Otimização de Ping de Multiplayer Game Servers

Se você quer manter las latências baixas e os tick rates estáveis em seus modos de jogo criativos, implemente estas quatro estratégias testadas em batalha:

1. Implemente Intercalação de Replicação Agressiva: Agrupe atualizações de actors não críticos (como itens cosméticos ou decorações de sandbox distantes) e replique-os a cada 3 ou 4 frames, em vez de a cada frame. Isso reduz o tamanho do payload de rede e evita o buffer bloat nos roteadores dos clientes.
2. Limite os Orçamentos de Tick (Tick Budgets) de UGC: Imponha limites estritos de execução para scripts gerados por usuários. Se a ilha personalizada de um jogador exceder 5ms de tempo de execução de script por frame, limite ou desative scripts de baixa prioridade para evitar que o tick rate do servidor caia abaixo de 30Hz.
3. Use Handshakes de Conexão Baseados na Borda: Valide a autenticação do jogador e os tokens de sessão no PoP de borda mais próximo antes de roteá-los para o game server. Isso evita que solicitações de autenticação maliciosas consumam ciclos de CPU do servidor e causem atrasos na fila de pacotes para os jogadores ativos.
4. Implemente Escalonamento Dinâmico de Tick Rate: Quando um servidor criativo estiver ocioso ou contiver apenas um jogador, reduza seu tick rate para 10Hz para economizar recursos de CPU. Escale dinamicamente o tick rate de volta para 30Hz ou 60Hz assim que outros jogadores entrarem na sessão, garantindo uma experiência responsiva durante o gameplay multiplayer ativo.

Conclusão e Próximos Passos

Resolver a penalidade de latência nos modos criativos exige uma abordagem dupla: otimizar os tempos de frame do servidor para eliminar o atraso de processamento e rotear o tráfego por backbones de rede dedicados, em vez da internet pública. Ao monitorar os atrasos de processamento do game loop e implementar o roteamento baseado na borda, você pode garantir uma experiência de baixo ping para seus jogadores.

Pronto para otimizar sua infraestrutura multiplayer? Faça o deploy de sua próxima build no horizOn para obter roteamento de borda automatizado e game servers de baixa latência distribuídos globalmente. Ou explore a documentação da API para saber mais sobre a integração de bancos de dados de rede de borda em sua arquitetura de Backend.

---

Fonte: Higher ping especially in creative