Tarayıcıda açık dünya geliştirmek aslında neler gerektiriyor?

Yazan: Mariana Muntean, Cinevva CEO'su

Cinevva ekibi, yakın dönem oyun geliştirme dünyasının en şeffaf mühendislik günlüklerinden birini kısa süre önce yayımladı: tamamen tarayıcıda çalışan çok oyunculu bir açık dünya geliştirme girişimimizi belgeleyen 12 bölümlük bir seri. İndirme yok. Uygulama mağazası yok. Yalnızca bir URL.

Proje, "spike" adını verdiğimiz 24 teknik deneyi kapsıyordu; bunlar, her biri riskli bir soruyu yanıtlamak üzere tasarlanmış kısa ve odaklı prototiplerdi. Her spike, hemen şimdi tarayıcınızda açıp çalıştırabileceğiniz canlı kaynak koduyla birlikte yayımlandı. Seri, Cinevva'nın CTO'su ve kurucu ortağı Oleg Sidorkin tarafından yazıldı ve pazarlama metninden çok, tarayıcıların 2026'da gerçekte neler yapabildiğinin ön saflarından bir saha günlüğü gibi okunuyor.

Seriyi okumaya değer kılan şey — hiçbir zaman arazi sistemleri geliştirmeyi planlamıyor olsanız bile — altında yatan yöntem. Bu, pahalı herhangi bir taahhütte bulunmadan önce iddialı bir projenin risklerini nasıl azaltabileceğinize dair bir vaka çalışması.

Önce en zor sorudan başlamak

Çoğu açık dünya projesi öngörülebilir bir sırayla başarısız olur. Önce harika bir fikir ortaya çıkar. Ardından güzel bir sahne gelir. Sonra da oynanış daha ortada yokken kare süresi bütçenizin çoktan tükendiğini keşfedersiniz.

Ekibimiz bu sırayı tersine çevirdi. İlk spike özellikle çirkin tasarlanmıştı: 512 metrelik bir arazi ağı, 500 örneklenmiş nesne, prosedürel yükseklik gürültüsü, bir su düzlemi ve sis. Gölge yoktu, görsel iyileştirme geçişi yoktu. Tek soru, kamera dünyada hareket ederken tarayıcının kararlı bir kare hızını koruyup koruyamayacağıydı.

Koruyabildi. Bu "evet" yanıtı, Oleg'in "temel sözleşme" olarak adlandırdığı şeyi oluşturdu: sonraki her özelliğin maliyetini haklı çıkarmak zorunda olduğu, minimal bir sahne için ölçülmüş referans maliyet. Yeni bir efekt harika görünüyor ancak kare bütçesini aşıyorsa yayımlanmıyordu. En azından henüz.

Bu tür bir disiplin kulağa bariz geliyor. Uygulamada ise herkesin bir sonraki görsel başarı için heyecanlandığı hızlı prototipleme ortamlarında nadir görülüyor.

Fizik kumarı

İkinci deney, tarayıcı oyunu geliştiricilerini ikiye bölen mimari bir tartışmayı ele aldı: fizik, daha basit olduğu ana iş parçacığında mı yoksa oluşturmayı engelleyemeyeceği bir Web Worker içinde mi çalışmalı?

Worker tabanlı fizik kâğıt üzerinde daha temizdir. Uygulamada ise korkulan şey gecikmedir. Her giriş olayı mesaj sınırını iki kez geçmek zorundadır: bir kez worker'a ulaşmak, bir kez de sonucu geri getirmek için. Bu gidiş dönüş çok yavaşsa bir tuşa basmanızla karakterinizin hareket ettiğini görmeniz arasındaki süre hantallık hissi yaratır.

Ekip, Rapier fizik motorunu (Rust'tan WebAssembly'ye derlenmiş hâliyle) özel bir worker'a entegre etti, mesaj hattını bağladı ve ölçüm yaptı. Ek yük ihmal edilebilir düzeydeydi. Kontroller hâlâ anında tepki veriyordu. Ancak evrensel bir kuralı değil, belirli bir senaryoyu doğruladığımızı özellikle belirtmeye dikkat ettik. GPU yükü ve veri akışı karmaşıklığı daha sonra değiştiğinde varsayımların yeniden kontrol edilmesi gerekecekti.

Projeyi kurtaran sıkıcı spike'lar

Serinin üçüncü bölümünde ekran görüntüsü yok. Bölüm, gösterişli görünmeyen ancak ürün düzeyinde sonuçları olan üç deneyi ele alıyor.

İlki, çok oyunculu altyapının temelini oluşturan Cloudflare Durable Objects'in gerçek zamanlı konum yayınlarını oyun benzeri tick hızlarında işleyip işleyemeyeceğini test etti. Bu başarısız olsaydı ağ mimarisinin tek ada sahipliği yerine daha başlangıçta parçalanması gerekecekti.

İkincisi, bir mobil kalite profilini doğruladı: adı değiştirilmiş bir masaüstü ön ayarı değil, aynı arazi temelinden oluşturulmuş ve düşük maliyet için açıkça tasarlanmış bir oluşturma yolu. Soru, oluşturucuyu baştan yazmadan dünyanın mobil GPU kısıtlamaları altında okunaklı ve duyarlı kalıp kalamayacağıydı.

Üçüncüsü, üretici iş akışları için yapay zekâ tarafından oluşturulan davranış betiklerinin üretimde kullanılacak kadar güvenilir olup olmayacağını değerlendirdi.

Bunların hiçbiri tanıtım videoları üretmedi. Ancak üçü de sonrasındaki her mimari kararı şekillendiren kesin sınırlar koydu. Oleg, bu "gösterişsiz spike'ların mimariyi görsel spike'lardan daha hızlı değiştirdiğini" yazıyor.

Veri akışı: güzel projelerin dağıldığı nokta

Tek bir sabit karede pek çok şeyi gizleyebilirsiniz. Koşarken bir parça sınırını geçtiğiniz anda oluşan 40 milisaniyelik takılmayı gizleyemezsiniz.

Ekip, sorumlulukları bilinçli olarak ayırıp gelişmiş araziyi oluşturmadan önce veri akışını test etti. Spike 6, basit içerikle komşu parçaların yüklenmesini doğruladı. Ancak bu net sonuçtan sonra Spike 11, aşamalı iyileştirmeyle sıkıştırılmış yükseklik haritası akışını devreye soktu: arazi önce 17 örnek çözünürlüğünde, sonra 33 örnekte ve son olarak 65 örnekli tam ızgarada yükleniyordu.

Sıralama beklediğimizden daha önemliydi. Doğrudan sıkıştırılmış yükseklik parçalarıyla başlasaydık her takılmanın nedeni belirsiz olacaktı. Sorun kod çözmede mi, doku yükleme tıkanmasında mı, yoksa geometri güncellemesinde miydi? Önce basit veri akışını test etmek, belirsizlik kategorilerinden birini tamamen ortadan kaldırdı.

Ortaya pratik bir ders çıktı: yükleme tıkanmalarını ortalama FPS üzerinden değil, doğrudan ölçün. Ortalamalar kare sıçramalarını gizler; oyuncuların gerçekten hissettiği şey de bu sıçramalardır.

Görsel bütçe savaşları

Üç ayrı deney, oluşturma maliyetlerini bir araya toplamak yerine birbirinden bağımsız olarak ele aldı. Bitki örtüsü yoğunluğu ve rüzgâr animasyonu. Uçurum yüzeyleri için üç düzlemli eşlemeye sahip çok katmanlı arazi malzemeleri. Gerçekçi arazi yükü altında basamaklı gölge haritaları.

Bitki örtüsü spike'ı, örnekleri daha az sayıda ağda toplu işlemenin, her bir ot sapındaki poligon sayısını azaltmaktan daha önemli olduğunu gösterdi. Malzeme spike'ı, dikey yüzeylerde üç düzlemli projeksiyonun GPU maliyetine değdiğini ancak beşinci bir doku sıçratma katmanı eklemenin değmediğini ortaya çıkardı. Gölge spike'ı ise 1024 çözünürlükte üç kademenin, GPU süresinde 2 milisaniyeyi aşmadan kabul edilebilir temas gölgeleri sunduğunu belirledi.

Ekip kesin bir kural benimsedi: bir özellik ancak maliyetini ölçülmüş kare süresi verileriyle açıklayabiliyorsa ilerler. Erken belirlenen bu kısıtlama, hacimsel arazi ve clipmap'lerle ilgili sonraki mimari kararları önemli ölçüde sadeleştirdi.

Projenin yönünü değiştiren dönüm noktası

Spike 10'dan önce zihinsel modelimiz "daha büyük dünya, daha fazla geometri demektir" şeklindeydi. Spike 10'dan sonra bu model "sabit geometri bütçesi, kamera merkezli halka güncellemeleri" hâline geldi.

Geometri clipmap'leri — kameranın etrafında merkezlenmiş ve her biri giderek daha kaba hâle gelen eş merkezli arazi halkaları — çizim mesafesi ne olursa olsun üçgen sayısının yaklaşık olarak sabit kalmasını sağladı. Uygulamadaki püf noktası, halka sınırlarındaki geometri geçişiydi: çözünürlük seviyeleri arasındaki değişimin hareket hâlindeyken görünmemesi için tepe yüksekliklerini shader içinde yumuşak biçimde harmanlamak.

Test yönteminden incelikli bir ders çıktı. Clipmap'ler ekran görüntülerinde iyi görünür. Kusurlarını yalnızca kamera halka sınırlarından sürekli olarak geçerken belli ederler. Ekip, sabit hızlı geçişler yapıp zamansal gürültüyü gözlemlemek için zaman harcadı. Oleg, "Ekran görüntüleri yalan söyledi," diye yazıyor. "Gerçeği hareket gösterdi."

Yer altına inmek

Yükseklik haritaları mağaraları temsil edemez. Izgaradaki her nokta için tek bir yükseklik değeri saklarlar. Tünellere, çıkıntılara veya oyulmuş kaya yüzeylerine ihtiyaç duyduğunuz anda hacimsel arazi gerekir.

Spike 12, WebGPU hesaplama shader'larını kullanarak marching cubes'ı GPU üzerinde uyguladı ve 3B işaretli mesafe alanından üçgen ağları çıkardı. Dört adet 64 küplük parça, animasyonlu SDF düzenlemelerinden gelen kare başına ağ güncellemeleriyle aynı anda çalıştı. Hesaplama shader'ı, CPU'ya hiçbir geri okuma yapmadan alanı değerlendirmekten hücreleri sınıflandırmaya ve tepe noktalarını üretmeye kadar her şeyi yönetti.

Zorluk bunu çalıştırmak değildi. Diğer her şeyle birlikte çalışmasını sağlamaktı. Three.js'in sahne grafiğiyle entegrasyon, tampon yaşam döngüsü yönetimi (WebGPU tamponları yeniden boyutlandırılamaz), hâlâ kullanımda olan GPU kaynaklarını yok etmekten kaçınmak için fence yönetimi... Seri, "kademeli sağlamlaştırma" adını verdiğimiz şeye iki tam bölüm ayırıyor: her seferinde tek bir yetenek ekleyip her eklemeden sonra önceki katmanın hâlâ çalıştığını doğrulamaya dayanan gösterişsiz süreç.

Birleşim yeri kâbusu

Serinin teknik açıdan en çetin bölümü, farklı çözünürlüklerdeki arazi parçaları bir araya geldiğinde neler olduğunu ele alan 9. Bölüm'den 11. Bölüm'e kadar uzanıyor.

Yüksek ayrıntılı bir parça düşük ayrıntılı bir parçanın yanına geldiğinde, bağımsız olarak oluşturulan ağları sınırda hizalanmaz. Sonuç; görünür çatlaklar, titreyen kenarlar ve ışığın sızdığı T bağlantılarıdır. Transvoxel algoritması, çözünürlük farkları arasında köprü kuran özel geçiş hücreleriyle bu sorunu çözer. Ancak algoritmayı tüm parça yapılandırmalarında tutarlı sarım sırası, doğru tampon yönetimi ve isabetli çizim aralıklarıyla doğru şekilde uygulamak altı ayrı deney gerektirdi.

Ekibin en unutulmaz hata ayıklama hikâyesi şuydu: geçiş mantığından kaynaklandığını düşündüğümüz bir birleşim yeri kusurunun peşinde geçen iki gün. Asıl suçlu eski veriydi. GPU hesaplama shader'ı bir tampona N tepe noktası yazıyordu ancak çizim çağrısı hâlâ önceki kareden kalan N+M tepe noktasını oluşturacak şekilde yapılandırılmıştı. Bu fazladan tepe noktaları, titreşen ve jilet inceliğinde üçgenler üreten bozuk veriler içeriyordu. Tek satırlık çözüm: çizim aralığını atomik sayacın etkin tepe noktası sayısıyla sınırlandırmak.

Oleg, "Oluşturma hataları genellikle ağ oluşturma hatası kılığına girer," diye belirtiyor. "Geometri başından beri doğruydu."

Kaostan yönetişime

Birleşim yeri mücadelesinin ardından ekip, plansız parça davranışını açık bir politika sistemiyle değiştirdi. Artık merkezi bir işlev her parçanın LOD seviyesine, oluşturma moduna (yükseklik haritası veya marching cubes) ve hangi yüzlerde geçiş hücreleri gerektiğine karar veriyordu. Mesafe halkaları temel LOD'u belirliyordu. Komşuluk kısıtlaması, yan yana iki parçanın çözünürlük seviyeleri arasında birden fazla kademe fark olmamasını sağlıyordu. Düzenleme bit eşlemi ise üretici değişiklikleri içeren hacimsel parçaları, mesafeden bağımsız olarak marching-cubes modunda tutuyordu.

Renk kodlu hata ayıklama katmanları — yükseklik haritası parçaları için yeşil, marching cubes parçaları için mavi, geçiş yüzleri için turuncu — "şu sırtın yakınlarında bir yerde hata gördüm" ifadesini "hata kuzeybatıya bakan (142, 12, -67) konumunda görünüyor" ifadesine dönüştürdü.

Oleg, "Politika karmaşıklığı azaltmadı," diye yazıyor. "Karmaşıklığı düzenledi."

Tüm bunların ortaya çıkardığı sonuç

Son spike; clipmap halkalarını, parça başına gökyüzü sisini (her arazi parçasının yönündeki gerçek gökyüzü kutusu rengini örnekleyen) ve Three.js modül bağlantılarını birleşik bir gösterimde bir araya getirdi. Sonuç; yakın alanda hacimsel düzenlemeyi, orta alanda yükseklik haritası parçalarını ve uzak alanda clipmap halkalarını; modu, LOD'u ve geçişleri yöneten bir politika katmanı altında birleştiren bir arazi sistemi.

Seri, Oleg'in gelecekteki her projede tekrarlayacağını söylediği derslerle sona eriyor:

• Özellik geliştirmeden önce risk spike'larıyla başlayın. İçerik işlem hatlarına yatırım yapmadan önce "bunu gerçekten yapabilir miyiz?" sorularını ortadan kaldırın.
• Büyük entegrasyon adımlarından önce çalıştığı bilinen temel sürümleri sabitleyin. Temiz bir kontrol noktası oluşturmak için harcanan bir gün, daha sonra gerilemeleri ikili aramayla bulmak için harcanacak birkaç günü kurtarır.
• Uzun optimizasyon süreçlerinden önce politika ve gözlemlenebilirliği zorunlu kılın. Tetikleme kurallarına sahip adlandırılmış koşullar, gizemli hatalara her zaman üstün gelir.
• Ekran görüntülerinde değil, hareket hâlinde test edin. Ani geçişler, titremeler ve veri akışı takılmalarının tümü sabit karelerde gizlenir.
• Ortalama FPS'yi değil, özellik başına kare süresini ölçün. Ortalamalar, kullanıcıların gerçekten hissettiği sıçramaları gizler.
• Dağınık kısımları da yayımlayın. Yanlış yolları, hayalet avlarını, yanlış sistemi suçlayarak geçen iki günü... İnsanların gerçekten ders çıkarabileceği kısımlar bunlardır.

Bunun Cinevva'nın ötesinde taşıdığı önem

Seri, tek bir şirketin arazi işlem hattının ötesine geçen üç nedenle önem taşıyor.

Birincisi, WebGPU hesaplama shader'larının, WebAssembly fiziğinin ve uçta dağıtılan Durable Objects'in bir eşiği aştığını gösteriyor. Hacimsel araziye, gerçek zamanlı düzenlemeye ve akışlı LOD'a sahip çok oyunculu bir açık dünya, 2026'da bir tarayıcı sekmesinde mimari açıdan uygulanabilir durumda. Bu, iki yıl önce mümkün değildi.

İkincisi, spike yöntemi — her biri canlı ve ölçülebilir sonuçlarla tek bir riskli soruyu yanıtlayan küçük, odaklı deneyler — çalışmayabilecek bir şeyi denemeye girişen her ekip için bir şablon sunuyor. Taahhütte bulunmadan önce ölçme, entegrasyondan önce temel ölçümler oluşturma ve optimizasyondan önce uç durumları adlandırma disiplini, arazi sistemlerinin çok ötesinde geçerlidir.

Üçüncüsü, bu radikal şeffaflık başlı başına amaçtır. Çıkmaz yollar ve iki günlük hata ayıklama sapmaları dâhil olmak üzere 24 deneyin tamamının kaynak kodunu yayımlamak, bunu teknik bir blogdan daha fazlasına dönüştürüyor. Bu, okuyucuya müşteri değil meslektaş gibi davranan, herkese açık bir mühendislik defteri. Serinin tamamına, her teknik denemenin tarayıcıda canlı olarak çalıştığı seri rehberimizden ulaşabilirsiniz.

---

Bu makale ilk olarak Medium'da yayımlandı.