Unreal Engine’de güzel sahne neden oyun değildir? Frame time, bellek ve streaming gerçeği

Editör görüntüsü çalışan ürün değildir

Unreal Engine güçlü varsayılanları sayesinde yeni kullanıcıya çok hızlı biçimde etkileyici görüntü verir. Yüksek kaliteli asset paketleri, Lumen, Nanite, volumetric efektler ve sinematik post process birkaç saat içinde sunum değeri yüksek bir kare oluşturabilir. Bu hız öğrenmek ve prototiplemek için değerlidir. Fakat editörde belirli kameradan alınan görüntü ile oyuncunun saatlerce kullanacağı gerçek zamanlı ürün arasında büyük fark vardır. Oyun; kamera dönerken, içerik yüklenirken, AI çalışırken, input işlenirken, ses çalarken, UI güncellenirken ve hedef cihaz ısınırken de güvenilir kalmalıdır.

Bu nedenle sahne değerlendirmesi “kaç FPS alıyorum” sorusuyla bitmez. Hangi donanımda, hangi çözünürlükte, hangi ayarlarda, hangi kamera rotasında ve hangi build türünde ölçüm yapıldığı belirtilmelidir. Editör ek yük taşır; development build ile shipping build farklı davranabilir. Güçlü masaüstü bilgisayar düşük hedef cihazdaki sorunu gizleyebilir. Tek bir ortalama değer kısa hitch’leri saklayabilir. Teknik olgunluk, görüntüyü küçültmek değil, hedef deneyimi tanımlayıp maliyeti kanıtla yönetmektir.

FPS sonuçtur, frame time teşhis dilidir

Frames per second oyuncunun hissettiği akıcılığı anlatır; frame time ise her karenin üretilmesi için harcanabilecek süreyi milisaniye olarak düşünmemizi sağlar. Yaklaşık 30 FPS hedefi kare başına 33,3 ms, 60 FPS 16,7 ms, 120 FPS ise 8,3 ms bütçe bırakır. Bu bütçe yalnızca rendering için değildir. Game thread, render thread, GPU, fizik, animasyon, audio ve diğer işler aynı ritimde tamamlanmalıdır. Bir sistem 60 FPS ortalamasını korusa bile düzenli aralıklarla 40 ms spike üretiyorsa oyuncu takılmayı fark eder.

Frame time’a bakmak optimizasyon konuşmasını somutlaştırır. “Efekti biraz hafifletelim” yerine GPU’nun translucency pass’inde kaç milisaniye harcadığı ölçülebilir. “Kod yavaş” yerine game thread’de hangi scope’un süre aldığı bulunabilir. Epic’in Unreal Insights aracı CPU ve GPU timeline’larını, task’ları, bellek allocation’larını, asset loading ve network verisini incelemek için tasarlanmıştır. Stat komutları hızlı sinyal verir; Insights ve frame capture araçları kök neden aramak için daha derin veri sağlar. Ölçüm olmadan yapılan optimizasyon çoğu zaman görünür kaliteyi azaltır ama gerçek darboğaza dokunmaz.

CPU bound ve GPU bound aynı problem değildir

GPU bound sahnede ekran kartı bir kareyi tamamlamak için CPU’dan daha uzun çalışır. Yüksek çözünürlük, karmaşık material, yoğun translucency, pahalı gölge, post process, fazla pixel overdraw veya ağır lighting bunun nedeni olabilir. CPU bound durumda ise oyun mantığı, actor tick’leri, animation update, physics, AI, draw call hazırlığı veya başka thread işleri sınır oluşturur. Çözünürlüğü düşürmek GPU darboğazını rahatlatabilir, fakat game thread maliyetini düzeltmez. Aynı şekilde actor sayısını azaltmak pahalı bir shader’ı çözmez.

İlk teşhis için game, draw ve GPU süreleri karşılaştırılır; VSync ve frame cap gibi sınırların sonucu maskelemediği kontrol edilir. Sonra maliyetli bölgeyi izole eden test yapılır. Resolution scale değiştiğinde süre belirgin düşüyorsa GPU yönü araştırılır. Rendering özelliklerini geçici kapatmak, görünür actor sayısını azaltmak veya stat gruplarını incelemek hipotez üretir. Ancak console komutuyla rastgele özellik kapatmak nihai çözüm değildir. Amaç sistemin neden pahalı olduğunu ve oyuncu değerini koruyarak hangi yapısal değişikliğin gerekli olduğunu anlamaktır.

Bellek bütçesi performanstan bağımsız değildir

RAM ve VRAM doluluğu yalnızca crash anında önemli değildir. Sistem sınırda çalıştığında streaming daha sık devreye girebilir, allocation baskısı artabilir, garbage collection spike’ları görülebilir ve asset’ler ihtiyaç anında hazır olmayabilir. Texture, mesh, animation, audio, shader, render target ve runtime verisi aynı fiziksel kaynakları paylaşır. Editörde bir sahnenin açılması, bütün oyun boyunca aynı anda bulunacak içerik kombinasyonunu temsil etmeyebilir. Özellikle açık dünya veya hızlı traversal içeren oyunda komşu bölgeler, karakterler ve geçici efektler birlikte düşünülmelidir.

Bellek denetimi için “asset kaç megabayt” sorusunun yanında residency ve yaşam süresi sorulur. Ne zaman yükleniyor, ne kadar süre kalıyor, hangi referans unload olmasını engelliyor, aynı verinin kopyası oluşuyor mu? Unreal Insights Memory Insights allocation ve free olaylarını incelemeye, Low-Level Memory Tracker ise kategorilere göre kullanım izlemeye yardım eder. Reference Viewer, Size Map ve platform araçları da zinciri anlamlandırır. Büyük texture’ı küçültmek bazen doğrudur; bazen asıl sorun hiç kullanılmayan asset’i hard reference ile sürekli bellekte tutmaktır.

Texture streaming havuzu sihirli depo değildir

Texture streaming sistemi, ihtiyaç duyulan mip seviyelerini görünürlük ve tahmini ekran boyutuna göre yükleyip boşaltır. “Pool over budget” uyarısını sadece pool değerini yükselterek susturmak sorunu başka cihaza taşır. Hedef platformda ayrılabilecek VRAM sınırlıdır ve texture dışındaki kaynaklar da aynı alanı kullanır. Epic’in streaming metrics dokümantasyonu texture, wanted ve streaming pool değerlerini; geçici bellek, bekleyen request ve update sürelerini birlikte okumayı açıklar. Tek sayı yerine sistemin neden talebi karşılayamadığı incelenmelidir.

Çözüm bağlama göre değişir. Yanlış texel density, gereksiz 4K texture, çok sayıda benzersiz set, never stream işaretli içerik, büyük UI texture’ları veya hatalı bounds soruna katkı verebilir. Bazı hero asset’ler yüksek çözünürlüğü hak ederken arka plandaki küçük prop aynı bütçeyi kullanmamalıdır. Virtual texture veya farklı packing yaklaşımı yararlı olabilir, fakat teknoloji seçimi ölçümün yerini tutmaz. Portfolyo sahnesinde aday texture çözünürlüğünü listelemekten çok, ekran kullanımına göre neden o bütçeyi seçtiğini ve target cihazdaki sonucu göstermelidir.

Streaming yalnızca level açıp kapatmak değildir

Dünya içeriğinin ne zaman yükleneceği, oyuncu hareketi ve depolama hızıyla ilişkili bir tasarım problemidir. Bir bölge çok geç istenirse pop-in veya bekleme görülür; çok erken istenirse bellek gereksiz dolar. Level Streaming, World Partition, data layer ve asset manager gibi sistemler farklı ölçeklerde içerik yaşam döngüsünü düzenler. Doğru yapı projenin kamera hızı, görüş mesafesi, teleport davranışı, co-op oyuncu dağılımı ve platform IO kapasitesine bağlıdır. Aynı açık dünya çözümü koridor oyununa kopyalanmamalıdır.

Streaming testinde yalnızca yavaş yürüyüş kullanılmaz. En hızlı araç, ani yön değişimi, respawn, fast travel ve save yükleme gibi kötü durumlar denenir. Asset Loading Insights, hangi paketin ne kadar sürede yüklendiğini ve bağımlılık zincirini anlamaya yardım eder. Tek bir küçük obje beklenmedik hard reference nedeniyle büyük paketi çağırabilir. Async load kullanmak otomatik olarak hitch’i çözmez; ana thread’de yapılan post-load veya component registration işi yine spike yaratabilir. Yükleme planı, içerik organizasyonu ve runtime davranışı birlikte tasarlanmalıdır.

Material maliyeti node sayısıyla ölçülmez

Material graph’ında çok node görmek maliyetli olabileceğini düşündürür, fakat asıl maliyet derlenen shader, kullanılan feature, pixel sayısı, overdraw ve pass sayısıyla ilişkilidir. Statik switch permutation sayısını büyütebilir; translucency aynı pixel’i birçok kez işletebilir; tam ekran efekt küçük bir mesh shader’ından daha pahalı olabilir. Shader Complexity ve Quad Overdraw görselleştirmeleri ilk bakışı sağlar, GPU profiler ve frame capture ise hangi pass’in süre aldığını gösterir. Sadece instruction count’a bakarak bütün performans kararı verilmez.

Master material tasarımı da “her şeyi tek shader’a koymak” değildir. Çok esnek dev graph, compile süresini ve permutation’ı büyütebilir; küçük değişiklik yüzlerce shader’ı yeniden derletebilir. Öte yandan her asset için benzersiz material bakım maliyeti doğurur. Projenin yüzey aileleri, platformları ve variation ihtiyacına göre sınırlı, belgeli bir yapı kurulmalıdır. Artist parametreyi ne zaman kullanacağını bilmeli, pahalı özelliğin fallback’i olmalıdır. Material optimization yalnızca teknik artist görevi değildir; görsel hedefi ve tekrar kullanımını anlamadan yapılan kesinti sanat yönünü bozabilir.

Nanite ve Lumen bütçeyi kaldırmaz, bütçeyi değiştirir

Nanite yüksek geometrik ayrıntıyı verimli stream ve render etmek için güçlü bir sistemdir; bu, her asset’in sınırsız ve kontrolsüz olabileceği anlamına gelmez. Material, masked yüzey, deformasyon, overdraw, disk boyutu ve platform desteği hâlâ önemlidir. Lumen de dinamik global illumination ve reflection için geniş olanak sunar; fakat kalite ayarı, sahne yapısı, çözünürlük, hardware veya software ray tracing yolu ve hedef kare hızı maliyeti belirler. Teknoloji adı, ölçüm raporu değildir.

Yeni araçlar eski kontrol noktalarını tamamen silmek yerine başka katmanlara taşır. Artist artık manuel LOD üretimine daha az zaman ayırabilir, fakat source asset hijyeni, material sayısı, collision, instance kullanımı ve görsel doğrulama devam eder. Lighting artist dinamik ışıkla hızlı iterasyon yapabilir, ancak shadow ve reflection maliyetini izler. Teknik karar “Nanite açık mı” değil, belirli içerik ve platform için hangi rendering yolunun hedef deneyimi en güvenilir biçimde verdiğidir. Portfolyoda özellik logosu göstermek yerine karşılaştırmalı capture, limit ve seçim gerekçesi sunmak daha değerlidir.

Actor, component ve tick sayısı görünmez CPU maliyeti yaratır

Sahnede binlerce küçük actor düzenlemek editörde rahat görünebilir, fakat runtime’da component registration, transform update, tick, collision ve replication maliyeti doğabilir. Her actor tick etmese bile yönetim yükü vardır. Bir özelliği her frame kontrol etmek yerine event tabanlı güncelleme, timer, significance veya daha toplu veri yapısı kullanılabilir. Instanced Static Mesh ve Hierarchical Instanced Static Mesh benzer geometriyi daha verimli render etmeye yardım edebilir; ancak collision, culling ve gameplay ihtiyaçları göz önünde tutulur.

Blueprint’in “yavaş”, C++’ın “hızlı” olduğu gibi kaba cümleler doğru teşhis değildir. Blueprint ile uygun yapıda birçok oyun sistemi üretilebilir; pahalı olan sık çağrılan ağır iş, yanlış veri erişimi veya gereksiz allocation olabilir. C++’a taşınmış kötü algoritma da pahalıdır. Unreal Insights ile çağrı sıklığı ve süre görülmeden yeniden yazım kararı almak zaman kaybettirebilir. Önce oyuncu senaryosunda ölçüm alınır, sonra en pahalı ve anlamlı bölge düzeltilir. Optimizasyon mühendislik olduğu kadar önceliklendirme disiplinidir.

VFX, foliage ve translucency birlikte test edilir

Görsel efektler genellikle kısa süreli olduğu için maliyeti gözden kaçar. Combat anında onlarca Niagara system, decal, light ve translucent particle aynı anda çalışabilir. Ortalama sakin sahne hedefi tutarken en yoğun encounter frame budget’ı aşar. Spawn sayısı, particle yaşam süresi, bounds, collision, simulation target ve overdraw birlikte incelenmelidir. Fixed bounds yanlışsa sistem gereksiz görünür kalabilir veya erken kaybolabilir. Ekranı kaplayan düşük opaklıklı parçacıklar az vertex’e rağmen yüksek pixel maliyeti yaratabilir.

Foliage da benzer biçimde yalnızca triangle sayısıyla açıklanmaz. Instance sayısı, culling distance, shadow, wind material, masked overdraw ve World Position Offset maliyeti bir araya gelir. Orman sahnesi tek bir güzel kamerada değil, zemine yakın, tepeden, hızlı hareket ve farklı gün ışığında test edilmelidir. HLOD, impostor veya farklı foliage type düzeni kullanılabilir. Burada amaç bitkiyi yok etmek değildir; görsel frekansın oyuncunun gerçekten fark ettiği alanlara bütçe ayırmaktır. Profiling yaratıcı hedefe karşı değil, hedefin oyun boyunca korunabilmesi için yapılır.

Target hardware olmadan optimizasyon tamamlanmış sayılmaz

Geliştirme bilgisayarı çoğu zaman hedef cihazdan güçlü, farklı sürücülü ve farklı depolama davranışına sahiptir. Console, düşük seviye PC, handheld veya mobil cihazda CPU çekirdek düzeni, birleşik bellek, thermal limit ve IO özellikleri değişir. Device profile ve scalability ayarı bu farkları yönetmeye yardım eder; fakat gerçek cihaz testi yerine geçmez. Paketlenmiş build düzenli aralıkla hedefte çalıştırılmalı, yalnızca final haftasına bırakılmamalıdır. Sorun ne kadar geç görülürse içerik miktarı o kadar büyür.

Test rotası tekrar edilebilir olmalıdır. Aynı save, aynı kamera yolu, aynı encounter ve aynı süre kullanılırsa değişiklikler karşılaştırılabilir. Ortalama, düşük yüzde frame, hitch sayısı, bellek zirvesi, yükleme süresi ve crash gibi ölçüler kaydedilebilir. Isınma sonrası uzun test, kısa ilk çalıştırmadan farklı sonuç verebilir. Regression takibi için build numarası ve cihaz ayarı rapora eklenir. Küçük öğrenci ekibi bile bu disiplini uygulayabilir: tek bir orta seviye bilgisayar hedeflenir, sabit rota oluşturulur ve her milestone’da aynı test tekrarlanır.

Ölçüm odaklı portfolyo sahnesi nasıl hazırlanır?

İyi teknik portfolyo çalışması dev açık dünya olmak zorunda değildir. Küçük bir oynanabilir alan seçilir; hedef çözünürlük, cihaz sınıfı ve kare hızı baştan yazılır. Scene budget; texture, material, ışık, actor ve efekt için yaklaşık hedeflere ayrılır. Blockout aşamasında temel rota ölçülür. İçerik eklendikçe aynı rota tekrar kaydedilir ve pahalı değişiklikler not edilir. Final sunum beauty shot, kısa gameplay, engine overview, profiler capture ve en önemli iki optimizasyon kararını birlikte gösterir.

Adayın her sistemi mükemmel çözmesi beklenmez. Daha değerli olan, sorunu doğru adlandırması ve kanıtla önceliklendirmesidir. Örneğin GPU bound sahnede texture çözünürlüğünü rastgele azaltmak yerine pahalı translucent fog’un süre etkisini ölçmek; streaming hitch’inde tüm asset’leri preload etmek yerine hard reference zincirini bulmak; CPU spike’ında bütün Blueprint’i C++’a çevirmek yerine gereksiz tick’i kaldırmak iyi düşünce gösterir. Önce, değişiklik ve sonra verisi açıkça sunulursa portfolyo yalnızca görüntü değil, üretim kararı kanıtı olur.

• Hedef cihaz, çözünürlük, kalite ayarı, build türü ve test rotasını her ölçümle birlikte yazın.
• FPS yanında game, draw ve GPU frame time değerlerini karşılaştırın; spike’ları ortalamadan ayrı inceleyin.
• Bellek, streaming, asset dependency ve yükleme davranışını görsel kaliteden bağımsız düşünmeyin.
• Her optimizasyon için önce hipotez kurun, tek değişkeni test edin ve görsel ya da oynanış etkisini kaydedin.
• Portfolyoda özellik isimlerini değil, hedefe göre alınmış teknik kararları ve doğrulama verisini öne çıkarın.

Optimizasyon raporu ekip kararına dönüşmelidir

Profiler capture kendi başına çözüm değildir. Rapor; test koşulu, beklenen hedef, görülen sapma, kök neden hipotezi, önerilen değişiklik ve görsel ya da oynanış etkisini birlikte anlatmalıdır. Bir pass’in pahalı olduğunu göstermek, o pass’in neden kullanıldığını bilmeden yeterli değildir. Teknik artist, rendering engineer, level artist ve designer aynı veriyi farklı ihtiyaçlarla okur. İyi rapor suçlu asset aramaz; bütçeyi ve yaratıcı değeri karşılaştırabilecek ortak bağlam verir.

Değişiklik uygulandıktan sonra aynı rota yeniden ölçülür. Bir alandaki kazanç başka alanda maliyet doğurmuş olabilir; düşük GPU süresi karşılığında CPU spike veya kötü pop-in oluşabilir. Sonuç source control değişikliği ve build numarasıyla kaydedilir, böylece regression olduğunda geçmiş karar bulunur. Öğrenci projesinde tek sayfalık performans günlüğü bile bu alışkanlığı geliştirir. Amaç yüzlerce grafik değil, ölçümden eyleme ve eylemden doğrulamaya giden zinciri kurmaktır.