Kreatif Modlarda Neden İki Kat Ping Görülür: Multiplayer Game Server Ping Optimization İçin Mimari Çözümler

Ana battle royale matchmaking sıranız 30ms'nin altında akıcı bir ping ile çalışırken, oyuncuların kullanıcı tarafından oluşturulan (UGC) bir kreatif session'a girdiği an latency değeri ikiye katlanarak 60ms veya üzerine çıkar. Bu 'kreatif mod latency cezası' (creative mode latency penalty), sandbox oyunlar geliştiren stüdyolar için kronik bir sorun olmasına rağmen hâlâ tam olarak anlaşılamamıştır. Bu durum; dinamik server orchestration, dinamik asset loading ve sub-optimal bölgesel routing işlemlerinin doğrudan bir sonucudur. Bu sorunu çözmek için geliştiricilerin, statik matchmaking mimarilerinden modern multiplayer game server ping optimization stratejilerine geçiş yapması gerekir.

Kreatif Modlar Neden Latency Cezasıyla Karşılaşır?

Standart multiplayer maçlarda, oyun server'ları önceden hazırlanır (pre-warmed) ve birincil, üst düzey bölgesel veri merkezlerinde kümelenir. Bu server'lar, minimum dinamik actor initialization veya asset replication gerektiren optimize edilmiş, salt okunur oyun haritalarını çalıştırır. Matchmaking algoritmaları benzer bölgelerdeki oyuncuları bir araya getirmek için bekler, böylece seçilen server'ın lobideki herkese fiziksel olarak yakın olmasını sağlar.

Kreatif ve sandbox modları bu paradigmayı tamamen yıkar. Önceden hazırlanmış server'lar kullanmak yerine, bu modlar bir grup lideri bir session başlattığında talep üzerine (on-demand) dedicated container instance'lar oluşturur. Bu instance'lar dinamik olarak başlatıldığından, orchestrator network latency yerine server kullanılabilirliğine öncelik vermek zorunda kalır.

En yakın birincil veri merkezi tam kapasiteyle çalışıyorsa, orchestration katmanı session'ı ikincil bir kullanılabilirlik alanına (availability zone) veya daha ucuz, uzak bir bölgeye yönlendirir (route eder). Bu dinamik değişiklik, oyuncunun bağlantısına anında 20ms ila 40ms arasında ham fiber geçiş süresi (transit time) ekler. Dahası sandbox ortamları, oyuncuların binlerce dinamik nesne, özel script'ler ve interaktif cihazlarla özel bölümler (custom levels) oluşturmasına olanak tanır. Bu nesneler devasa bir replication overhead yaratır; bu da server'ın ana thread'ini (main thread) yavaşlatır ve tick rate değerini düşürür.

Tick Rate Düşüşünün Hissedilen Latency Üzerindeki Etkisi

Bir server'ın frame rate değeri düştüğünde, network replication döngüsü de yavaşlar. Server 30Hz'lik bir tick rate hedefliyorsa, beklenen frame süresi 33.3ms'dir. Eğer bir client, tam server tick işlemini yürütmeye başladıktan hemen sonra ulaşan bir paket gönderirse, bu paket bir sonraki tick başlayana kadar network buffer'ında beklemek zorundadır.

Optimize edilmemiş sandbox script'leri server tick rate değerini 30Hz'den 15Hz'e düşürürse, frame süresi 66.6ms'ye yükselir. Bu işleme gecikmesi (processing delay), client'ın round-trip süresine (RTT) otomatik olarak 33.3ms ekler. Client'ın oyun içi network arayüzü (UI), fiziksel fiber latency değeri değişmemiş olsa bile bu lokal işleme gecikmesini network ping olarak kaydeder.

Ayrıca, kullanıcı tarafından oluşturulan içeriğin (UGC) dinamik olarak stream edilmesi, server'ı bağlanan oyunculara devasa veri paketleri (payload'lar) serialize etmeye ve göndermeye zorlar. Network trafiğindeki bu ani artış, ev router'larında ve network arayüzlerinde buffer bloat oluşmasına yol açarak paketlerin kuyruğa girmesine (packet queuing) neden olur. Paketler kuyrukta beklediğinde latency aniden yükselir ve paket kaybı (packet loss) artar.

Optimize edilmemiş UGC script'leri CPU'yu aşırı yüklediğinde, tick rate düşüşleri tamamen server donmalarına (freeze) dönüşebilir. Yük altında büyük latency dalgalanmaları yaşıyorsanız, netcode yapınızı stabilize etmek için server crash fix protocol kılavuzumuza göz atın.

UGC Yüklemesinde MTU ve Packet Fragmentation Rolü

Oyuncular özel bir sandbox haritasına yüklendiğinde, server yüzlerce özel actor'ün durumunu (state) replicate etmek zorundadır. Bu durum senkronizasyonu (state synchronization) genellikle standart 1500 baytlık Maksimum İletim Birimi (MTU) boyutunu aşar. UDP paketleri bu limiti aştığında, network katmanı bunları daha küçük birden fazla IP paketine bölmek (fragment etmek) zorunda kalır.

Eğer tek bir fragment bile iletim sırasında kaybolursa, tüm UDP paketi client'ın network stack'i tarafından atılır. Bu durum paket yeniden iletimini (packet retransmission) tetikler; bu da oyuncunun hissettiği ping değerinde ciddi dalgalanmalara (jitter) ve ani yükselmelere yol açar. Kreatif haritalar son derece dinamik kurulumlar içerdiğinden, bu fragmentation statik battle royale session'larına kıyasla çok daha sık gerçekleşir.

Bunu hafifletmek için geliştiriciler, actor verilerini daha sıkı paketlemek adına özel serialization teknikleri uygulamalıdır. Replication payload'larını 1200 bayt eşiğinin altında tutarak IP fragmentation sorununu tamamen önleyebilirsiniz. Bu basit değişiklik, network geçiş yollarını (network transit paths) stabilize eder ve bağlantı kalitesini önemli ölçüde artırır.

Dinamik Server Routing ve Cold Start Mekanizmaları

Standart IP routing, sabit server konumları için iyi çalışan statik yol konfigürasyonlarına dayanır. Ancak server instance'ları dağıtık bir bulut (distributed cloud) üzerinde dinamik olarak ayağa kaldırıldığında, standart unicast IP routing en düşük latency'ye sahip yolu seçmekte yetersiz kalır. Bir kreatif session başlatan oyuncu, yeni oluşturulan bir container node'una bağlı dinamik bir unicast IP alır.

Bu IP geçici olduğundan global Anycast routing yapısından yararlanamaz. Bunun yerine, oyuncunun paketleri açık internet üzerinden seyahat etmek zorunda kalır; bu da optimize edilmemiş birden fazla transit sağlayıcıdan ve yerel ISP routing adımlarından (hops) geçmesi demektir. Bu durum, oyuncuları Anycast özellikli bir edge proxy üzerinden yönlendiren birincil matchmaking kuyruklarıyla tam bir tezat oluşturur.

Bu proxy'ler, client bağlantılarını en yakın Point of Presence (PoP) noktasında sonlandırır ve verileri özel omurgalar (private backbones) üzerinden doğrudan oyun server'ına tüneller. Dinamik provisioning (tedarik/dağıtım) aynı zamanda cold start sorunlarını da beraberinde getirir. Bir server container'ının ayağa kalkması çok uzun sürerse, oyuncular bağlantı hatalarıyla karşılaşabilir. Bunu düzeltmek için, resolving session launch timeouts kılavuzumuzda detaylandırıldığı gibi, driver ve bağlantı zaman aşımı (timeout) sorunlarını nasıl teşhis edeceğinizi anlamalısınız.

Teknik Derin Bakış: ICMP Network Latency ve Game Loop RTT Karşılaştırması

Multiplayer game server ping optimization işlemini doğru bir şekilde uygulamak için, fiziksel network transit latency (ICMP/UDP ping) ile uygulama seviyesindeki round-trip süresi (RTT) arasındaki farkı ayırt etmeniz gerekir. İlki, ham bir network paketinin server'a gidip geri gelmesi için geçen süreyi ölçer. İkincisi ise server'ın frame processing delay, network serialization süresi ve client tarafındaki interpolation latency değerlerini de içerir.

Client tarafındaki ping göstergelerinin en büyük sorunu, bir paketin gönderilmesi ile onayının (ACK) alınması arasında geçen toplam süreyi ölçmeleridir. Eğer server, Garbage Collection veya karmaşık fizik hesaplamaları nedeniyle bir CPU darboğazı (bottleneck) yaşıyorsa, ACK göndermeyi geciktirir. Client, bu lokal server gecikmesini routing gecikmelerinden ayırt edemez ve bu da hatalı yüksek network ping raporlarına yol açar.

Geliştiriciler, ping kontrolünü network driver seviyesinde gerçekleştirip bunu ana oyun thread'i (main game thread) tick rate değeri ile karşılaştırarak bu darboğazları izole edebilirler. Bu sayede backend orchestration ekibi, kodu optimize etmeleri mi yoksa network routing yollarını mı değiştirmeleri gerektiğine karar verir. Şimdi bu izleme ajanını (monitoring agent) nasıl entegre edebileceğimize bakalım.

Aşağıdaki Unreal Engine uyumlu C++ sınıfı, ham network ping değerini izlemeyi ve bunu game loop işleme yükünden (processing overhead) ayırmayı göstermektedir. Aradaki farkı hesaplayarak, bir oyuncunun yüksek ping değerinin kötü network routing'den mi yoksa zorlanan bir server frame rate değerinden mi kaynaklandığını belirleyebilirsiniz.

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

Bu sınıf, sunucu tick işleminin gerçek delta zamanını hedef tick rate değeriyle karşılaştırarak FrameProcessingDelayMS değerini hesaplar. İşleme gecikmesi yüksekse geliştirici, network sağlayıcısını suçlamak yerine server tarafındaki script yürütmesini optimize etmesi gerektiğini anlar. Bu sistemi test server'larında çalıştırarak network kalite metriklerini gerçek zamanlı olarak takip edebilirsiniz.

Düşük Latency Değerine Sahip Dinamik Bir Orchestrator Tasarlamak

Kreatif modlardaki latency cezasını manuel olarak çözmek için server orchestration katmanınızı yeniden tasarlamanız gerekir. Tipik bir mimari üç temel sütuna dayanır: geo-distributed pre-warming (coğrafi olarak dağıtılmış ön hazırlık), Anycast destekli edge routing ve agresif asset stripping (asset ayıklama).

İlk olarak, Kubernetes üzerinde Agones gibi araçlar kullanarak bir pre-warming orchestrator uygulayın. Container'ları sıfırdan başlatmak yerine, 8 ila 12 küresel bölgede boşta bekleyen, hazır (idle, warm) server instance'larından oluşan küçük bir havuz bulundurun. Matchmaking sistemi oyuncu yoğunluğunu sürekli izlemeli ve yoğun saatlerde oyuncuların uzak bölgelere yönlendirilmesini önlemek için bu havuzları dinamik olarak ölçeklendirmelidir.

İkinci olarak, oyun server'larının önüne bir edge proxy network'ü yerleştirin. Bu proxy'ler, en yakın network edge'inde client UDP bağlantılarını kabul etmek için Anycast IP routing kullanmalıdır. Proxy daha sonra oyun trafiğini özel, düşük gecikmeli bir özel omurga (AWS Global Accelerator gibi bir private backbone) üzerinden gerçek server container'ına tüneller. Bu, isteğe bağlı (on-demand) unicast bağlantılarını olumsuz etkileyen optimize edilmemiş genel routing yollarını devre dışı bırakır.

Üçüncü olarak, server build'lerinizi optimize edin. Dedicated server build'inden yüksek çözünürlüklü kaplamalar (textures), ses dosyaları ve skeletal mesh'ler gibi gereksiz tüm client tarafı asset'leri temizleyin (strip edin). Bu, container imaj boyutlarını birkaç gigabayttan 200MB'ın altına düşürerek container pull sürelerini kısaltır. Böylece pre-warmed kapasite tükendiğinde cold start'ların 500ms'nin altında tamamlanmasını sağlar.

horizOn ile Edge Routing ve Hosting İşlemlerini Kolaylaştırma

Anycast edge routing'e sahip coğrafi olarak dağıtılmış (geo-distributed) bir orchestrator kurmak ve sürdürmek, özel bir operasyon ekibi ve bulut altyapısında binlerce dolarlık ek maliyet gerektirir. Bu durum, oyun geliştirme sürecinden değerli zamanınızı çalan karmaşık bir mühendislik işidir. İşte bu noktada horizOn, bağımsız (indie) ve orta ölçekli stüdyolar için anahtar teslim bir çözüm sunar.

Özel load balancer'lar yazmak veya birden fazla bulut üzerinde Kubernetes cluster'ları yönetmek yerine, server build'lerinizi doğrudan platforma dağıtabilirsiniz (deploy edebilirsiniz). horizOn'un saniyenin altındaki container boot sürelerinden ve yerleşik edge database'lerinden yararlanarak cold-start zaman aşımlarını ve routing verimsizliklerini ortadan kaldırırsınız. Bu sayede oyuncularınız, yapılandırılmış matchmaking lobilerinde olduğu gibi kreatif sandbox session'larında da aynı düşük latency deneyimini yaşarlar.

Multiplayer Game Server Ping Optimization İçin En İyi 4 Pratik Yöntem

Kreatif oyun modlarınızda latency değerlerini düşük ve tick rate değerlerini kararlı tutmak istiyorsanız, bu dört adet sahada kanıtlanmış stratejiyi uygulayın:

1. Agresif Replication Interleaving Uygulayın: Kritik olmayan actor güncellemelerini (kozmetik öğeler veya uzaktaki sandbox dekorasyonları gibi) gruplandırın ve bunları her frame yerine her 3. veya 4. frame'de bir replicate edin. Bu, network payload boyutunu azaltır ve client router'larında buffer bloat oluşmasını engeller.
2. UGC Tick Bütçelerini Sınırlandırın: Kullanıcı tarafından oluşturulan script'ler üzerinde katı yürütme sınırları uygulayın. Bir oyuncunun özel adası frame başına 5ms'den fazla script yürütme süresi harcıyorsa, server tick rate değerinin 30Hz'in altına düşmesini önlemek için düşük öncelikli script'leri sınırlandırın (throttle edin) veya devre dışı bırakın.
3. Edge Tabanlı Connection Handshake'ler Kullanın: Oyuncu kimlik doğrulamalarını (authentication) ve session token'larını oyun server'ına yönlendirmeden önce en yakın edge PoP noktasında doğrulayın. Bu, kötü niyetli kimlik doğrulama isteklerinin server CPU döngülerini tüketmesini ve aktif oyuncular için paket kuyruğu (packet queue) gecikmelerine yol açmasını engeller.
4. Dinamik Tick-Rate Ölçeklendirmesini Devreye Alın: Bir kreatif server boşta (idle) olduğunda veya yalnızca tek bir oyuncu içerdiğinde, CPU kaynaklarından tasarruf etmek için tick rate değerini 10Hz'e düşürün. Diğer oyuncular session'a katılır katılmaz tick rate'i dinamik olarak 30Hz veya 60Hz'e yükselterek aktif multiplayer oyun deneyimi sırasında yüksek yanıt hızına sahip bir deneyim sunun.

Sonuç ve Sonraki Adımlar

Kreatif modlardaki latency cezasını çözmek çift yönlü bir yaklaşım gerektirir: işleme gecikmesini ortadan kaldırmak için server frame sürelerini optimize etmek ve trafiği genel internet yerine özel network omurgaları (backbones) üzerinden yönlendirmek. Game loop işleme gecikmelerini izleyerek ve edge tabanlı routing uygulayarak oyuncularınız için düşük ping değerine sahip bir deneyim garanti edebilirsiniz.

Multiplayer altyapınızı optimize etmeye hazır mısınız? Otomatik edge routing ile küresel olarak dağıtılmış, düşük latency değerine sahip oyun server'larına sahip olmak için bir sonraki build'inizi horizOn'a deploy edin. Veya edge-network database'lerini backend mimarinize nasıl entegre edeceğinizi öğrenmek için API dokümanlarını inceleyin.

---

Kaynak: Higher ping especially in creative