Zero Ping Spikes, Tam Freeze: Nihai UEFN Server Crash Fix Protokolü

Her multiplayer oyun geliştiricisi eninde sonunda o korkunç senaryoyla karşılaşır: Oyuncular yüksek riskli bir maçın ortasındadır, aksiyon zirveye ulaşmıştır ve aniden her şey durur. Oyuncular hareket edemez. Ateş edemezler. rubber-banding yoktur ve oyun içi debug istatistikleri olaydan hemen öncesine kadar kesinlikle sıfır ping veya lag spikes gösterir. 10 ila 20 saniye boyunca dünya tamamen donar. Sonra kaçınılmaz olan gerçekleşir; herkes aynı anda lobiye atılır.

Unreal Editor for Fortnite (UEFN) içinde geliştirme yapıyorsanız veya özel Unreal Engine dedicated servers ile çalışıyorsanız, bu "silent freeze" teşhis edilmesi en sinir bozucu hatalardan biridir. Sunucu düzgün bir şekilde kapanmadığı için genellikle elinizde sıfır crash logs ve belirgin bir yeniden oluşturma adımı kalmaz.

Bu kılavuz, kesin uefn server crash fix protokolüdür. Bu sessiz donmaların tam olarak neden oluştuğunu, Unreal Engine main thread yapısının network driver ile nasıl etkileşime girdiğini ve oyuncularınızın ilerlemelerini bir daha asla kaybetmemelerini sağlamak için multiplayer backend yapınızı nasıl kurşun geçirmez hale getireceğinizi inceleyeceğiz.

Bir "Sessiz" Sunucu Donmasının Anatomisi

Bir sunucu çökmesini düzeltmek için önce bunun neden standart bir bağlantı kesilmesi yerine donma gibi göründüğünü anlamanız gerekir.

Bir oyuncu çökmeden önce "lag spikes" yaşamadığını bildirdiğinde, genellikle ağ gecikmesinden (ping) bahsediyordur. Unreal Engine'de ağ paketleri, işletim sisteminin soket katmanıyla yakından çalışan UNetDriver tarafından işlenir. Ancak asıl oyun simülasyonu (oyuncu girdilerinin işlenmesi, mermilerin hareket ettirilmesi, Verse mantığının güncellenmesi ve physics çalıştırılması) sunucunun Game Thread üzerinde gerçekleşir.

Game Thread yapınız bir infinite loop, imkansız derecede ağır bir hesaplama veya bir Out-Of-Memory (OOM) istisnası ile karşılaşırsa, thread tamamen kilitlenir.

O 20 saniyelik donma sırasında arka planda şunlar olur:

1. Game Thread Locks: Simülasyon X karesinde durur. Yeni konumlar hesaplanmaz. Hiçbir RPCs (Remote Procedure Calls) işlenmez.
2. Network Driver Starves: Game Thread kilitlendiği için sunucu, istemcilere düzenli durum güncellemeleri (Actor replications) göndermeyi durdurur.
3. Client-Side Prediction Fails: İstemci, hareket girdileri için onay almayı durdurur. Oyuncunun sunucuyla senkronizasyonunun bozulmasını önlemek için client-side prediction motoru oyuncuyu olduğu yerde durdurur.
4. Timeout Threshold Reached: Sunucunun watchdog zamanlayıcısı veya istemcinin connection timeout eşiği (Unreal Engine'de genellikle 20-30 saniye civarı) sonunda aşılır. Bağlantı zorla sonlandırılır ve oyuncular lobiye atılır.

Ping artışı olmamasının nedeni budur. Ağ bağlantısı mükemmel durumdaydı; sunucunun beyni çalışmayı durdurdu.

Kök Neden 1: Verse Thread Starvation ve Sonsuz Döngüler

Bir UEFN sunucu çökmesinin en yaygın sorumlusu, ana thread'i kilitleyen optimize edilmemiş Verse kodudur. Verse oldukça eşzamanlı bir dildir, ancak yield yapmadan devasa bir senkron döngü çalıştırırsanız sunucu karesini durdurursunuz.

Sorun: Synchronous Blocking

Dinamik olarak spawn edilmiş 5.000 prop içeren bir diziniz olduğunu ve bir oyun olayına göre durumlarını güncellemeniz gerektiğini düşünün. Standart bir for döngüsü çalıştırırsanız, sunucu 5.000 öğenin tamamını tek bir karede (30Hz tick rate için yaklaşık 33,3 milisaniyelik bir bütçesi vardır) işlemelidir.

# BAD CODE: Bu, Game Thread'i kilitleyecek ve sessiz donmaya neden olacaktır
ProcessMassivePropArray(Props: []creative_prop): void =
    for (Prop : Props):
        # Ağır uzamsal matematik veya durum güncellemeleri
        CalculateComplexState(Prop)
        UpdatePropTransform(Prop)

CalculateComplexState prop başına sadece 0,05 ms sürerse, 5.000 prop'un işlenmesi 250 ms sürecektir. Sunucu karesi büyük ölçüde takılır. Bunu arka arkaya birkaç kez yapın veya birden fazla oyuncu için aynı anda tetikleyin; sunucu watchdog, thread'in öldüğünü varsayacak ve instance'ı sonlandıracaktır.

Çözüm: Suspends ile Time-Slicing

Mantık aşırı yüklemeleri için uygun bir uefn server crash fix uygulamak için, yürütmeyi motora geri vermek üzere Verse'ün <suspends> etkisini kullanmalısınız; bu, sunucunun döngünüze devam etmeden önce network ve physics motorlarını tick etmesine olanak tanır.

# GOOD CODE: Time-sliced işleme thread kilitlenmesini önler
ProcessMassivePropArrayAsync(Props: []creative_prop)<suspends>: void =
    var ProcessedCount: int = 0
    
    for (Prop : Props):
        CalculateComplexState(Prop)
        UpdatePropTransform(Prop)
        
        set ProcessedCount += 1
        
        # Ana thread kilitlenmesini önlemek için her 50 öğede bir yürütmeyi bırak
        if (ProcessedCount >= 50):
            set ProcessedCount = 0
            Sleep(0.0) # Bir sonraki frame tick'e kadar bırakır

Sleep(0.0) çağırarak Verse VM'e şunu söylersiniz: "Bu fonksiyonu duraklat, Unreal Engine'in mevcut kareyi oluşturmayı bitirmesine ve ağ paketlerini göndermesine izin ver, ardından bu döngüye bir sonraki karede devam et." Bu, sunucu tick rate değerinizi sabit tutar ve sessiz donmayı önler.

Kök Neden 2: Bellek Tükenmesi (OOM Kills)

16GB veya 32GB RAM atayabileceğiniz geleneksel Unreal Engine dedicated servers yapısının aksine, UEFN instance'ları Epic'in altyapısında son derece kısıtlı konteynerli ortamlarda çalışır.

Oyununuz dinamik olarak actor, VFX veya ses bileşenlerini yok etmeden spawn ediyorsa, bir memory leak oluşturuyorsunuz demektir. Sunucu konteyneriniz katı bellek bütçesini aştığında, hipervizör işlemi anında sonlandıracaktır. Bu, tam olarak aynı belirtiyle sonuçlanır: anında, sessiz bir donma ve ardından lobiye atılma.

Sızıntıyı Teşhis Etme

UEFN'deki memory leaks genellikle şunlardan kaynaklanır:

• Verse aracılığıyla nesneler spawn etmek ve Dispose() çağırmadan önce referansı kaybetmek.
• Eskilerini temizlemeden oyunculara sürekli yeni partikül sistemleri eklemek.
• Verse map veya array yapılarında sınırsız veri depolamak (örneğin, 4 saatlik bir oturumda sonsuz büyüyen bir dizide her oyuncu öldürmesini günlüğe kaydetmek).

Object Pooling Çözümü

Kaçınabiliyorsanız oyun sırasında asla dinamik actor örneklemeyin. Bunun yerine, OnBegin aşamasında sınırlı sayıda actor (örneğin 100 mermi) önceden spawn edin ve bunları haritanın altına gizleyin. Bir oyuncu ateş ettiğinde, gizli mermiyi silaha ışınlayın ve görünür hale getirin. Bir hedefe çarptığında tekrar gizleyin.

Bu, bellek ayak izinizin 1. dakikadan 100. dakikaya kadar tamamen statik kalmasını garanti ederek OOM çökmelerini tamamen ortadan kaldırır.

Kök Neden 3: Chaos Physics Aşırı Yükü

Unreal Engine'in Chaos physics çözücüsü inanılmaz derecede güçlüdür, ancak çakışan çarpışmaları hesaplamak hesaplama açısından maliyetlidir.

Tam olarak aynı konumda 200 fiziksel nesne spawn ederseniz, fizik çözücü aynı anda 200 çakışan çarpışma hacmini çözmeye çalışır. Çözücü süresi sağlıklı bir ~2ms'den felaket bir >2000ms'ye fırlayacaktır. Fizik thread'inin çarpışma patlamasını çözmesini beklerken Game Thread askıda kalır, ağ paketlerini düşürür ve istemcileri dondurur.

Oyununuz oyuncuların envanter öğelerini düşürmesine izin veriyorsa, collision bounds yapılarının mükemmel şekilde kesişmemesi için spawn konumlarına hafif rastgele ofsetler eklediğinizden emin olun. Kötü niyetli kişilerin oturumunuzu çökertmek için bu aşırı yükleri bilerek nasıl tetikleyebileceğine dair daha derin bir bakış için The Uefn Server Performance Exploit Explained Hard Armoring Your Unreal Engine Netcode analizimize göz atın.

Başarısızlık İçin Mimari: Oyuncu Durumunu Kaydetme

Mükemmel kodla bile donanım arızalanır. Bulut instance'ları çöker. Öngörülemeyen motor hataları garbage collection çökmelerini tetikler. Bir extraction shooter, bir RPG veya bir tycoon oyunu gibi kalıcı bir oyun oluşturuyorsanız, bir sunucu çökmesi 50 oyuncunun son bir saatlik ilerlemesini kaybetmesi anlamına gelemez.

Backend mimarisinin amatör projeleri profesyonel oyunlardan ayırdığı yer burasıdır.

Yalnızca bir oturumun sonunda veri kaydetmeye güveniyorsanız (örneğin, oyuncu manuel olarak "Oyundan Ayrıl" seçeneğine tıkladığında), bir sunucu çökmesi o instance'ın uçucu belleğinde saklanan tüm verileri silecektir.

Manuel Yaklaşım: Özel Backend Mühendisliği

Veri kaybını önlemek için, player state verilerini sürekli olarak harici bir veritabanına kaydeden bir sisteme ihtiyacınız vardır. Tipik olarak bu şunları içerir:

1. Yetkili bir API gateway kurulumu.
2. Asenkron POST istekleri göndermek için FHttpModule etrafında özel bir Unreal Engine subsystem sarmalayıcısı yazmak.
3. Devasa yazma isteği akışını yönetmek için veritabanı sharding yönetimi.
4. Veritabanının geçici olarak bağlantısının kesilmesi durumunda exponential backoff ve yeniden deneme mantığını uygulamak.

Bunu kendiniz oluşturmak; load balancers, veritabanı sharding ve SSL sertifika yönetimi kurulumunu gerektirir; bu da kolayca 4-6 haftalık özel altyapı çalışması demektir. Ayrıca, özel HTTP uygulamanız bir veritabanı yanıtı beklerken Game Thread'i engellerse, yanlışlıkla düzeltmeye çalıştığınız sunucu donmasına neden olursunuz.

Modern Yaklaşım: Backend-as-a-Service

Bulut altyapısıyla boğuşmak yerine, modern geliştiriciler özel BaaS platformları kullanır. horizOn ile bu backend servisleri oyun motorları için önceden yapılandırılmış ve yüksek düzeyde optimize edilmiş olarak gelir.

Durum güncellemelerini asenkron olarak güvenli bir şekilde kabul eden, önceden oluşturulmuş, ultra düşük gecikmeli bir veritabanına kolayca bağlanabilirsiniz. Oyuncu envanterlerini, XP'lerini ve konumlarını birkaç dakikada bir (veya boss öldürme gibi yüksek değerli olaylardan hemen sonra) horizOn platformuna kaydederek, rastgele bir UEFN sunucu çökmesi felaket bir veri kaybı yerine küçük bir rahatsızlık haline gelir. Oyuncular lobiye atılır, yeni bir sunucuya katılırlar ve eşyaları tam olarak bıraktıkları yerdedir.

Oyuncu durumlarını istemci, sunucu ve backend arasında mükemmel şekilde hizalı tutmaya yönelik daha gelişmiş teknikler için How To Fix Player Location Desync In Uefn And Unreal Engine Multiplayer kılavuzumuzu inceleyin.

Oyun Sunucularınızı Kurşun Geçirmez Hale Getirmek İçin 5 En İyi Uygulama

Oyun oturumlarınızın ağır yük altında kararlı kalmasını sağlamak için bu savaşta test edilmiş kuralları hemen uygulayın:

1. Ağır Döngüleri Her Zaman Time-Slice Yapın: Yield yapmadan tek bir karede 100 öğeden büyük diziler üzerinde asla işlem yapmayın. İş yükünü birden fazla sunucu tick'ine bölmek için <suspends> ve Sleep(0.0) kullanın.
2. Sıkı Object Pooling Uygulayın: Sık kullanılan öğeler (mermiler, hasar sayıları, geçici VFX) için dinamik spawn kullanımını yasaklayın. Başlatma sırasında bir havuz önceden tahsis edin ve referansları geri dönüştürün.
3. Durum Kayıtlarını Oturum Sonundan Ayırın: İlerlemeyi kaydetmek için asla oyunun bitmesini beklemeyin. Kritik verileri elde edildiği anda kaydedin (örneğin, bir oyuncu efsanevi bir öğeyi yağmaladığı milisaniyede harici backend'inize kaydetmek).
4. Collision Channels Yapınızı Denetleyin: Küçük düşen öğelerin, görsel kalıntıların ve ölü bedenlerin birbirlerinin çarpışmasını yok sayacak şekilde ayarlandığından emin olun. Chaos çözücü aşırı yüklerini önlemek için fiziği yalnızca statik dünya geometrisine karşı hesaplayın.
5. Veri Yapılarınızı İzleyin: Bir maç boyunca Verse'de bir diziye veya map'e veri ekliyorsanız, eski verileri budamak için bir mekanizma olduğundan emin olun. Sınırsız diziler, Out-Of-Memory çökmeleri için saatli bombalardır.

Sonuç

Lobiye atılmayla sonuçlanan sessiz bir sunucu donması neredeyse hiçbir zaman gerçek bir ağ hatası değildir. Sonsuz döngülerle boğulmuş, bellekten yoksun bırakılmış veya fizik hesaplamalarıyla ezilmiş bir Game Thread belirtisidir. Asenkron Verse modellerini benimseyerek, bellek ayak izinizi sıkı bir şekilde yöneterek ve her sunucu instance'ını son derece uçucu olarak değerlendirerek, bu çökmelerin sıklığını büyük ölçüde azaltabilirsiniz.

En önemlisi, oyununuzu kaçınılmaz bir çökme gerçekleştiğinde oyuncularınızın zarar görmeyeceği şekilde mimari edin. Multiplayer backend yapınızı ölçeklendirmeye ve oyuncularınızın verilerini sunucu çökmelerinden korumaya hazır mısınız? horizOn platformunu ücretsiz deneyin ve altyapıyı biz halledelim, siz oyununuzu oluşturmaya odaklanın.

---

Kaynak: Server Crash / Freeze (random)