UEFN ve Unreal Engine Multiplayer'da Player Location Desync Sorunu Nasıl Çözülür?

Multiplayer Transform Desync Kabusu

Her multiplayer oyun geliştiricisi, netcode'un kendisine yalan söylemeye başladığı o anla eninde sonunda karşılaşır. Bir oyuncunun koltuğa oturduğu, koltuğun haritada hareket ettiği ve sunucuda her şeyin kusursuz göründüğü bir sekans yazarsınız. Ancak ikinci bir client açtığınızda illüzyon bozulur. Client A kendisini koltukta mükemmel bir şekilde giderken görür. Client B ise koltuğun hareket ettiğini, Client A'nın ise başlangıç noktasında havada donmuş bir şekilde kaldığını görür.

Bu fenomen — uefn player location desync — oyuncu girişlerini kullanarak üzerinde oyuncu taşıyan proplarda MoveTo komutlarını tetiklerken karşılaşılan, iyi belgelenmiş bir sorundur. Sunucu doğru mutlak konumu kaydeder, ancak simulated proxies (oyuncunun diğer client'lardaki temsilleri) güncellenmiş transform bilgisini parent prop'tan devralamaz.

İster Unreal Editor for Fortnite (UEFN) içinde özel bir deneyim oluşturun, ister Unreal Engine 5'te bağımsız bir dedicated server mimarisi kurun, attachment replication'ın neden başarısız olduğunu anlamak kritiktir. Bu eğitimde, Network Dormancy mekaniklerini, attachment'ların neden client-side prediction'ı bozduğunu ve replication graph'ı dünya durumunuza uymaya nasıl zorlayacağınızı inceleyeceğiz.

Attachment'lar Neden Network Updates'i Bozar?

Desync sorununu çözmek için önce Unreal Engine'in actor replication'ı hiyerarşik olarak nasıl ele aldığını anlamanız gerekir.

Bir character actor bir prop'a bağlandığında (örneğin bir koltuk cihazına oturmak), transformu parent actor'a göre göreceli (relative) hale gelir. Bant genişliğinden tasarruf etmek için Unreal Engine, Network Dormancy (Ağ Uyku Modu) kavramını agresif bir şekilde kullanır.

Bir oyuncu koltuğa oturduğunda ve doğrudan movement input vermeyi bıraktığında, sunucunun replication graph'ı oyuncu aktörünü dormant (uykuda) olarak işaretleyebilir. Sunucu şunu varsayar: "Oyuncu bağımsız olarak hareket etmiyor, bu yüzden onun için güncelleme göndermeme gerek yok. Sadece hareket eden koltuk için güncelleme göndereceğim."

Desync'in Arkasındaki Matematik

• Server Tick Rate: UEFN'de genellikle 30Hz.
• Prop NetUpdateFrequency: Genellikle varsayılan olarak saniyede 100 güncelleme.
• Character MinNetUpdateFrequency: Giriş algılanmadığında saniyede 2.0'a kadar düşebilir.

Koltuk üzerinde MoveTo çağırdığınızda, koltuğun transformu 30Hz'de güncellenir. Ancak bağlı oyuncu dormant olduğu için, diğer client'lar oyuncunun göreceli konumunu güncellemelerini söyleyen RPC (Remote Procedure Call) mesajını asla almazlar. Sonuç? Devasa bir görsel desync.

Adım 1: UEFN Verse Geçici Çözümü

UEFN hata raporlarında geliştiriciler hayati bir ipucu fark ettiler: Koltuktan inmek sorunu düzeltiyor. Bunun nedeni, oyuncunun movement mode durumunu Custom'dan tekrar Walking'e geçirmenin sunucuyu Network Dormancy'yi temizlemeye (flush) ve tüm client'lara kesin bir mutlak transform güncellemesi göndermeye zorlamasıdır.

Verse içinde oyuncuyu gerçekten indirmeden bir mikro-teleport ile replication graph'ı uyandırarak bu durumu simüle edebiliriz.

# [Verse kodu orijinaliyle aynı kalır]

Aynı koordinatlara TeleportTo çağırarak, C++ motorunu TeleportPhysics flag'ini tetiklemeye zorlarız, bu da o aktör için client-side prediction'ı tamamen sıfırlar.

Adım 2: Native Unreal Engine C++ Çözümü

Kaynak koduna erişiminiz varsa, dormancy durumunu yönetmek için doğrudan networking API'sini kullanabilirsiniz.

// UE5 C++ Force Net Update Örneği
// [C++ kodu orijinaliyle aynı kalır]

Adım 3: Durumu Backend'e Kaydetme

Canlı replication desync'ini düzeltmek savaşın sadece yarısıdır. Kalıcı bir dünyanız varsa, veritabanına doğru mutlak koordinatların kaydedildiğinden emin olmalısınız. horizOn, oyun geliştiricileri için özel olarak tasarlanmış bir Backend-as-a-Service sunar.

5 En İyi Uygulama

1. Client'ın Attachment Durumuna Asla Güvenmeyin: Her zaman server-authoritative RPC'ler kullanın.
2. Araçlar için NetDormancy'yi Manuel Yönetin: Hareket sırasında FlushNetDormancy çağırın.
3. Hiyerarşileri Sığ Tutun: Çok derin attachment zincirlerinden kaçının.
4. Kritik Değişiklikler İçin Güvenilir RPC'ler Kullanın: Binme/inme için NetMulticast kullanın.
5. İnerken Transform Doğrulaması Yapın: Sunucu tarafında konum kontrolü yapın.

Sonuç

Multiplayer desync'ler genellikle ağ trafiğini optimize etme çabasının bir sonucudur. Network Dormancy'yi anlayarak Verse veya C++ ile güncellemeleri zorlayabilirsiniz. replication graph'ınızın kontrolünü elinize alın.

Backend'inizi ölçeklendirmeye hazır mısınız? horizOn'u ücretsiz deneyin.