Çok Oyunculu İçerik Üretici Dünyaları için Tarayıcı Tabanlı 3D Açık Dünya Teknolojisi

İçerik üreticilerimizi paylaşımlı bir açık dünyaya taşımak istiyoruz. Bir lobiye değil. Bir galeriye değil. İnsanların keşfedebileceği, inşa edebileceği ve birbirlerinin eserleriyle tesadüfen karşılaşabileceği yaşayan bir 3D mekâna. Bir tarayıcı sekmesinde yüklenen ve içinde bulunmaya değer bir yer hissi veren bir şeye.

Bu zor bir problem. Skyrim ve The Witcher 3, dünyalarını oluşturmak için yüz milyonlarca dolar harcadı; üstelik hâlâ onlarca gigabaytlık disk alanına ve özel donanıma ihtiyaç duyuyorlar. Biz ise bir tarayıcı sekmesini, yüzlerce oyuncu arasında paylaşılan durumu ve içerik üreticilerinin gerçekten yeniden şekillendirebileceği bir dünyayı hedefliyoruz.

Bu rehber, teknoloji üzerine yaptığımız araştırmalarda öğrendiklerimizi belgeliyor. Bugün nelerin mümkün olduğunu, gelecekte nelerin geleceğini ve bizi bu hedefe hangi mimarinin ulaştırabileceğini ele alıyor.

Skyrim ve The Witcher'dan Neler Öğrenebiliriz?

Teknoloji seçmeden önce, en başarılı iki açık dünyanın gerçekte nasıl çalıştığını anlamak faydalıdır. Kullandıkları teknikler, şaşırtıcı ölçüde tarayıcı kısıtlamalarına uyarlanabilir.

Skyrim'in Hücre Sistemi

Skyrim'in açık dünyası, oyuncunun çevresindeki 5x5 hücrelik bir ızgarayı akışla yükler. Uzaktaki dağlar düşük çözünürlüklü taklit modellerdir. Bunu asla fark etmezsiniz.

Skyrim, dünyasını 57x37 dış mekân hücresinden oluşan bir ızgaraya böler; her hücre 4096x4096 oyun birimi (yaklaşık 59 metre) boyutundadır. Motor, herhangi bir anda oyuncunun çevresindeki 5x5 hücrelik bir ızgarayı yükler. Siz yürüdükçe arkada kalan kenardaki hücreler bellekten çıkarılırken öndeki kenardaki hücreler akışla yüklenir. İç mekânlar (zindanlar, binalar), kapı tetikleyicileri üzerinden yüklenen ayrı dünya alanlarıdır.

Bu yaklaşım, tarayıcı tabanlı bir dünyaya doğrudan uygulanabilir. Haritanın tamamını yüklemezsiniz. Oyuncunun çevresindeki bölgeyi yükler ve oyuncu hareket ettikçe parçaları değiştirirsiniz. Temel fikir şudur: Skyrim, uzaktaki arazinin tüm ayrıntılarını görmenize asla izin vermez. Bunun yerine çoklu çözünürlük yaklaşımını kullanır.

Skyrim'deki LOD (Ayrıntı Düzeyi) katmanları:

• 1-2 hücre içinde tam ayrıntı (oyuncunun yakın çevresi)
• Orta mesafede basitleştirilmiş mesh'ler (nesneler küçük geometrilerini kaybeder)
• Orta mesafenin ötesindeki ağaçlar ve kayalar için kameraya dönük taklit görseller
• Arazi LOD'u, uzaktaki manzara için önceden hazırlanmış düşük çözünürlüklü mesh'ler kullanır
• Nesne kaybolma mesafeleri her nesne için ayrı ayarlanır (önce çimler, en son binalar kaybolur)

Skyrim'in arazisi, hücre başına 32x32 köşeli parçalardan oluşan yükseklik haritası tabanlı bir sistem kullanır. Her parça, alfa haritalarıyla harmanlanan farklı dokulara sahip olabilir. Bunu depolamak ve render etmek düşük maliyetlidir. Tek bir hücrenin arazi verisi megabaytlarla değil, kilobaytlarla ölçülür.

Uygulayabileceklerimiz: Parça tabanlı akış, yükseklik haritası tabanlı arazi, agresif LOD, iç/dış mekân ayrımı ve uzaktaki arazinin geometrik olarak kusursuz olmak yerine yalnızca görsel açıdan ikna edici olması gerektiği fikri.

The Witcher 3'ün Akış Mimarisi

The Witcher 3'ün 136 km² büyüklüğündeki dünyası, içeriğe duyarlı akış kullanır. 200 metreden uzaktaki ağaçlar düz taklit görsellerdir. Binalar, araziden bağımsız olarak akışla yüklenir.

The Witcher 3'ün dünyası Skyrim'den daha büyüktür (tüm bölgeler toplamında yaklaşık 136 km²) ve daha gelişmiş bir akış sistemi kullanır. CD Projekt RED, dünyanın katı bir ızgara yerine akış sektörlerine bölündüğü özel bir motor (REDengine 3) geliştirdi.

Her sektör, içerik katmanlarından oluşan bir hiyerarşi barındırır:

• Arazi, 4 LOD seviyesine sahip parçalar hâlinde akışla yüklenir
• Bitki örtüsü, mesafeye dayalı ayıklamayla GPU örneklemesi kullanır
• Statik geometri (binalar, kayalar), araziden bağımsız olarak akışla yüklenir
• Oynanış nesneleri (NPC'ler, eşyalar, tetikleyiciler), görev durumuna ve yakınlığa göre yüklenir

Render sistemi, fizik tabanlı malzemelerle ertelenmiş gölgelendirme kullanır. Özellikle önemli olan numaralardan biri şudur: The Witcher 3, taklit görselleri yoğun biçimde kullanır. 200 metre uzaktaki bir ağaç, dalları ve yaprakları olan bir 3D model değildir. Her zaman kameraya dönük duran, dokulu ve düz bir dörtgendir. Motor bu taklit görselleri birden fazla açıdan önceden render eder ve kamera hareket ettikçe aralarında geçiş yapar. Yeterince uzakta oldukları için bunu asla fark etmezsiniz.

Dünya kompozisyonu: The Witcher 3'ün açık dünyası, eş zamanlı çalışan farklı ekipler tarafından katmanlar hâlinde oluşturuldu. Arazi ekibi manzarayı şekillendirdi. Çevre sanat ekibi yapıları yerleştirdi. Görev ekibi tetikleyicileri ve NPC rotalarını bağladı. Bu katmanlı kompozisyon sistemi, büyük bir ekibin birbirinin çalışmasını bozmadan çalışabilmesini sağladı.

Uygulayabileceklerimiz: Katmanlı dünya kompozisyonu (bir içerik üretici platformu için kritik öneme sahiptir), uzaktaki nesneler için taklit görsel render'ı, çok sayıda ışık kaynağı için ertelenmiş render ve akışın içeriğe duyarlı olması gerektiği fikri (göremediğiniz iç mekânları yüklemeyin, yakınında olmadığınız NPC'leri oluşturmayın).

Breath of the Wild'ın Kimya Motoru

BotW, tablet sınıfı donanımda çalışmasına rağmen çarpıcı görünüyor. Hücre gölgelendirmeli stil, suluboya görünümlü uzaklık sisi ve betikli içerik yerine sistemsel etkileşimler. Stilize açık dünyalar için altın standart.

Nintendo'nun açık dünya tasarımına yaklaşımı, alışılmış formülü tersine çevirdi. Dünyayı betikli içeriklerle doldurmak yerine sistemsel kurallar oluşturdular ve oyuncuların beklenmedik davranışları keşfetmesine izin verdiler. Ateş çimlere yayılır. Metal, gök gürültülü fırtınalarda elektriği iletir. Rüzgâr nesneleri taşır. Her şey, tutarlı bir fizik/kimya katmanı aracılığıyla diğer her şeyle etkileşime girer.

Bu, bir içerik üretici dünyası için önemlidir; çünkü dünyanın kendisinin, yerleştirilen herhangi bir nesneden daha ilgi çekici olabileceğini gösterir. İçerik üreticileri yalnızca statik mesh'ler yerleştirmekle kalmayıp malzeme özelliklerini ve etkileşim kurallarını da tanımlayabilirse dünya, kimsenin özel olarak tasarlamadığı bölgelerde bile keşfi değerli kılan beklenmedik davranışlar kazanır.

BotW'dan teknik çıkarımlar:

• Nispeten düşük poligon sayısı ve çözünürlük (Switch, dock'a bağlıyken 900p). Stilize hücre gölgelendirmeli görünüm, düşük görsel ayrıntıyı gizler. Tarayıcı tabanlı bir dünya bugün benzer bir görsel kaliteye ulaşabilir.
• Uzaklık render'ı, suluboya tarzı gökyüzü kutularına karışan toon gölgelendirmeli bir sis kullanır. Render maliyeti düşüktür ve pratikte güzel görünür. Bu tür atmosferik perspektif, bir fragment shader'da neredeyse ücretsizdir.
• Dünya yaklaşık 84 km² büyüklüğündedir ancak seyrektir. Haritanın büyük bölümü, üzerine ilgi çekici noktalar serpiştirilmiş geçilebilir araziden oluşur. Yoğun içerik kasabalara ve mabetlere ayrılmıştır. Bu "seyrek ama ilgi çekici" yaklaşım, The Witcher 3'ün yoğun nüfuslu Novigrad'ına kıyasla varlık gereksinimlerini büyük ölçüde azaltır.
• Fizik nesneleri, etkileşimleri belirleyen malzeme etiketlerine (ahşap, metal, yiyecek, patlayıcı) sahiptir. Gerçek kuralların sayısı azdır (belki 20-30 etkileşim türü), ancak sonsuzmuş gibi hissettiren biçimlerde birleşirler.

GTA V'in Dünya Katmanları

GTA V'in Los Santos'u katmanlı ortam sistemleri sayesinde canlı hissettirir: trafik, yayalar, günün saati ve hava durumu. Uzaktaki binalar 3D modeller değil, birleştirilmiş fotoğraflardır.

Rockstar'ın Los Santos yaklaşımı farklı bir ders veriyor. GTA V'in dünyası, her NPC'nin bir görevi olduğu için değil, katmanlı ortam sistemleri sayesinde canlı hissettirir.

Şehir, bir yol ağı üzerindeki yüzlerce aracı simüle eden trafik sistemlerine sahiptir. Yayalar rotalarda yürür, oyuncuya tepki verir ve birbirleriyle etkileşime girer. Günün saati nüfus yoğunluğunu, mevcut NPC türlerini ve ortam etkinliklerini değiştirir. Hava durumu, sürüş fiziğini ve NPC davranışlarını etkiler.

Bir içerik üretici dünyası açısından çıkarım şudur: Ortam yaşamı, müze gibi hissettiren bir dünya ile gerçek bir yer gibi hissettiren dünya arasındaki farkı yaratır. Basit davranışlar bile (tepede uçan kuşlar, kıyıya vuran dalgalar, binalar arasında yürüyen NPC'ler) yaşayan bir dünya yanılsaması oluşturur.

GTA V'ten teknik çıkarımlar:

• Harita 75 km² büyüklüğündedir ve hıza göre yükleme yapan bir akış sistemiyle birlikte agresif LOD kullanır (hızlı araç kullanırken, yürümeye kıyasla ilerideki daha uzak alanlar yüklenir).
• GTA Online, bu dünyada aynı anda 30 oyuncuyu barındırır. Rockstar, 30 oyuncuda bile mekânsal ilgi yönetimine ihtiyaç duyduğunu gördü: Yakındaki oyuncular hakkında ayrıntılı, uzaktaki oyuncular hakkında ise daha seyrek güncellemeler alırsınız. Aynı ilke, 200 oyunculuk hedefimiz için de geçerlidir.
• GTA V'in varlık üretim hattı, bugüne kadar oluşturulmuş en verimli sistemlerden biridir. Aşırı doku sıkıştırma, mesh paylaşımı ve prosedürel ayrıntılar sayesinde oyunun tamamı yaklaşık 80 GB'a sığar. Bina iç mekânlarında modüler parçalar yoğun biçimde yeniden kullanılır.
• Oyun, uzaktaki binaların aslında bir araya getirilmiş düz fotoğraflar olduğu gelişmiş bir taklit model sistemi kullanır. Geçiş mesafeleri belirli görüş açılarına göre ayarlandığından oyuncu bunu asla fark etmez.

Elden Ring'in Kesintisiz Açık Dünyası

Elden Ring'in 79 km² büyüklüğündeki haritası, seyrek açık arazileri yoğun ve elle hazırlanmış zindanlarla birleştirir. Aynı çevre varlıkları, farklı düzenlemelerle her yerde kullanılır. Kompozisyon ve ışıklandırma değiştiğinde tekrarlar görünmez olur.

FromSoftware, Elden Ring'i Dark Souls ile aynı motor üzerinde geliştirdi ancak bu motoru açık dünya ölçeğine taşıdı. Ortaya çıkan sonuç ilgi çekicidir; çünkü Rockstar veya CD Projekt'e kıyasla görece küçük bir ekibin nasıl büyük bir açık dünya oluşturabileceğini gösterir.

İşin sırrı yoğunluk çeşitliliğidir. Elden Ring'in haritası çok büyüktür (yaklaşık 79 km²), ancak geniş bölümleri dağınık düşmanlar ve ilgi çekici noktalar içeren açık arazilerden oluşur. Yoğun, elle hazırlanmış içerikler (Stormveil Castle gibi Legacy Dungeon'lar), açık dünyanın içine gömülüdür ve Skyrim'dekiyle aynı iç/dış mekân ayrımını kullanır.

Elden Ring'den teknik çıkarımlar:

• Dünya, büyük karolar hâlinde akışla yüklenir. At sırtındayken çok uzağı görebilirsiniz, ancak uzaktaki arazi son derece basitleştirilmiştir. Yakından bakıldığında ayrıntı seviyesi Dark Souls 3 ile karşılaştırılabilir.
• Yükleme ekranları yalnızca hızlı seyahat sırasında veya belirli zindanlara girerken görünür. Açık dünyanın kendisi kesinti olmadan akışla yüklenir.
• Oyun, çevre varlıklarını yoğun biçimde yeniden kullanır. Aynı ağaç modelleri, kaya oluşumları ve harabe parçaları harita boyunca farklı düzenlemelerle karşınıza çıkar. Düzenleme ve ışıklandırma yeterince çeşitliyse tekrarlar fark edilmez. Bu, modüler parçalardan oluşan bir kütüphanenin sonsuz çeşitlilik üretebildiği içerik üretici dünyasına doğrudan uygulanabilir.
• Çok oyunculu sistem kalıcı değil, oturum tabanlıdır (diğer oyuncuları kendi dünyanıza çağırırsınız). Ancak eşzamansız özellikler (mesajlar, kan lekeleri, diğer oyuncuların hayaletleri), kalıcı bir sunucunun ağ yükü olmadan ortak bir dünyada var olma hissi yaratır. Bu ortam çok oyunculu özellikleri, tarayıcı tabanlı bir dünyaya düşük maliyetle eklenebilir.

No Man's Sky: Her Şey Prosedürel

Paylaşılan seed'lerden üretilen 18 kentilyon gezegen. Her oyuncu, evren sunucuda depolanmadan aynı evreni görür. Üs inşa verileri kompakttır: parça kimlikleri ve dönüşümler.

No Man's Sky, prosedürel üretimin uç örneğidir. Paylaşılan bir seed'den 18 kentilyon gezegen üretilir; böylece her oyuncu, hiçbir veri sunucuda depolanmadan aynı evreni görür.

Üretim hattı aşamalar hâlinde çalışır: Galaksi düzeyindeki seed'ler yıldız konumlarını, yıldız seed'leri gezegenlerin sayısını ve türlerini, gezegen seed'leri ise arazi üretimini (çok oktavlı gürültü), biyom atamasını, flora/fauna türlerini, renk paletlerini ve kaynak dağılımını belirler. Her şey seed'den deterministik biçimde hesaplandığı için aynı koordinatları ziyaret eden iki oyuncu, herhangi bir gezegen verisi alışverişinde bulunmadan aynı gezegeni görür. No Man's Sky'dan teknik çıkarımlar:

• Arazi üretimi, bir dizi gürültü fonksiyonuyla birlikte voksel tabanlı marching cubes yöntemini kullanır. Bu sayede yükseklik haritası tabanlı arazilerin temsil edemediği mağaralar, çıkıntılar ve yüzen adalar oluşturulabilir. Bunun karşılığında parça başına hesaplama maliyeti daha yüksektir, ancak sonuç görsel açıdan daha ilgi çekici bir arazidir.
• Üs inşa sistemi, tasarladığımız yapıya en yakın örnektir. Oyuncular sunucuda kalıcı olan ve diğer oyuncular tarafından görülebilen yapılar yerleştirir. Üs verileri kompakttır (konumları ve dönüşleriyle birlikte parçaların bir listesi) ve birisi gezegeni ziyaret ettiğinde isteğe bağlı olarak aktarılır.
• Oyun, sonsuz çeşitliliğine rağmen başlangıçta tekrarlayan içerikleri nedeniyle eleştirildi. Seed tabanlı üretim sonsuz arazi oluşturabilir, ancak sunduğu sürprizler sınırlıdır. Çıkarılacak ders şu: prosedürel üretim tuvali oluşturmak için işe yarar, ancak bir mekânın tasarlanmış ve amaca yönelik hissettirilmesini sağlayan şey, içerik üreticilerinin yerleştirdiği içeriktir.
• Hello Games, çok oyunculu modu çıkıştan yıllar sonra ekledi. En fazla 32 oyuncu, tam kapsamlı inşa ve keşif özellikleriyle aynı oturumu paylaşır. Ağ modeli basittir: bir oyuncu barındırır, diğerleri bağlanır. Kalıcı duruma sahip bir tarayıcı dünyası için sunucu otoriteli bir model daha iyi çalışır, ancak No Man's Sky paylaşımlı prosedürel dünyaların uygulanabilir olduğunu kanıtlıyor.

Minecraft: İçerik Üreticisi Dünyalarının Planı

300 milyon kopya satıldı. 16x16 piksel dokular. Tamamen düzenlenebilir arazi. Sonsuz üretim. Çok oyunculu. Bir içerik üreticisi dünyası için en önemli referans. Tarayıcı klonları, konseptin WebGL'de çalıştığını kanıtlıyor.

Minecraft, herhangi bir yüksek bütçeli AAA oyundan daha fazla, inşa ettiğimiz şey için en önemli referans noktasıdır. 300 milyon kopya satıldı. Dünya sonsuz üretilir, tamamen yok edilebilir ve çok oyunculudur. İçerik üreticileri Minecraft'ta yalnızca nesne yerleştirmez. Arazinin kendisini yeniden şekillendirirler.

Minecraft'tan teknik çıkarımlar:

• Dünya, 16x16x384 blokluk parçalara ayrılır. Yalnızca oyuncunun yakınındaki parçalar yüklenir (görüş mesafesi yapılandırılabilir). Bu, Skyrim'dekiyle aynı parça aktarımı düzenidir, ancak arazi tamamen düzenlenebilir.
• Her parça, paletle sıkıştırılmış bir blok kimliği dizisi olarak saklanır. Yalnızca 5 farklı blok türü içeren bir parça, tam blok kimliği yerine blok başına 4 bitlik bir palet indeksi saklar. Bu, parça verilerini oldukça kompakt hâle getirir (sıkıştırmadan sonra parça başına genellikle 10-50 KB).
• Minecraft'ın çok oyunculu protokolü iyi belgelenmiştir ve görece basittir. Oyuncu hareket ettikçe sunucu parça verilerini gönderir. Blok değişiklikleri küçük fark güncellemeleri (konum + yeni blok türü) olarak yayınlanır. İçerik üreticisi düzenlemeleri için kullanacağımız model tam olarak budur.
• Oyun Java ile çalışır ve artık C++ ile geliştirilmiş bir Bedrock Edition sürümüne de sahiptir. Tarayıcı tabanlı Minecraft klonları (ClassiCube, eaglercraft), temel konseptin WebGL'de çalıştığını kanıtlıyor. Bunlar genellikle 60 fps'de 8-12 parçalık görüş mesafesini işleyerek yaklaşık 200-400 metrelik bir görüş alanı sağlar.
• Minecraft'ın asıl rekabet avantajı modlama ekosistemidir. Modlar yeni bloklar, varlıklar, biyomlar ve oynanış sistemleri ekler. Bir içerik üreticisi dünyası açısından bu, genişletilebilirliğin temel deneyim kadar önemli olduğunu gösterir. İçerik üreticileri yalnızca nesne yerleştirmekle kalmayıp yeni etkileşim türleri tanımlayabilirse dünya zamanla daha da zenginleşir.
• Redstone (Minecraft'ın oyun içi kablolama sistemi), içerik üreticilerine basit ve birleştirilebilir temel bileşenler verdiğinizde karmaşık sistemler inşa edeceklerini gösterir. Mantık kapıları, otomatik çiftlikler, hesap makineleri. Basit kurallar olağanüstü bir karmaşıklık doğurur. Bu, BotW'nin kimya motorundan çıkarılan dersle aynıdır.

AAA Açık Dünyalardaki Ortak Kalıplar

Tüm bu oyunlara birlikte bakıldığında aynı kalıpların tekrar tekrar ortaya çıktığı görülür:

Mekânsal bölümleme evrenseldir. Hücreler (Bethesda), sektörler (CD Projekt), parçalar (Mojang/Rockstar) veya döşemeler (FromSoftware) kullanılsa da her açık dünya, alanı yüklenebilir birimlere ayırır. Hiçbir motor tüm dünyayı bellekte tutmaya çalışmaz.

Her şey çoklu çözünürlüklüdür. Arazi, mesh'ler, dokular ve hatta sesler birden fazla kalite seviyesine sahiptir. Elde ettiğiniz çözünürlük, ne kadar yakında olduğunuza ve nesnenin ne kadar önemli olduğuna bağlıdır.

Örtülme ayıklaması, ham üçgen işleme kapasitesinden daha önemlidir. Göremediğiniz şeyleri çizmemek, görebildiklerinizi optimize etmekten daha fazla performans kazandırır. Skyrim basit, mesafe tabanlı bir sistem kullanır. The Witcher 3 büyük örtücülerle (binalar, kayalıklar) yazılım tabanlı örtülme kullanır. UE5'in Nanite'ı gibi modern motorlar, donanım örtülme sorgularıyla bunu daha ileri taşır.

Eşzamansız yükleme geçişleri gizler. Bu oyunlar açık dünya için yükleme ekranları göstermez (yalnızca hızlı seyahat veya iç mekân geçişlerinde gösterir). İçerikleri arka plan iş parçacıklarında yükler, paralel olarak açar ve yeni içerikleri kademeli biçimde devreye alırlar.

Poligon sayısı yerine sanat yönetimi. Skyrim, 2011'de o dönem için bile mütevazı sayılabilecek grafiklerle çıktı. BotW, tablet sınıfı bir çipte çalışır ve güzel görünür. Minecraft 16x16 piksel dokular kullanır ve şimdiye kadar yapılmış görsel açıdan en tanınabilir oyunlardan biridir. Bu, bir tarayıcı dünyası için son derece önemlidir. Daha düşük görsel ayrıntı düzeyine sahip, sanat yönetimi güçlü bir tarz; teknik açıdan gelişmiş ancak sanatsal açıdan yavan bir dünyayı her zaman geride bırakır.

Sistemik tasarım, betiklenmiş içerikten üstündür. BotW'nin kimya motoru, Minecraft'ın blok etkileşimleri ve GTA V'in trafik sistemleri, basit kurallardan doğan davranışlar üretir. Bunların geliştirilmesi ve çalıştırılması daha ucuzdur ve elle hazırlanmış betiklenmiş sekanslardan daha fazla oyuncu hikâyesi doğururlar. Bir içerik üreticisi dünyasında sistemik tasarım, hiç kimsenin açıkça tasarlamadığı alanlarda bile dünyanın ilgi çekici kalması anlamına gelir.

İçerik üreticilerinin yerleştirdiği içerikler kalıcı ve görünür olmalıdır. Minecraft üsleri, No Man's Sky üsleri ve GTA Online mülkleri oturumlar arasında kalıcıdır ve diğer oyuncular tarafından görülebilir. İçerik üreticisi içeriklerinin veri modeli her zaman kompakttır (parça kimlikleri + dönüşümler), ancak görsel temsili zengindir (istemci, verileri eksiksiz 3D sahnelere dönüştürür).

Görselleştirme: Bir Tarayıcı Gerçekte Neler Yapabilir?

Three.js

Three.js temel katmandır. En büyük topluluğa (100 binden fazla GitHub yıldızı), en fazla örneğe ve en geniş uyumluluğa sahiptir. WebGL 2'yi soyutlar ve WebGPURenderer aracılığıyla deneysel WebGPU desteği sunar.

Three.js, açık bir dünya için şunları sağlar:

• Bitki örtüsü, kayalar ve tekrarlanan geometriler için örneklemeli görselleştirme (InstancedMesh)
• Yerleşik LOD sistemi (THREE.LOD, mesh'leri mesafeye göre değiştirir)
• Nesne başına otomatik görüş hacmi ayıklaması
• Özel BufferGeometry veya yükseklik haritası tabanlı PlaneGeometry aracılığıyla arazi
• MeshStandardMaterial ve MeshPhysicalMaterial aracılığıyla PBR materyalleri
• EffectComposer aracılığıyla son işleme (parlama, SSAO, ton eşleme)
• Özel kodla kademeli gölge eşleme uygulanabilen gölge haritaları
• Birincil varlık biçimi olarak glTF/GLB (kompakt, GPU'ya hazır)

Three.js ayrıca açık dünyalar için önemli olan etkin bir araç ekosistemine sahiptir. three-mesh-bvh, karmaşık mesh'lerde ışın izleme ve mekânsal sorguları hızlandırır. postprocessing (vanruesc tarafından), Three'ün yerleşik çözümünden daha yüksek performanslı bir son işleme yığını sunar. three-gpu-pathtracing, referans kalitesinde görselleştirmeyi mümkün kılar.

Açık dünyalar için sınırlamalar: Three.js; büyük ölçekte aktarım, LOD yönetimi veya mekânsal bölümlemeyi yöneten yerleşik bir sahne grafiğine sahip değildir. Bunları kendiniz oluşturursunuz. Yerleşik varlık-bileşen sistemi (ECS), fizik veya arazi sistemi yoktur. Bir motor değil, görselleştiricidir. Bellek düzenini ve yükleme stratejisini kontrol edebildiğiniz için bu aslında özel bir açık dünya açısından avantajdır, ancak başlangıçta daha fazla çalışma gerektirir.

const lod = new THREE.LOD();
lod.addLevel(highDetailMesh, 0);
lod.addLevel(mediumDetailMesh, 50);
lod.addLevel(lowDetailMesh, 200);
lod.addLevel(impostorSprite, 500);
scene.add(lod);

Babylon.js

Babylon.js diğer büyük adaydır. Microsoft destekli bu çözüm, açık dünyalara özgü sorunlar için Three.js'ten daha kapsamlı yerleşik özelliklere sahiptir.

İlgili yerleşik özellikler:

• Büyük sahnelerin verimli biçimde ayıklanması için octree tabanlı sahne bölümleme
• Çok büyük ölçekli örneklemeli görselleştirme için Solid Particle System
• Yerleşik LOD ve çoklu doku harmanlama özelliğine sahip yükseklik haritası tabanlı arazi
• Görsel shader oluşturma için Node Material Editor
• WebGPU desteği (Babylon bu alana daha erken yatırım yaptığı için Three.js'ten daha olgun)
• Havok fizik entegrasyonu (Wasm ile derlenmiş, üretim kalitesinde)
• Aşamalı yüklemeyle glTF aktarımı

Babylon'ın DynamicTerrain uzantısı, yükseklik haritası verilerinden anında arazi parçaları üretir, LOD'yi otomatik olarak yönetir ve doku harmanlamayı destekler. Bu, Three.js'in kutudan çıktığı hâliyle sunduğu her şeyden çok Skyrim'in yaptıklarına yakındır.

const terrain = new BABYLON.DynamicTerrain("terrain", {
  terrainSub: 100,
  mapData: heightmapData,
  mapSubX: 1000,
  mapSubZ: 1000,
}, scene);
terrain.LODLimits = [4, 3, 2, 1];

Dezavantajı: Babylon.js daha büyük bir kütüphanedir (tam sürüm küçültülmüş hâliyle yaklaşık 1-2 MB, Three.js ise yaklaşık 600 KB). Ancak açık bir dünya için Three.js'e muhtemelen yeterince özel kod ekleyeceğinizden boyut farkı önemsiz hâle gelir. Babylon ayrıca iterasyonu hızlandıran kendi Node Material sistemine, denetçisine ve geliştirici araçlarına sahiptir.

Babylon.js 8.0 (Mart 2025'te yayınlandı), burada motor çekirdeği olarak kullanılmasını daha da güçlü bir seçenek hâline getirdi. Artık tüm çekirdek motor shader'ları hem GLSL hem de WGSL biçiminde sunuluyor; böylece WebGPU herhangi bir dönüştürme katmanı olmadan çalışıyor ve WebGPU paketi eskisinin yaklaşık yarısı boyutunda. Aynı sürüm Havok'un eksiksiz karakter denetleyicisini, alan ışıklarını, yeniden oluşturulmuş bir ses motorunu ve Gaussian splatting iyileştirmelerini (SPZ ve sıkıştırılmış PLY biçimleri, küresel harmonikler ve daha düşük bellek/CPU kullanımı) motora ekledi.

PlayCanvas

PlayCanvas'tan söz etmeye değer çünkü üretim ortamında kendini en çok kanıtlamış, önceliği web olan 3D motordur. Snap, Facebook ve çok sayıda reklam müşterisi bununla karmaşık 3D deneyimler yayınladı. Motor yaklaşık 1 MB'tır, hızlı yüklenir ve bulut düzenleyicisi ortaklaşa dünya oluşturmayı mümkün kılar.

PlayCanvas, özellikle açık dünyalar için çizim çağrısı optimizasyonunda kullanılan toplu gruplar, yerleşik bir ışık haritası oluşturucusu ve Gaussian splatting desteği (fotogrametriyle yakalanmış gerçek dünya ortamları için önemlidir) sunar. Çalışma zamanı hafiftir ve mobil tarayıcılar için iyi optimize edilmiştir.

WebGPU: Performansın Kilidini Açmak

WebGPU, tarayıcı tabanlı açık dünyalar için denklemi değiştirir. En önemli iki özellik şunlardır:

Hesaplama shader'ları, GPU tarafında arazi üretimini, bitki örtüsü yerleşimini, parçacık simülasyonunu ve hatta basit fizik hesaplamalarını mümkün kılar. WebGL tabanlı bir dünyada bunların tamamı JavaScript aracılığıyla CPU üzerinde çalışır. WebGPU ile arazi parçalarını tamamen GPU üzerinde üretebilir, LOD geçişlerini GPU üzerinde hesaplayabilir ve ayıklama geçişlerini GPU üzerinde çalıştırabilirsiniz. Bu, CPU'yu ağ iletişimi, oyun mantığı ve içerik aktarımı için serbest bırakır.

Dolaylı görselleştirme, GPU'nun hesaplama shader'ı çıktısına göre neyin çizileceğine karar vermesini sağlar. Tek bir çizim çağrısı gönderirsiniz ve GPU, mesafeye göre her LOD seviyesinde kaç örneğin çizileceğine karar verir. Modern motorlar milyonlarca çim yaprağını veya ağacı bu şekilde işler. Dolaylı görselleştirme olmadan (WebGL bunu desteklemez) CPU'nun her şeyi sıralaması ve gruplaması gerekir; yoğun sahnelerde darboğaz da bu olur.

WebGPU artık tüm büyük tarayıcılarda sunuluyor. Chrome ve Edge bunu 113. sürümden beri destekliyor; Firefox Windows'ta (141) ve Apple Silicon macOS'te (145) destek ekledi, Safari 26 ise 2025'in sonlarında macOS, iOS, iPadOS ve visionOS'e getirdi. Böylece mobil dâhil küresel destek yaklaşık %82'ye ulaştı (Android için Chrome ve Samsung Internet de destekliyor). WebGPU'nun etkinleştirilmediği eski tarayıcılar ve cihazlar için yine WebGL 2 geri dönüş seçeneği bulundurmanız gerekir, ancak aradaki fark hızla kapandı.

@compute @workgroup_size(64)
fn generateTerrain(@builtin(global_invocation_id) id: vec3<u32>) {
    let worldPos = vec2<f32>(f32(id.x), f32(id.y)) * cellSize + worldOffset;
    let height = fbmNoise(worldPos, octaves, persistence);
    heightmap[id.x + id.y * width] = height;
}

Önerilen Görselleştirme Yığını

Masaüstündeki içerik üreticilerini hedefleyen tarayıcı tabanlı bir açık dünya için:

Birincil: Kullanılabildiği yerlerde WebGPU görselleştiricisi, geri dönüş seçeneği olarak WebGL 2 ile Three.js veya Babylon.js. Babylon daha güçlü yerleşik açık dünya temel bileşenlerine sahiptir. Three.js ise daha büyük bir topluluk ve daha fazla esneklik sunar.

Tercihimiz: Yerleşik arazi LOD'si, octree ayıklaması, Havok fiziği (Wasm) ve olgun WebGPU desteği nedeniyle motor çekirdeği olarak Babylon.js. Babylon'ın eksik kaldığı yerlerde Three.js ekosistemindeki araçları kullanın (örneğin mekânsal sorgular için mesh BVH). Her şeyi özel bir dünya aktarım katmanıyla sarmalayın.

Dünya Aktarım Mimarisi

Zor kısım budur. Bir tarayıcı sekmesi masaüstünde yaklaşık 2-4 GB (tarayıcı tarafından uygulanan sınırlar), mobilde ise yaklaşık 1 GB bellek kullanabilir ve diske doğrudan erişemez. Her şey ağ üzerinden gelir. Oyuncunun hareket ettiği yönün biraz ilerisindeki içerikleri aktarırken görünür dünyayı bellekte tutan bir mimariye ihtiyacınız vardır.

Parça Tabanlı Dünya Izgarası

Skyrim'in hücre sisteminde olduğu gibi dünyayı düzenli bir parça ızgarasına bölün. Her parça, ayrı olarak yüklenebilen, görselleştirilebilen ve bellekten çıkarılabilen bağımsız bir birimdir.

Parça boyutlandırması önemlidir. Çok küçük olursa yüksek ek yükle sürekli yükleme ve bellekten çıkarma yaparsınız. Çok büyük olursa her parçanın indirilmesi fazla uzun sürer. Tipik geniş bant bağlantılarına sahip bir tarayıcı dünyası için:

• Zemin seviyesinde 64x64 metrelik parçalar
• Her parça şunları içerir: yükseklik haritası bölümü (2-4 KB), doku harmanlama haritası (sıkıştırılmış olarak 16-32 KB), örneklenmiş referanslar olarak statik mesh'ler (1-50 KB örnek verisi), manifest olarak içerik üreticilerinin yerleştirdiği nesneler (1-10 KB)
• Yükleme yarıçapı: tam ayrıntıda 5x5 parça (320 m görüş), orta LOD'de 9x9, yalnızca arazi için 17x17
• Hedef: Her parçanın tam ayrıntılı verisi 200 KB'ın altında olmalı; böylece 5x5'lik bir çevre 5 MB'ın altında kalır

Aşamalı Yükleme Hattı

Bir parçayla ilgili her şeyi aynı anda yüklemeyin. Bir öncelik kuyruğu kullanın:

1. Önce arazi geometrisi (yalnızca yükseklik haritası, parça başına 2-4 KB). Oyuncu zemini 100 ms içinde görür.
2. Arazi dokuları (splat haritaları; önce düşük çözünürlük, ardından yükseltme). Zemin 200 ms içinde renklenir.
3. Büyük yapılar (binalar, büyük kayalar). Silüetler 500 ms içinde görünür.
4. Detay nesneleri (bitki örtüsü, küçük dekoratif nesneler, üretici öğeleri). Dünya 1-2 saniye içinde dolmaya başlar.
5. Yüksek çözünürlüklü dokular en son yükseltilir. Uzaktaki bir binanın dokusunun yüklenmesi bir saniye daha uzun sürse kimse fark etmez.

Bu, insan gözünün çalışma biçimiyle uyumludur. Zeminin veya büyük yapıların eksikliğini fark ederiz. Çimlerin eksikliğini fark etmeyiz.

Bellek Yönetimi

Tarayıcı belleği sınırlıdır ve çöp toplayıcı düşmanınızdır. Tek bir GC duraklaması bile bir kareliğine 60 fps'den 10 fps'ye düşmenize neden olabilir.

Nesne havuzlama zorunludur. Yaygın nesneler (ağaçlar, kayalar, çim kümeleri) için önceden havuzlar ayırın ve parçalar yüklenip kaldırıldıkça bunları yeniden kullanın. Yoğun çalışan kod yolunda asla yeni THREE.Mesh veya BABYLON.Mesh örnekleri oluşturmayın. Bunun yerine havuzlanmış nesnelerin geometri ve malzeme referanslarını değiştirin.

Doku atlasları hem çizim çağrılarını hem de bellek parçalanmasını azaltır. Tüm arazi dokularını birkaç büyük atlasta birleştirin. Üreticilerin yüklediği dokuları sunucuda parça başına atlaslar hâlinde paketleyin ve tekil görseller olarak aktarın.

Draco veya Meshopt ile geometri sıkıştırması, indirme boyutunu 5-10 kat azaltır ve açma işlemi bir Web Worker üzerinde çalıştığı için ana iş parçacığını engellemez. Özellikle arazi için nicemlenmiş yükseklik haritaları (basit delta kodlamasıyla sıkıştırılmış 16 bit değerler), genel amaçlı tüm ağ biçimlerinden daha küçüktür.

Worker'lar ile ana iş parçacığı arasında ArrayBuffer sahipliğinin aktarılması, kopyalama işlemini önler. Bir worker bir ağı açtığında, aktarılabilir nesnelerle birlikte postMessage kullanarak tamponu sıfır kopyalamayla ana iş parçacığına aktarın.

Varlık Dağıtımı

Sabit dünya verileri için uç önbelleklemeli CDN kullanın. Sık değişmeyen arazi parçaları, temel ağlar ve doku atlasları yoğun biçimde önbelleğe alınmalıdır (Cache-Control: max-age=31536000, immutable).

İçerik adresli depolama, her varlık sürümünün URL'sinde benzersiz bir karma değeri alması anlamına gelir. Bir üretici bir parçayı değiştirdiğinde yeni sürüm yeni bir karma değeri alır; eski sürüm ise hâlâ ona bakan herkes için önbellekte kalır. Önbellek geçersiz kılmaya gerek kalmaz.

Basis Universal sıkıştırmalı KTX2 dokuları kullanın. Bunlar, cihazın desteklediği GPU biçimine açılır (BC7, ASTC, ETC2 veya yedek olarak RGBA). 1024x1024 boyutundaki bir arazi dokusu, sıkıştırılmamış 4 MB'den KTX2 ile yaklaşık 150 KB'ye düşer. Binlerce benzersiz dokuya sahip bir dünya için bu sıkıştırma, projenin uygulanabilir olup olmaması arasındaki farktır.

Tüm 3D varlıklar için glTF Binary (GLB) kullanın. Bu, 3D'nin JPEG'idir. Her tarayıcı motoru bunu yükleyebilir, biçim kompakttır ve dokuları, malzemeleri ve animasyonları tek dosyada barındırabilir. Ağ sıkıştırması için Draco veya Meshopt uzantılarını kullanın. Üreticilerin yüklediği varlıklar, dünyaya girmeden önce sunucu tarafında işlenerek optimize edilmiş GLB'lere dönüştürülür.

Çok Oyunculu Ağ İletişimi

Yüzlerce üreticiyi aynı dünyaya yerleştirmek; gerçek zamanlı hareketi, kalıcı dünya durumunu ve üretici düzenlemelerini sistemi çökertmeden işleyebilen bir ağ mimarisi gerektirir.

Sunucu Mimarisi

Dünya durumu için yetkili sunucu kullanın. Tarayıcı güvenilir değildir. Anlamlı tüm eylemler (nesne yerleştirme, araziyi değiştirme, parçalar arasında hareket etme) sunucu tarafında doğrulanır. İstemci yerel tahminde bulunur ve sunucu durumuyla uzlaştırma yapar.

Mekânsal parçalama, dünyayı sunucu örnekleri arasında böler. Her parça, dünya ızgarasının dikdörtgen bir bölgesine sahip olur. Oyuncu yoğunluğu değiştikçe parçalar bölünebilir veya birleştirilebilir. EVE Online binlerce oyuncuyu tek bir evrende bu şekilde barındırır ve aynı ilke daha küçük ölçekte de geçerlidir.

Çoğu etkileşimin yerel olduğu bir üretici dünyasında (siz kendi bölgenizde inşa ederken komşularınız bunu görebilir) mekânsal parçalama doğal biçimde çalışır. Bir parça sınırında duran oyuncu her iki parçanın içeriğini de görür; bu da parçalar arası görünürlük sorguları gerektirir, ancak bu çözülmüş bir problemdir.

Sunucu için teknoloji seçenekleri:

Teknoloji	Güçlü Yönleri	Kullanım Alanı
Cloudflare Durable Objects	Uçta dağıtım, otomatik ölçeklendirme, yerleşik kalıcılık, WebSocket desteği	Dünya parçası durumu, parça başına yetki
Hathora / Rivet	Yönetilen oyun sunucusu barındırma, DDoS koruması, küresel dağıtım	Özel oyun sunucusu örnekleri
Colyseus	Node.js için açık kaynaklı oyun sunucusu çatısı, şema tabanlı durum eşitleme	Durum farkı hesaplamalı, oda tabanlı çok oyunculu deneyimler
PartyKit	Uçta dağıtım, WebSocket + WebRTC, Cloudflare Workers tabanlı	Gerçek zamanlı iş birliği, hafif çok oyunculu deneyimler
Özel Rust/Go çözümü	Azami kontrol, örnek başına en iyi performans	Düşük gecikmeli fizik gerektiren yüksek yoğunluklu parçalar

Bizim bağlamımızda (Cloudflare altyapısı): Durable Objects doğal bir seçimdir. Her dünya parçası, o parçanın içeriğine ait yetkili durumu tutan bir Durable Object olur. Oyuncular WebSocket üzerinden mevcut parçalarından sorumlu Durable Object'e bağlanır. Bitişik bir parçaya geçtiklerinde, o parçanın DO'suna bağlanırlar. Durable Objects durumu otomatik olarak diske kalıcı biçimde kaydeder; böylece dünya verileri yeniden başlatmalardan etkilenmez.

İstemci-Sunucu İletişimi

Güvenilir ve sıralı iletiler (sohbet, dünya düzenlemeleri, envanter, oyun durumu) için WebSocket kullanın. Oyuncunun görebildiği her etkin parça için bir bağlantı kullanılır (genellikle 1-4 bağlantı).

Güvenilir olmayan ve sırasız iletiler (oyuncu konumları, animasyonlar, geçici efektler) için WebRTC DataChannel kullanın. WebRTC eşler arası çalışabilir, ancak çok sayıda oyuncunun bulunduğu bir dünyada N2 bağlantıdan kaçınmak için bunu bir SFU (Selective Forwarding Unit) üzerinden çalıştırmanız gerekir. Cloudflare Calls veya LiveKit, SFU olarak kullanılabilir.

Durum eşitleme delta sıkıştırması kullanır. Sunucu, her istemcinin neleri gördüğünü izler ve yalnızca değişiklikleri gönderir. Bu, üretici dünyalarında özellikle önemlidir; çünkü dünya durumu (hangi nesnelerin var olduğu, nerede bulundukları ve hangi özelliklere sahip oldukları) oyuncu konumlarından çok daha seyrek değişir. Oyuncu konumları 20-30 Hz'de güncellenirken dünya durumu güncellemelerini 2-5 Hz'de gönderebilirsiniz.

interface WorldChunkState {
  version: number;
  terrain: TerrainPatch;
  objects: PlacedObject[];
  creators: CreatorPresence[];
}

interface DeltaUpdate {
  chunkId: string;
  fromVersion: number;
  toVersion: number;
  addedObjects: PlacedObject[];
  removedObjectIds: string[];
  modifiedObjects: Partial<PlacedObject>[];
  creatorMoves: CreatorPosition[];
}

Üretici Düzenlemelerinde Çakışma Çözümü

İki üretici aynı alanı eş zamanlı değiştirdiğinde bir çakışma çözümü stratejisine ihtiyacınız vardır. Gerçek zamanlı iş birliği modelleri arasındaki seçim burada önem kazanır.

Son yazan kazanır yaklaşımı en basitidir. Her nesnenin herhangi bir anda tek bir sahibi vardır. Bir binayı düzenliyorsanız siz bırakana kadar başka hiç kimse onu düzenleyemez. Basittir, çakışma oluşturmaz ancak iş birliğini sınırlar.

Operasyonel Dönüşüm (OT), Google Docs'un kullandığı yöntemdir. Tutarlı bir sonuç üretmek için işlemler eş zamanlı işlemlere göre dönüştürülür. Bu, metin için işe yarar ancak 3D mekânsal işlemlerde karmaşıklaşır. Figma, 2D tuvali için bunun bir çeşidini kullanır.

CRDT'ler (Çakışmasız Çoğaltılmış Veri Türleri), eş güdüm gerektirmeden her zaman aynı duruma yakınsayan eş zamanlı düzenlemelere olanak tanır. Ayrık nesnelere (her biri bir kimliğe ve özelliklere sahip) sahip bir dünya için nesne koleksiyonunda Add-Wins Set ile birlikte her özellik başına bir Last-Writer-Wins Register kullanmak otomatik yakınsama sağlar. Yjs ve Automerge, JavaScript için üretime hazır CRDT kütüphaneleridir.

Önerimiz: Dünya nesnesi durumu (nelerin var olduğu, nerede bulunduğu ve hangi özelliklere sahip olduğu) için CRDT'leri; mekânsal doğrulama (aynı noktada iki nesnenin bulunmaması, nesnelerin dünya sınırları içinde kalması) için ise yetkili sunucuyu kullanın. İş birliğini CRDT yönetir. Fiziği sunucu yönetir.

Ölçeklendirme: Kaç Oyuncu?

Tarayıcı MMO'ları bugün zaten var. Hordes.io, tarayıcıdaki tek bir sahnede 200'den fazla oyuncuyla çalışır. BrowserQuest (Mozilla'nın deneyi), basit karo tabanlı bir dünyada yüzlerce oyuncuyu destekledi. Mesele tarayıcıların çok oyunculu deneyimleri destekleyip destekleyememesi değil, oyuncu sayısı arttıkça hangi görsel kaliteyi koruyabileceğinizdir.

Oyuncu işleme bütçesi: Görünür her oyuncunun bir ağa, animasyonlara ve potansiyel olarak üretici tarafından özelleştirilmiş bir görünüme ihtiyacı vardır. 60 fps'de kare başına 16 ms'niz bulunur. Makul bir bütçe şöyledir:

• Yakın mesafede tam animasyonlu 50 oyuncu: yaklaşık 2 ms animasyon + iskelet deformasyonu
• Orta mesafede 200 oyuncu (basitleştirilmiş animasyon, örneklenmiş): yaklaşık 1 ms
• Mini haritada nokta/simge olarak 500'den fazla oyuncu: ihmal edilebilir

Bu, tek bir görünümde yaklaşık 250 oyunculuk görünür nüfus sağlar ve bir üretici dünyası için fazlasıyla yeterlidir. World of Warcraft'ın başkentlerinde bile aynı anda görünüm içinde nadiren 200'den fazla karakter işlenir.

Ağ bütçesi: Her oyuncunun 20 Hz'de konum göndermesi yaklaşık olarak 40 bayt * 20 = 800 bayt/saniyedir. Görünümde 200 oyuncu: 160 KB/s konum verisi. Dünya durumu, sohbet ve üretici eylemlerini de eklediğinizde istemci başına 200-500 KB/s veri kullanımı ortaya çıkar. Bu, geniş bant kapasitesinin oldukça altındadır ancak yine de sıkıştırmaya değer.

Arazi Sistemi

Arazi, tüm açık dünyaların temelidir. Ayrıca her yerde bulunması ve daima görünür olması gerektiğinden, tarayıcı kısıtlamalarının en ağır hissedildiği alandır.

Yükseklik Haritası Tabanlı Arazi

Skyrim gibi bir yükseklik haritası kullanın. Yükseklik değerlerinden oluşan 2D bir ızgara, bir köşe gölgelendiricisi aracılığıyla 3D arazi üretir. Bu, serbest biçimli ağ arazisinden çok daha kompakttır.

16 bit hassasiyetteki 4096x4096 yükseklik haritası sıkıştırılmamış olarak 32 MB'dir. Ancak hiçbir zaman tamamını aynı anda yüklemezsiniz. Her 64 m'lik parça, yükseklik haritasının 65x65'lik bir bölümünü kullanır (16 bitte yaklaşık 8,4 KB). Bunu delta kodlaması ve zlib ile sıkıştırdığınızda parça başına 2 KB'nin altına inersiniz.

Doku splatting, bir karışım haritası kullanarak birden fazla arazi malzemesini (çim, kaya, toprak, kum) boyar. Her parçada, her kanalın bir malzemenin karışım ağırlığını kontrol ettiği 4 kanallı bir RGBA splat haritası bulunur. Splat haritası başına 4 doku ve parçaya göre splat haritalarını değiştirebilme olanağı sayesinde tüm dünya genelinde görsel çeşitlilik elde edersiniz.

Modern arazi işleyicileri sanal dokulama kullanır (id Software'ın Rage'deki teknolojisinden gelen adıyla mega doku da denir). Dokuları çalışma zamanında splatting ile karıştırmak yerine, harmanlanmış arazi dokusunu önceden yüksek çözünürlükte işler ve kamera hareket ettikçe bunun karolarını aktarırsınız. Bu yaklaşım, çalışma zamanı performansı karşılığında daha fazla depolama kullanır. WebGPU'nun hesaplama gölgelendiricileri, sanal dokulamanın gerektirdiği geri bildirim ve sayfa tablosu yönetimini gerçekleştirebilir.

Clipmap veya Geoclipmapping

Tarayıcıda büyük arazileri işlemek için CDLOD (C. Dick'in LOD'u) veya geoclipmapping yaklaşımı iyi sonuç verir. Arazi, kameranın etrafındaki bir dizi eş merkezli halka olarak işlenir ve her halkanın çözünürlüğü bir öncekinden yarı yarıya düşüktür. Kameraya yakınken araziyi tam çözünürlükte görürsünüz. Uzakta ise daha kaba bir sürümünü görürsünüz. Geometri seviyeler arasında biçim değiştirdiği için geçişler pürüzsüzdür.

Bu teknik GPU dostudur (halka başına bir çizim çağrısı), sabit bellekle sonsuz araziyi destekler ve WebGL 2'de çalışır. Flight Simulator ve modern açık dünya oyunlarının çoğu bunu belirli bir düzeyde kullanır.

Üreticiler Tarafından Değiştirilen Arazi

Üreticiler araziyi şekillendirebiliyorsa değişiklikleri temel yükseklik haritasının üzerinde depolayıp aktarmanın bir yoluna ihtiyacınız vardır. İki yaklaşım bulunur:

Delta yükseklik haritaları, temel arazi ile değiştirilmiş arazi arasındaki farkı depolar. Dünyanın büyük kısmı değiştirilmemiştir (delta değerleri sıfırdır), dolayısıyla bu son derece iyi sıkıştırılır. Bir parçayı yüklerken delta değerlerini temel haritanın üzerine uygulayın.

Daha büyük değişiklikler (mağaralar, çıkıntılar, kemerler) için voksel katmanları kullanın. Bir yükseklik haritası, tek bir noktanın iki yüksekliğe sahip olduğu araziyi temsil edemez. Yalnızca değiştirilmiş parçalarda depolanan seyrek bir voksel ızgarası bunu destekler. Marching cubes veya dual contouring, ağı oluşturur. Bu daha maliyetlidir ancak Minecraft tarzı arazi düzenlemeye olanak tanır.

Yapay Zekâ Destekli Dünya Üretimi

Cinevva'nın mevcut üretken yapay zekâ yetenekleri burada büyük bir güç çarpanına dönüşür. Üreticiler her kaya ve ağacı elle oluşturmak yerine yapay zekâyı dünyayı doldurması için yönlendirebilir.

Sinirsel Alanlarla Arazi Üretimi

Sinirsel arazi üretimine ilişkin yakın tarihli araştırmalar (NVIDIA'nın GET3D'si, Terragen'in sinir ağı modu ve "Terrain Generation Using Procedural Models" gibi makaleler), eğitilmiş modellerin metin istemlerinden veya eskiz girdilerinden inandırıcı araziler üretebildiğini gösteriyor. Bir üretici kabaca bir kıyı şeridi çizip "kayalık bir kıyıyla buluşan ormanlık tepeler" diyebilir ve uygun erozyon, bitki örtüsü maskeleri ve malzeme atamalarına sahip bir yükseklik haritası elde edebilir.

Tarayıcıya sunmak için üretimi sunucu tarafında çalıştırır ve sonucu aktarırsınız. Üretim modelinin tarayıcıda çalışması gerekmez. Model, tarayıcının standart arazi işlem hattıyla işleyebileceği yükseklik ve splat haritaları üretir.

3D Varlık Üretimi

Hunyuan3D, Meshy, Tripo ve Rodin gibi modeller, metinden veya görsellerden 3D ağlar üretebilir. Bir üretici dünyası için iş akışı şöyledir:

1. Üretici istediği şeyi tarif eder veya taslağını çizer ("yosunlu bir taş kemer" ya da "fütüristik bir sokak lambası")
2. Sunucu üretim modelini çalıştırır ve yüksek poligonlu bir ağ oluşturur
3. Sunucu otomatik olarak işler: web'e uygun poligon sayısına düşürür, LOD'lar üretir, dokuları atlasa işler ve Draco sıkıştırmalı GLB olarak dışa aktarır
4. Varlık, dünyaya yerleştirilmeye hazır biçimde üreticinin envanterinde görünür

Bu işlem hattının parçaları Cinevva'da zaten mevcut. Eksik olan kısım, LOD/optimizasyon adımı ve dünyaya yerleştirme sistemidir.

Prosedürel Yerleştirme

Yapay zekâyla üretilmiş varlıklar kullanılsa bile bir ormandaki her ağacı elle yerleştirmek zahmetlidir. Prosedürel dağıtım kuralları, üreticilerin bölgeler tanımlamasına ("bu alan sık bir ormandır", "bu yamaç kayalık molozlarla kaplıdır") ve sistemin bu bölgeleri otomatik olarak doldurmasına olanak tanır.

GPU hesaplama gölgelendiricileri dağıtım işlemini tarayıcıda çalıştırabilir. Bir yoğunluk haritası ve bir dizi kural (asgari aralık, eğim kısıtlamaları, yükseklik aralığı) verildiğinde, bir hesaplama geçişi bir parçanın tamamı için örnek konumlarını 1 ms'den kısa sürede oluşturur. Yoğunluk haritasını değiştirdiğinizde bitki örtüsü anında yeniden oluşturulur.

Varlık Bileşen Sistemi (ECS)

Binlerce nesne içeren bir açık dünya, verimli bir varlık yönetim sistemine ihtiyaç duyar. ECS kalıbı (Unity'nin DOTS'u ve Bevy'den bu yana oyun motorlarında popülerdir) JavaScript'e oldukça iyi uyarlanır.

bitECS, tipli diziler ve bitsel işlemler kullanan, JavaScript için yüksek performanslı bir ECS'dir. Varlıklar yalnızca tam sayılardır. Bileşenler, bitişik tipli dizilerdir (her bileşen türü için bir tane). Sistemler diziler üzerinde sıralı biçimde yinelenir; bu da JavaScript'te bile önbellek dostudur.

import { createWorld, defineComponent, Types, defineQuery, addEntity, addComponent } from 'bitecs';

const Position = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const Velocity = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const ChunkRef = defineComponent({ chunkX: Types.i16, chunkZ: Types.i16 });

const world = createWorld();
const movingQuery = defineQuery([Position, Velocity]);

function movementSystem(world) {
  const entities = movingQuery(world);
  for (let i = 0; i < entities.length; i++) {
    const eid = entities[i];
    Position.x[eid] += Velocity.x[eid] * dt;
    Position.y[eid] += Velocity.y[eid] * dt;
    Position.z[eid] += Velocity.z[eid] * dt;
  }
  return world;
}

Açık bir dünyada ECS her şeyi yönetir: oyuncu karakterleri, yerleştirilmiş nesneler, NPC'ler, parçacıklar, tetikleyiciler ve dünya dekorları. Bir parça bellekten kaldırıldığında varlıkları ECS'den silinir. Bir parça yüklendiğinde varlıklar eklenir. ECS, mekânsal düzenlemeyle ilgilenmez. Yalnızca bileşenleri işler.

Fizik

WebAssembly sayesinde tarayıcı fiziği şaşırtıcı derecede gelişti.

Rapier (Rust -> Wasm)

Rapier, Rust ile yazılmış ve WebAssembly'ye derlenen bir fizik motorudur. Katı cisimleri, çarpıştırıcıları, eklemleri, karakter denetleyicilerini ve ışın izlemeyi yönetir. Tipik oyun iş yüklerinde performansı, yerel Bullet/PhysX'in 2-3 katı aralığındadır.

Rapier, açık bir dünyada şunları yönetir:

• Oyuncu karakter denetleyicisi (arazide yürüme, basamakları çıkma, eğimlerde kayma)
• Nesneler arası çarpışma (yerleştirilmiş nesneler, mermiler)
• Oyuncu etkileşimleri için ışın izleme (seçmek için bir nesneye tıklama)
• Tetikleyici hacimler (bir alana girme, bir olayı tetikleme)

Rapier bir Web Worker içinde çalışır; böylece fizik simülasyonu görüntülemeyi engellemez. Her karede konumları görüntüleyiciye gönderir ve girdi olaylarını geri alırsınız.

Web için Havok (Babylon.js aracılığıyla)

Babylon.js'i seçerseniz Havok fiziği, bir Wasm modülü olarak yerleşik gelir. Havok, çoğu AAA oyununun (Half-Life 2, Skyrim, Breath of the Wild) arkasındaki fizik motorudur. Wasm derlemesi üretim kalitesindedir ve Babylon'ın sahne grafiği için optimize edilmiştir.

Arazi Çarpışması

Fizik motorları, arazi için çarpışma geometrisine ihtiyaç duyar. Görünür arazinin tamamı için tam çözünürlüklü bir üçgen ağ oluşturmak pahalı olurdu. Bunun yerine yalnızca oyuncuya yakın parçalar (en yakın 3x3 veya 5x5 parça) için çarpışma yükseklik alanları oluşturun ve geri kalan her şey için basitleştirilmiş çarpışma kullanın. Rapier'in yükseklik alanı çarpıştırıcısı tam olarak bu kullanım durumu için tasarlanmıştır.

Ses

Ses, 3B bir alanı görsel bir demodan gerçek bir mekâna dönüştürür. Web Audio API, tarayıcıda mekânsal ses için gereken her şeyi sağlar.

HRTF ile mekânsal ses (Başla İlişkili Aktarım İşlevi), sesleri 3B uzaya yerleştirir. Solunuzdaki bir şelalenin sesi gerçekten solunuzdan geliyormuş gibi duyulur. Yaklaştıkça ses yükselir. Bir binanın arkasına geçtiğinizde ise boğuklaşır (ek işlemlerle).

Ortam bölgeleri, ses için doku serpme gibi çalışır. Bölgeler (orman, mağara, kıyı, şehir) tanımlayın ve oyuncu bunlar arasında hareket ederken ortam ses manzaraları arasında yumuşak geçiş yapın. Skyrim, ormanların canlı duyulmasını bu şekilde sağlar. Rüzgârı, kuşları, hışırdayan yaprakları ve uzaktaki hayvanları katmanlayın. Bunların hiçbiri karmaşık değildir. Hepsi mekânsaldır.

Web Audio performansı, aynı anda onlarca mekânsal kaynak için yeterince iyidir. Darboğaz genellikle işleme değil, varlık boyutudur. Sıkıştırılmış ses için Opus veya AAC kullanın, uzun ortam parçalarını akışla aktarın ve kısa ses efektlerini (ayak sesleri, etkileşimler) önceden yükleyin.

Su, Hava Durumu ve Atmosfer

Akılda kalan her açık dünyada su ve hava durumu vardır. Bu sistemler atmosferi belirler ve dünyanın canlı hissettirmesini sağlar. Ayrıca tarayıcıda uygulanmaları şaşırtıcı derecede mümkündür.

Su Görüntüleme

Tarayıcı tabanlı 3B'de suyun üç karmaşıklık düzeyi vardır; önce en basitini yayımlayıp daha sonra yükseltebilirsiniz.

Düzey 1: Yansıtıcı düzlem. Su seviyesinde, yansıtıcı/kırıcı malzemeye sahip düz bir ağ. Sahneyi baş aşağı bir dokuya görüntüleyin (düzlemsel yansıma), bunu mavi bir tonla karıştırın ve dalga hareketi için kayan normal haritalar ekleyin. Skyrim'in temel su gölgelendiricisi bunu yapar. Three.js'te resmî depodaki Water örneği bunu uygular. Babylon.js'te WaterMaterial bunu kullanıma hazır olarak sunar. Maliyet: yansımalar için bir ek görüntüleme geçişi (yarı çözünürlük yeterlidir) ve su yüzeyinin çizimi. Orta seviye bir GPU'da bu, kare başına 2-3 ms ekler.

Düzey 2: Ekran uzayı yansımaları + derinlik tabanlı efektler. Ayrı bir yansıma görüntüleme geçişi yerine, yansımalar için mevcut kare tamponunu örnekleyin (SSR). Derinlik tabanlı renk emilimi (su derinleştikçe koyulaşır), derinlik karşılaştırmasıyla kıyılarda köpük ve su altındaki araziye yansıtılan kostikler ekleyin. The Witcher 3 bunu kullanır. SSR, hem Three.js'in son işleme yığınında hem de Babylon.js'in görüntüleme işlem hattında kullanılabilir. Maliyet: SSR için 1-2 ms, derinlik efektleri için ihmal edilebilir düzeyde.

Düzey 3: FFT okyanus simülasyonu. Açık okyanus için GPU'da dalga spektrumlarını simüle etmek üzere Hızlı Fourier Dönüşümü kullanın. Jerry Tessendorf'un "Simulating Ocean Water" (2001) makalesi, tüm büyük oyun motorlarının kullandığı temeldir. FFT, WebGPU'da bir hesaplama gölgelendiricisi olarak çalışır ve her karede bir yer değiştirme haritası ile normal harita üretir. Ortaya çıkan okyanus son derece inandırıcı görünür. Sea of Thieves, Assassin's Creed Black Flag ve Uncharted 4 bunu kullanır. WebGPU'da 256x256 FFT okyanusu, masaüstü GPU'larında 1 ms'den kısa sürede çalışır.

@compute @workgroup_size(16, 16)
fn fftOceanDisplacement(@builtin(global_invocation_id) id: vec3<u32>) {
    let k = vec2<f32>(f32(id.x) - N/2.0, f32(id.y) - N/2.0);
    let omega = sqrt(length(k) * gravity);
    let phase = omega * time;
    let h = spectrum[id.xy] * vec2<f32>(cos(phase), sin(phase));
    displacement[id.xy] = h;
}

İçerik üreticilerine yönelik bir dünyada Düzey 1 (yansıtıcı düzlem) ile başlayın ve görüntüleyici olgunlaştığında Düzey 2'ye geçin. Düzey 3 yalnızca dünyada açık okyanus varsa gereklidir.

Hava Durumu Sistemleri

Skyrim ve BotW'deki hava durumu, geçişlere sahip bir durum makinesi tarafından yönetilir. Açık > Bulutlu > Yağmurlu > Fırtınalı > Açık. Her durum aynı anda birden fazla sistemi değiştirir: gökyüzü kutusu, sis yoğunluğu, ortam ışığının rengi, parçacık efektleri (yağmur/kar), ses (rüzgâr, yağmur) ve oynanış özellikleri (BotW'de ıslak yüzeyler kaygandır).

Tarayıcı tabanlı bir dünya için hava durumu sistemi üç katmandan oluşur:

Gökyüzü görüntüleme. Prosedürel bir gökyüzü gölgelendiricisi, gökyüzü kutusu dokularından daha ucuz ve esnektir. Preetham veya Hosek-Wilkie gökyüzü modelleri, yalnızca güneşin konumundan fiziksel olarak makul gökyüzü renkleri hesaplar. Bir düzlem üzerinde kaydırılan 3B gürültüyü kullanarak bir bulut katmanı ekleyin. Babylon.js, yerleşik bir prosedürel gökyüzü malzemesine sahiptir. Three.js'te Sky örneği vardır. Her ikisi de ihmal edilebilir GPU maliyetiyle (tek bir tam ekran dörtgenidir) inandırıcı sonuçlar üretir.

Parçacık efektleri. Yağmur, yukarıdan düşen binlerce ince dörtgenden oluşan bir parçacık sistemidir. Kar da benzerdir ancak daha yavaş ve savrulan yörüngelere sahiptir. Sis, sahneyi derinliğe göre bir sis rengine doğru harmanlayan bir son işleme geçişidir. Bunların tümü standart WebGL efektleridir. Maliyet parçacık sayısına bağlıdır: 10.000 yağmur parçacığı kare başına yaklaşık 0,5 ms ekler.

Çevresel tepki. Islak yüzeyler aynasal yansımayı artırır. Kar birikimi, yukarı bakan yüzeylere beyazlık ekler. Çukurlu arazilerde su birikintileri oluşur. Bunlar geometri değişiklikleri değil, gölgelendirici hileleridir. Bir "ıslaklık" uniform değeri malzemenin pürüzlülüğünü değiştirir. Bir "kar örtüsü" uniform değeri, normalleri yukarı bakan yüzeylerde beyazı harmanlar. GTA V ve The Witcher 3 tam olarak bu yaklaşımı kullanır.

Senkronize hava durumu. Çok oyunculu bir dünyada hava durumu tüm istemcilerde tutarlı olmalıdır. En basit yaklaşım şudur: sunucu, hava durumu durumunu (geçiş ilerlemesi dâhil) 1 Hz hızında yayınlar. İstemciler yerel olarak interpolasyon yapar. Hava durumu yavaş değiştiğinden (açık havadan yağmura geçiş 30-60 saniye sürer), gecikmiş bir güncelleme bile akıcı görünür.

Atmosferik Perspektif

Bu, bir dünyanın büyük hissettirilmesini sağlayan en etkili görsel tekniktir ve neredeyse ücretsizdir. Uzaktaki nesneler, atmosferdeki ışık saçılımı nedeniyle daha puslu, daha mavi ve daha düşük kontrastlı görünür. Her açık dünya bunu kullanır.

Bir parça gölgelendiricisinde, uzaktaki pikselleri derinliğe göre atmosfer rengine doğru harmanlayın:

float fogFactor = 1.0 - exp(-distance * fogDensity);
vec3 finalColor = mix(objectColor, atmosphereColor, fogFactor);

BotW, suluboya tarzı bir uzaklığa dönüşen resimsi sisle bunu daha ileri taşır. Sis rengi günün saatine ve hava durumuna göre değişir. Bu tek gölgelendirici efekti, ölçek hissi için herhangi bir miktardaki arazi ayrıntısından daha fazlasını sağlar.

Stilize bir sanat yönetimine sahip tarayıcı tabanlı bir dünyada, uygulanması gereken ilk görsel efekt atmosferik perspektiftir. LOD geçişlerini gizler (daha düşük ayrıntılı uzaktaki nesneler pusun içinden iyi görünür), akışla yüklenen içeriklerin görünür biçimde aniden belirmesini azaltır ve dünya tamamen doldurulmadan önce bile ekran görüntülerinin iyi görünmesini sağlar.

Avatar Sistemleri

Oyuncuların bedenlere ihtiyacı vardır. İçerik üreticilerine yönelik bir dünyada avatar, inşa ettiklerinizin yanı sıra kendinizi ifade etmenin birincil yoludur. Sistem, kişiselleştirme için yeterince esnek olmalı ve aynı zamanda 200'den fazla görünür oyuncu için görüntüleme maliyetlerini yeterince düşük tutmalıdır.

Avatar Mimarisi

Temel ağ + özelleştirme katmanları. Paylaşılan insansı bir temel ağla başlayın (gövde için 1.500-3.000 üçgen). Özelleştirme şu yollarla gerçekleştirilir:

• Uniform değişiklikleri aracılığıyla renk/doku varyasyonları (cilt tonu, saç rengi). Ek geometri gerektirmez.
• Temel ağın bölümlerinin yerini alan, değiştirilebilir ağ parçaları (saç stilleri, kıyafetler, aksesuarlar). Her parça ayrı bir küçük ağdır (200-500 üçgen).
• Malzeme parametresi değişiklikleri aracılığıyla malzeme özelliği varyasyonları (metalik zırh veya kumaş tunik).

Roblox, Fortnite ve VRChat avatarları bu şekilde işler. Temel maliyet, özelleştirmeden bağımsız olarak sabit kalır.

Ready Player Me ve Avaturn, tüm 3B motorlarla uyumlu glTF modelleri üreten tarayıcı tabanlı avatar oluşturma araçları sunar. Fotoğraflardan yüz taramayı, vücut oranlarını ve kıyafetleri yönetirler. Çıktı modelleri gerçek zamanlı görüntüleme için optimize edilmiştir (genellikle 10 bin-20 bin üçgen; uzaktan görüntüleme için 3 bin-5 bine indirilebilir).

Tarayıcıda İskelet Animasyonu

Görünür her oyuncunun animasyonlara ihtiyacı vardır: bekleme, yürüme, koşma, zıplama ve ifadeler. İskelet animasyonu, her karede bir dizi kemik dönüşümü aracılığıyla bir ağı hareket ettirir.

GPU skinning, performans için zorunludur. Hem Three.js hem de Babylon.js varsayılan olarak skinning işlemini GPU'da gerçekleştirir. Kemik matrisleri bir uniform tamponu veya doku olarak yüklenir ve köşe gölgelendiricisi kemik dönüşümlerini uygular. CPU maliyeti, animasyon klibinden kemik dönüşümlerini hesaplamaktır. 30 fps'de 60 kemikli bir iskelet için bu, karakter başına yaklaşık 0,01 ms'dir. 200 karakter: toplam 2 ms. Kabul edilebilir.

Animasyon harmanlama, harman ağırlıklarını kullanarak birden fazla animasyonu (yürüme + el sallama, bekleme + etrafa bakma) karıştırır. Hem Three.js (AnimationMixer) hem de Babylon.js (AnimationGroup) bunu destekler. Harmanlama, harmanlanmış sonuç GPU'ya gitmeden önce CPU'da (kemik dönüşümlerinin interpolasyonu yoluyla) gerçekleşir.

Örneklenmiş animasyon, çok sayıda karakteri verimli biçimde görüntülemenin anahtarıdır. Her karakteri ayrı bir ağ olarak çizmek yerine, animasyon karelerini bir dokuya işleyin (köşe animasyonu dokusu veya VAT). Dokunun her satırı, bir kareye ait kemik dönüşümlerini saklar. Bir hesaplama gölgelendiricisi veya köşe gölgelendiricisi, karakterin animasyon zamanına göre doğru satırı okur. Böylece yüzlerce karakter tek bir örneklenmiş çizim çağrısıyla görüntülenebilir. The Witcher 3 ve Assassin's Creed bunu kalabalık görüntüleme için kullanır.

WebGPU'da örneklenmiş animasyonlu karakterler şöyle görünür:

@vertex
fn vs_main(@builtin(instance_index) instanceIdx: u32, @location(0) position: vec3<f32>) -> @builtin(position) vec4<f32> {
    let animFrame = instances[instanceIdx].animationFrame;
    let boneIdx = vertexBoneIndices[vertexIdx];
    let boneTransform = textureLoad(animTexture, vec2<i32>(i32(boneIdx), i32(animFrame)), 0);
    let worldPos = instances[instanceIdx].transform * boneTransform * vec4<f32>(position, 1.0);
    return viewProjection * worldPos;
}

Uzaktaki oyuncular (50 metreden ötede) için billboard sahtelerine geçin: karakterin mevcut görüş açısından önceden görüntülenmiş hareketli grafiğini gösteren düz bir dörtgen. Bu, Skyrim'in uzaktaki ağaçlar için kullandığı hilenin karakterlere uygulanmış hâlidir. Geçiş uzaktan fark edilmez.

Etkileşim için Ters Kinematik

Bir karakter nesne aldığında, kapı koluna uzandığında veya bir şeyi işaret ettiğinde prosedürel IK, eylemin doğal görünmesini sağlar. FABRIK (Forward And Backward Reaching Inverse Kinematics), gerçek zamanlı uygulamalarda iyi çalışan basit ve hızlı bir IK çözücüsüdür. Hem Three.js (CCDIKSolver aracılığıyla) hem de Babylon.js (BoneIKController aracılığıyla) yerleşik IK desteğine sahiptir.

İçerik üreticilerine yönelik bir dünyada IK, karakterlerin yerleştirilmiş nesnelerle doğal biçimde etkileşime girebilmesi anlamına gelir: üreticilerin yerleştirdiği sandalyelere oturabilir, korkuluklara yaslanabilir ve eşyaları alabilirler. Etkileşimler için nesne başına animasyon gerekmez. IK sistemi, karakterin pozunu nesnenin konumuna uyarlar.

Gelişmiş Ağ İletişimi

Temel mimari (WebSocket + WebRTC) daha önce ele alındı. Burada protokoller, sıkıştırma ve daha yeni aktarım seçenekleriyle ilgili ayrıntılara gireceğiz.

İkili Mesaj Protokolleri

WebSocket üzerinden JSON kullanmak, ikili kodlamaya kıyasla bant genişliğini 10 kat boşa harcar. Gerçek zamanlı çok oyunculu bir dünyada her mesaj ikili olmalıdır. FlatBuffers (Google tarafından geliştirildi) oyun ağ iletişimi için en uygun seçenektir. Protocol Buffers'ın aksine FlatBuffers, serileştirilmiş verilere sıfır kopyalamalı erişim sağlar. Mesajı JavaScript nesnelerine dönüştürmezsiniz. Alanları doğrudan arabellekten okursunuz. Bu, Protocol Buffers'ın yoğun çalışan bir kod yolunda oluşturacağı bellek ayırma ve çöp toplama yükünü ortadan kaldırır. FlatBuffers'ın JavaScript/TypeScript kod üreteci vardır.

FlatBuffers ile bir oyuncu konumu güncellemesi:

// Schema: PlayerUpdate { id: uint16, x: float32, y: float32, z: float32, yaw: float16, pitch: float16, animState: uint8 }
// Total: 17 bytes per player update
// vs JSON: {"id":42,"x":103.5,"y":12.3,"z":-47.8,"yaw":1.57,"pitch":0.2,"animState":3} = 80+ bytes

20 Hz'de 200 oyuncu için aradaki fark 200 * 17 * 20 = 68 KB/sn (ikili) ile 200 * 80 * 20 = 320 KB/sn (JSON) olur. İkili veri 4,7 kat daha küçüktür ve yoğun döngüde JSON.parse kaynaklı bellek ayırmalarını önler.

MessagePack, FlatBuffers'dan daha basittir (şema ve kod üretimi yoktur) ancak yine de JSON'dan %30-50 daha küçüktür. Şema yönetimi olmadan ikili veri kullanmak istiyorsanız iyi bir orta yoldur.

Konum Kuantalama ve Delta Sıkıştırma

Oyuncu konumları 32 bit kayan nokta hassasiyetine ihtiyaç duymaz. Dünyanız 4 km x 4 km ise 16 bit işaretsiz bir tam sayı size 6 cm hassasiyet sağlar (4000 m / 65536). Çoğu oyunda bunun tam hassasiyetten farkı algılanamaz. Bu, konum verilerinin boyutunu yarıya indirir.

Delta sıkıştırma, yalnızca son onaylanan durumdan farkı gönderir. Bir oyuncu son güncellemeden bu yana 0,5 metre hareket ettiyse delta, iyi sıkıştırılabilen küçük bir sayıdır. Değişken uzunluklu kodlamayla birlikte (daha küçük deltalar daha az bayt kullanır), delta ile sıkıştırılmış tipik konum güncellemeleri 12 bayt yerine 3-6 bayttır.

Ölü hesaplama, güncelleme sıklığını azaltır. Konumu 20 Hz'de göndermek yerine konum + hız gönderilir. İstemci, güncellemeler arasındaki konumu ileriye dönük tahmin eder. Yalnızca gerçek konum, tahmin edilen konumdan belirli bir eşiğin üzerinde saptığında düzeltme gönderilir. Bu, düz çizgide hareket eden oyuncular için (hareketlerin çoğu böyledir) konum güncellemesi bant genişliğini %60-80 azaltabilir.

RuneScape bunun uç bir sürümünü kullanır: oyuncu hareketi karo tabanlıdır, dolayısıyla bir hareket komutu yalnızca hedef karodan oluşur. İstemci, yürüme rotasını yerel olarak canlandırır. Kesintisiz bir 3D dünya için akıcı ölü hesaplama kullanılırdı ancak ilke aynıdır.

WebTransport

WebTransport, oyun ağ iletişiminde hem WebSocket'in hem de WebRTC DataChannel'ın yerini alabilecek daha yeni bir protokoldür. HTTP/3 (QUIC) üzerinden çalışır ve şunları sağlar:

• Güvenilir, sıralı akışlar (WebSocket gibi ancak çoklanmıştır; dolayısıyla bir akıştaki duraklama diğerlerini engellemez)
• Güvenilir olmayan datagramlar (UDP gibi; geciken konum güncellemeleri anında geçersizleştiğinden bunlar için uygundur)
• Çoklanmış akışlar (satır başı engellemesi olmadan sohbet, dünya durumu ve konumlar için ayrı akışlar)

Oyun ağ iletişiminin ihtiyaç duyduğu şey tam olarak budur. WebSocket güvenilir ve sıralı iletişim sağlar (ancak satır başı engellemesi, konum güncellemelerindeki gecikmeyi artırır). WebRTC DataChannel güvenilir olmayan iletişim sağlar (ancak kurulumu karmaşıktır ve ICE/STUN gerektirir). WebTransport ise ikisini tek bir bağlantı üzerinden sunar.

Tarayıcı desteği: Chrome, Edge ve Firefox bir süredir WebTransport desteği sunuyor; Safari 26.4 ise Mart 2026'da bu desteği ekledi. Bu adım WebTransport'u Baseline durumuna taşıdı; yani artık tüm tarayıcıların WebKit kullandığı iOS dahil olmak üzere bütün büyük tarayıcılarda çalışıyor. Eski Safari sürümleri için WebSocket yedek çözümünü korumak hâlâ faydalı olsa da WebTransport bugün genel kullanım için hazırdır.

Cloudflare, altyapımıza uygun şekilde Workers üzerinden WebTransport'u destekler.

Büyük Ölçekte İlgi Alanı Yönetimi

200'den fazla oyuncuyla ağ iletişiminin zorluğu, oyuncu başına düşen bant genişliği değildir. Sorun N-kare ölçeklenmesidir: her oyuncu diğer tüm oyunculara güncelleme gönderirse 200 oyuncu, tik başına 200 * 199 = 39.800 güncelleme mesajı demektir. Sunucunun bunları filtrelemesi gerekir.

İlgi Alanı (AOI) yönetimi, her oyuncunun yalnızca görüş menzili içindeki varlıklarla ilgili güncellemeleri alması anlamına gelir. Uygulama, parça sistemiyle aynı uzamsal ızgarayı kullanır: bir oyuncunun konumu (3, 7) parçasına karşılık geliyorsa oyuncu, 3x3'lük bir komşuluk olan (2-4, 6-8) parçalarından güncellemeler alır. Bu aralığın dışındaki varlıklar gönderilmez.

AOI içindeki öncelik tabanlı güncellemeler, önemli varlıklara daha fazla bant genişliği ayırır. Size doğru koşan bir oyuncu 20 Hz'de güncellenir. 200 metre uzakta hareketsiz duran bir oyuncu 2 Hz'de güncellenir. Hiçbir şey yapmayan bir NPC 0,5 Hz'de güncellenir. Sunucu, her istemci için bir öncelik kuyruğu tutar ve bant genişliğini varlığın ilgililik düzeyine (mesafe, hız ve etkileşim olasılığı) göre dağıtır.

Uyku durumu. N saniye boyunca durumu değişmeyen varlıklar uyku durumuna geçer ve ağ trafiği oluşturmayı tamamen bırakır. İstemci, bir uyanma olayı gelene kadar bilinen son durumu korur. Yerleştirilen nesnelerin çoğunun sabit olduğu üretici dünyalarında uyku durumu, olası ağ trafiğinin büyük bölümünü ortadan kaldırır.

Slither.io'nun değişken tik hızı (uzakta 5 Hz, yakında 30 Hz) bunun basitleştirilmiş bir sürümüdür. EVE Online'ın "zaman genişletmesi" ise uç bir sürümüdür (tek bir alanda çok fazla oyuncu bulunduğunda sunucu, tutarlılığı korumak için oyunun tik hızını düşürür). Bizim kullanım senaryomuz için uyku durumuyla birlikte öncelik tabanlı AOI doğru dengeyi sağlar.

Gaussian Splatting ve Yeni Görselleştirme Teknolojileri

Geleneksel mesh görselleştirme (üçgenler + dokular) artık tarayıcı tabanlı 3D için tek seçenek değildir. Daha yeni birkaç teknik, üretimde kullanılabilir hâle gelmektedir.

3D Gaussian Splatting

3D Gaussian Splatting (SIGGRAPH 2023): fotoğraflardan fotogerçekçi sahne yeniden oluşturma ve tarayıcıda gerçek zamanlı görselleştirme. Üreticiler gerçek dünyadaki nesneleri telefonla tarayıp doğrudan dünyaya yerleştirebilir.

3D Gaussian Splatting (3DGS), sahneyi milyonlarca renkli 3D Gauss elemanı (yönlendirilmiş, renkli elipsoitler) olarak temsil ederek fotoğraflardan 3D sahneler oluşturur. Görselleştirici, üçgenler yerine bu splat'leri sıralayıp rasterleştirir.

Bunun bir üretici dünyası için önemli olmasının nedenleri:

• Fotogrametriyle yakalama son derece kolaylaşır. Üretici, gerçek dünyadaki bir nesnenin veya konumun telefonuyla 50 fotoğrafını çeker. Sunucu tarafındaki işleme (Nerfstudio veya gsplat gibi araçlarla) dakikalar içinde bir Gaussian splat sahnesi üretir. Bu sahne tarayıcıda yüklenir ve her açıdan fotogerçekçi görünür.
• Tarayıcıda görselleştirme sorunu çözülmüştür. Birden fazla açık kaynaklı uygulama, Gaussian splat'leri WebGL ve WebGPU'da görselleştirir. PlayCanvas yerleşik splat görselleştirmeye sahiptir. Luma AI, Three.js uyumlu bir görüntüleyici sunar. gsplat.js ise bağımsız bir kütüphanedir. Performans iyidir: masaüstü GPU'larında 1-3 milyon splat, 30-60 fps hızında görselleştirilebilir.
• Veri biçimi kompakttır. Bir odanın Gaussian splat sahnesi sıkıştırılmış hâlde 10-30 MB olabilir. Tekil nesneler ise 1-5 MB'tır. Bu, dokulu mesh varlıklarıyla karşılaştırılabilir düzeydedir.

Dezavantajı şudur: splat sahneleri sabittir. Bunları kolayca canlandıramaz veya değiştiremezsiniz. Çevre düzenlemesinde (fotogerçekçi bir ağaç, gerçek dünyadan yakalanmış bir heykel veya taranmış bir bina cephesi) iyi çalışırlar ancak etkileşimli oyun nesneleri için uygun değildirler. Hibrit yaklaşım, çevresel ayrıntılar için splat'leri, etkileşimli nesneler için ise geleneksel mesh'leri kullanmaktır.

Bir üretici dünyası için: Üreticilerin telefon fotoğraflarıyla gerçek dünyadaki nesneleri yakalamasına, bunları sunucu tarafında Gaussian splat'lere dönüştürmesine ve dünyaya yerleştirmesine olanak tanıyın. Bu, yapay zekâyla üretilen varlıklarla gerçek dünyadaki nesneler arasındaki boşluğu kapatır. Bir üretici kendi sanat eserini, mobilyasını veya mimarisini tarayıp doğrudan paylaşılan dünyaya yerleştirebilir.

Neural Radiance Fields (NeRF'ler) ile Mesh Üretimi

NeRF'ler, sahneleri herhangi bir 3D noktanın renk ve yoğunluk değerini çıktı olarak veren sinir ağları şeklinde temsil eder. Fotoğraflardan olağanüstü görsel kalite üretirler ancak görselleştirilmeleri pahalıdır (her karede piksel başına tam bir sinir ağı ileri geçişi gerekir).

Tarayıcılar için pratik yaklaşım şudur: fotoğraflardan bir NeRF eğitin, ardından yoğunluk alanında marching cubes kullanarak bir mesh çıkarın. Sonuç, herhangi bir tarayıcı motorunun görselleştirebileceği, dokuları işlenmiş geleneksel bir üçgen mesh'tir. Instant-NGP, Nerfstudio ve Neuralangelo gibi araçlar bu işlem hattını otomatikleştirir. Kalite, NeRF'i doğrudan görselleştirmek kadar yüksek değildir ancak standart görselleştirme işlem hatlarıyla uyumludur.

Bu da üreticilerin modelleme becerilerine ihtiyaç duymadan gerçek dünyadaki nesneleri tarayıcı dünyasına aktarmaları için başka bir yoldur.

Mesh Shader'ları ve Nanite Tarzı Görselleştirme

UE5'in Nanite sistemi; mesh shader'ları, GPU güdümlü görselleştirme ve sanal geometri (ekran kapsamına göre küme düzeyinde üçgen akışı) kullanarak milyarlarca üçgeni görselleştirir. WebGPU henüz mesh shader'larını desteklemiyor ancak temel ilke (hesaplama tabanlı ayıklama ve LOD seçimiyle GPU güdümlü görselleştirme) uygulanabilir.

Bir WebGPU hesaplama shader'ı şunları yapabilir:

1. Tüm mesh kümelerinin sınırlayıcı kutularını okur (yaklaşık 64 üçgenden oluşan gruplar)
2. Her kümeyi görüş hacmine ve örtülme arabelleğine karşı test eder
3. Ekran uzayındaki boyuta göre uygun LOD düzeyini seçer
4. Görünür kümeleri dolaylı çizim arabelleğine yazar
5. Tek bir dolaylı çizim çağrısı her şeyi görselleştirir

Bu "sanal geometri" yaklaşımı, milyonlarca üçgeni sabit CPU maliyetiyle işler (sahne karmaşıklığından bağımsız olarak CPU tek bir çizim çağrısı gönderir). Tarayıcı tabanlı görselleştirme, büyük açık dünyaları eninde sonunda bu şekilde işleyecektir. Uygulaması karmaşıktır ancak gerekli yapı taşları bugün WebGPU'da mevcuttur.

Stilize Açık Dünyalar için Shader Teknikleri

Stilize bir sanat yönetimi, belirli shader teknikleri gerektirir. GPU döngüsü başına en yüksek görsel etkiyi sağlayan teknikler şunlardır.

Bitki Örtüsü Rüzgâr Animasyonu

Rüzgârda sallanan ağaçlar ve çimenler, dünyayı canlı hissettirir. Teknik basittir: vertex shader'da, dünya konumu ve zamana göre belirlenen sinüs dalgalarının birleşimini kullanarak köşe konumlarını kaydırın.

vec3 windOffset = vec3(
    sin(worldPos.x * 0.5 + time * 2.0) * windStrength,
    0.0,
    cos(worldPos.z * 0.3 + time * 1.5) * windStrength
);
float heightFactor = localPos.y / meshHeight;
finalPos += windOffset * heightFactor * heightFactor;

heightFactor, ağacın tabanının yere sabit kalmasını, tepesinin ise en fazla sallanmasını sağlar. Sinüs fonksiyonunda dünya konumunun kullanılması, bitişik ağaçların biraz farklı fazlarda sallanmasını sağlayarak orman boyunca doğal bir dalga etkisi oluşturur. BotW, Skyrim ve bitki örtüsü içeren tüm açık dünya oyunları bu tekniği kullanır.

Aynı ilke çimenler için de geçerlidir ancak daha yüksek frekans ve daha kısa dalga boyu kullanılır. Örnek başına rastgele faz kaymaları içeren, GPU örneklemeli çimen yaprakları (binlerce ince dörtgen), çok düşük maliyetle inandırıcı çayırlar oluşturur. WebGPU hesaplama shader'ları, çimen yapraklarının konumlarını ve yönlerini bir yoğunluk haritasından üretebilir; rüzgâr etkisi her karede örnek dönüşümlerine işlenir.

Toon/Cel Gölgelendirme

Sanat yönetimi stilizeyse (ve bulgular böyle olması gerektiğini gösteriyorsa) temel teknik cel gölgelendirmedir. Fikir şudur: aydınlatmayı yumuşak geçişler yerine ayrık adımlara kuantalamak.

float NdotL = dot(normal, lightDir);
float toonShading = step(0.3, NdotL) * 0.5 + step(0.6, NdotL) * 0.5;
vec3 color = baseColor * (ambient + toonShading);

Bu, klasik iki veya üç tonlu görünümü üretir. Çizgi roman etkisi için bir kontur geçişi ekleyin (arka yüzleri hafifçe genişleterek görselleştirin veya ekran uzayında kenar algılayan bir son işleme efekti kullanın).

BotW'nin gölgelendirmesi saf cel gölgelendirmeden daha inceliklidir. Gölge sınırında hafif bir basamak bulunan yumuşak bir gradyan ve sıcaktan soğuğa renk geçişi kullanır (gölgeler mavi tonlu, aydınlık alanlar ise sıcaktır). Bu hibrit yaklaşım, stilize görünümünü korurken katı toon gölgelendirmeden daha doğal görünür. Herhangi bir tarayıcı 3D motorunda özel bir shader ile uygulanabilir.

Stilize Su Shader'ı

Stilize bir dünyadaki suyun gerçekçi dalga simülasyonuna ihtiyacı yoktur. Kayan normal haritaları, kıyı köpüğü algılama ve derinlik tabanlı renklerin birleşimi, BotW tarzı sanat yönetimiyle görsel olarak uyumlu sonuçlar verir.

float depth = texture(depthTexture, screenUV).r - fragDepth;
vec3 shallowColor = vec3(0.2, 0.7, 0.8);
vec3 deepColor = vec3(0.05, 0.15, 0.3);
vec3 waterColor = mix(shallowColor, deepColor, saturate(depth * 2.0));

float foam = step(0.05, depth) * (1.0 - step(0.15, depth));
foam *= texture(foamNoise, worldUV * 3.0 + time * 0.1).r;
waterColor = mix(waterColor, vec3(1.0), foam * 0.8);

Bu size derinlik tabanlı renklendirme (sığ su daha açıktır) ve gürültüyle hareketlenen kıyı köpüğü sağlar; üstelik tamamı tek bir fragment shader geçişinde çalışır.

Ekran Uzayı Ortam Perdelemesi (SSAO)

SSAO; köşeleri, yarıkları ve yüzeylerin birleştiği alanları karartır. Pahalı küresel aydınlatmaya ihtiyaç duymadan sahneye derinlik kazandırır ve nesneleri zemine oturtur. Hem Three.js hem de Babylon.js yerleşik SSAO uygulamalarına sahiptir.

Stilize bir dünyada SSAO, gerçekçi görselleştirmedekinden daha da önemlidir çünkü düz gölgelendirme, temas gölgelerini doğal olarak göstermez. Hafif bir SSAO geçişi (yarı çözünürlük yeterlidir), eksik derinlik ipuçlarını ekler. Maliyeti: masaüstü GPU'larında 1-2 ms.

Daha Derinlemesine Dünya Üretimi

Temel makale, prosedürel araziyi genel hatlarıyla ele aldı. İşte algoritmik ayrıntılar.

Arazi için Gürültü Fonksiyonları

Tüm prosedürel arazi üretimi gürültüyle başlar. Gürültü fonksiyonu, uzayda yumuşak biçimde değişen sözde rastgele değerler üretir. Doğal görünen sonuçlar için birden fazla oktavı (frekansı) katmanlayın.

Perlin gürültüsü klasik yöntemdir. Simplex gürültüsü daha hızlıdır ve daha az yönsel yapaylık oluşturur. OpenSimplex 2, JavaScript'te iyi performans gösteren modern varyanttır. WebGPU hesaplama shader'ları için WGSL'de simplex gürültüsü uygulamak kolaydır (yaklaşık 50 satırlık matematikten oluşur).

Fraktal Brown Hareketi (fBm), gürültü oktavlarını katmanlar:

height = 0
amplitude = 1.0
frequency = baseFrequency
for each octave:
    height += amplitude * noise(position * frequency)
    frequency *= lacunarity (typically 2.0)
    amplitude *= persistence (typically 0.5)

6-8 oktav kullanıldığında fBm; gerçek araziye çok benzeyen büyük ölçekli dağ oluşumları, orta ölçekli tepeler ve ince ölçekli pürüzlülük içeren araziler üretir. Persistence parametresi, arazinin ne kadar engebeli olduğunu kontrol eder (0,3 yumuşak ve dalgalı tepeler, 0,7 ise sivri dağlar üretir).

Alan çarpıtma (domain warping), bir gürültü fonksiyonunun çıktısını başka bir fonksiyonun giriş koordinatları olarak kullanır. Bu yöntem, tekdüze biçimde engebeli görünmek yerine aşınmış ve organik görünen araziler üretir. 2-3 katman alan çarpıtma uygulandığında arazi, jeolojik süreçlerle şekillenmiş gibi görünmeye başlar.

Hidrolik Erozyon Simülasyonu

Ham gürültüyle üretilen arazi buruşmuş kâğıda benzer. Gerçek arazi ise bir milyon yıl boyunca yağmur altında kalmış buruşuk kâğıda benzer. Hidrolik erozyon simülasyonu, gürültüyle üretilen araziyi jeolojik açıdan gerçekçi görünen bir yapıya dönüştürür.

Algoritma:

1. Yükseklik haritasında rastgele bir konuma bir su parçacığı bırakın
2. Parçacık yokuş aşağı akar (arazi gradyanını izler)
3. Her adımda hızına ve eğime bağlı olarak araziden tortu toplar
4. Parçacık yavaşladığında (arazi düzleştiğinde veya su biriktiğinde) tortuyu bırakır
5. Bu işlemi 100.000-500.000 parçacık için tekrarlayın

Sonuçta nehir vadileri, alüvyon yelpazeleri, doğal görünen sırt hatları ve mantıklı biçimde geçiş yapan yumuşak yamaçlara sahip bir arazi ortaya çıkar. Algoritma, 1024x1024 boyutundaki bir yükseklik haritasında JavaScript ile yaklaşık 2-5 saniyede, WebGPU compute shader ile ise 100 ms'den kısa sürede çalışır.

Sebastian Lague'ın uygulaması (GitHub'da mevcuttur), oyun geliştiricileri için standart başvuru kaynağıdır. Elle şekillendirilmiş sonuçlarla yarışabilecek araziler üretir. Bir içerik üretici dünyasında, sunucu tarafındaki işleme adımı sırasında yapay zekâyla üretilmiş araziye erozyon uygulamak, prosedürel olarak oluşturulan manzaraların el yapımı görünmesini sağlayabilir.

Biyom Atama

Gerçek dünyalarda biyomlar vardır: ormanlar, çöller, tundralar ve bataklıklar. Biyom atama, iklim parametrelerini arazi bölgeleriyle eşleştirir.

Minecraft'ın yaklaşımı öğreticidir: sıcaklık ve nem eksenlerini kullanarak 2B bir ızgara üzerinde biyomlar tanımlayın. Sıcaklık, rakım ve enlem arttıkça azalır. Nem ise suya yakınlığa ve hâkim rüzgâr yönüne göre değişir. Her ızgara hücresine; arazi dokularını, bitki örtüsünün türünü ve yoğunluğunu, ortam seslerini ve hava durumu düzenlerini belirleyen bir biyom (orman, çöl, tundra vb.) atanır.

Bir içerik üretici dünyasında biyom sınırları boyanabilmelidir. Sistem, arazi özelliklerinden varsayılan biyomlar üretir; ancak içerik üreticileri, sahip oldukları parsellerde biyom bölgelerini boyayarak bu atamayı geçersiz kılabilir. Bu hibrit yaklaşım, dünyaya doğal görünen bir başlangıç sunarken içerik üreticilerinin kendi vizyonlarını ifade etmelerine olanak tanır.

Yapılar İçin Dalga Fonksiyonu Çöküşü

Dalga Fonksiyonu Çöküşü (WFC), komşuluk kısıtlarına sahip bir karo kümesinden yapılar (binalar, zindanlar, yollar) üretir. Modüler yapı parçaları ve hangi parçaların birbiriyle bağlanabileceğine ilişkin kurallar verildiğinde WFC; köylerin tamamını, kale planlarını veya zindan haritalarını oluşturabilir.

Bir içerik üretici dünyasında WFC şunları mümkün kılar:

• İçerik üreticileri özelleştirmeden önce dünyayı temel içerikle doldurmak için otomatik oluşturulan köyler
• İçerik üreticisinin birkaç parça yerleştirdiği, WFC'nin ise boşlukları doldurduğu destekli inşa (Townscaper gibi, ancak 3B yapı bloklarıyla)
• İçerik üreticilerinin yapılandırabileceği etkileşimli deneyimler için zindan üretimi (temayı, zorluğu ve boyutu belirlediğinizde WFC planı oluşturur)

Oskar Stalberg (Townscaper ve Bad North'un yaratıcısı), WFC tabanlı üretimin kullanıcılara büyülü hissettirdiğini göstermiştir. Kullanıcılar birkaç blok yerleştirir ve sistem bunların çevresinde estetik açıdan tutarlı yapılar üretir. Bu, içerik üretici platformlarında başarılı olan "basit araçlar, zengin çıktılar" ilkesinin tam karşılığıdır.

İçerik Moderasyonu Mimarisi

İçerik üreticilerinin başkalarının görebileceği her türlü 3B içeriği yerleştirebildiği bir dünyada moderasyon isteğe bağlı değildir. Temel altyapı bileşenlerinden biridir.

Otomatik Tarama İşlem Hattı

Dünyaya giren her varlık, diğer oyuncular tarafından görünür hâle gelmeden önce çok aşamalı bir işlem hattından geçer:

1. Geometri analizi. Eğitilmiş bir sınıflandırıcı kullanarak mesh'i anatomik açıdan müstehcen şekillere karşı tarayın. Bu yöntem, açıkça uygunsuz olan 3B modellerin çoğunu yakalar. Çeşitli ticari API'ler (Azure Content Safety, 3B için Google Cloud Vision) bunu destekler. Sınıflandırıcı, mesh'in silüetini birden fazla açıdan inceler; bu da hesaplama açısından düşük maliyetlidir.

2. Doku analizi. Her dokuyu standart bir görsel içerik moderasyonu API'sinden geçirin (yüklenen fotoğraflar için kullanılanlarla aynı API'ler). Bu, normal görünen geometrilere doku olarak uygulanmış uygunsuz görselleri yakalar.

3. Metin algılama. Nesne metin içeriyorsa (dokuda veya 3B metin mesh'i olarak), OCR çalıştırın ve metni içerik politikasına göre denetleyin. Bu; nefret söylemini, hakaretleri ve metin tabanlı diğer ihlalleri yakalar.

4. Otomatik onay. Tüm kontroller geçilirse varlık hemen görünür hâle gelir. Kontrollerden herhangi biri varlığı işaretlerse varlık inceleme kuyruğuna girer.

5. İnsan incelemesi. İşaretlenen varlıklar bir moderatör tarafından incelenir. Küçük bir platformda bunu ekip üstlenebilir. Ölçek büyüdüğünde ise sözleşmeli moderasyon hizmetleri kullanılabilir (sosyal medya içeriklerini denetleyen hizmetlerle aynı türde).

Mekânsal Moderasyon

Tek tek her nesne uygun olsa bile nesnelerin mekânsal düzeni uygunsuz olabilir. Bunu otomatik olarak tespit etmek daha zordur. Pratik yaklaşım şöyledir:

• Oyuncu bildirimleri. Her oyuncu bir konumu bildirebilir. Bildirim, bildirilen koordinatlarda otomatik olarak alınan bir ekran görüntüsünü ve bildiren oyuncunun hesabını içerir. Bildirimler insan incelemesini tetikler.
• Isı haritalama. Hangi alanların bildirim oluşturduğunu takip edin. Bir içerik üreticisinin parseli sürekli olarak bildirim alıyorsa incelemeyi üst seviyeye taşıyın. Bir içerik üreticisinin tekrar tekrar ihlalde bulunduğu tespit edilirse düzenleme izinlerini kısıtlayın.
• Parsel derecelendirmeleri. Second Life'ta olduğu gibi içerik üreticilerinin kendi parsellerini derecelendirmesine izin verin. Varsayılan görünüm, "Genel" seviyesinin üzerinde derecelendirilmiş parselleri gizler. Oyuncular yetişkinlere yönelik içerikleri görmeyi kendileri etkinleştirir. Bu, ihlalleri önlemez ancak maruz kalmayı azaltır.

Gecikmeyle İlgili Hususlar

Otomatik tarama varlık başına 5-10 saniye sürüyorsa bu, içerik üreticisinin bir nesneyi yerleştirmesiyle nesnenin diğer oyunculara görünmesi arasında fark edilir bir gecikme oluşturur. Seçenekler:

• İyimser yerel gösterim. İçerik üreticisi yerleştirdiği nesneyi hemen görür. Diğer oyuncular ise onaylandıktan sonra görür. Varlık reddedilirse kaybolur ve içerik üreticisine bildirim gönderilir.
• Önceden onaylanmış varlık kütüphanesi. Çoğu yerleştirme, platformun kütüphanesindeki önceden taranmış varlıkları kullanır (üretim sırasında taranan yapay zekâ üretimi varlıklar dâhil). Özel yüklemeler taramadan geçer. Böylece yerleştirmelerin çoğu anında gerçekleşir.
• İtibara dayalı hızlandırma. Daha önce onaylanmış içerikler üretmiş içerik üreticilerinin yeni yerleştirmeleri otomatik olarak onaylanır. Yeni veya işaretlenmiş içerik üreticileri tam taramadan geçer.

Tarayıcıda 3B Performansı: Gerçek Rakamlar

Teorik bütçeler faydalıdır. Gerçek ölçülmüş performans ise daha faydalıdır. Aşağıda, son kullanıcı donanımlarında çalışan tarayıcı tabanlı 3B sahnelerden elde edilmiş gerçek rakamlar yer alıyor.

Render Karşılaştırmaları

10.000 örneklenmiş nesne içeren Three.js sahnesi (ağaçlar, kayalar; her biri 500 üçgen):

• MacBook Pro M1 (Chrome, WebGL2): 58-60fps
• RTX 3060 masaüstü (Chrome, WebGL2): sabit 60fps
• Intel UHD 620 dizüstü (Chrome, WebGL2): 25-35fps
• iPhone 13 (Safari, WebGL2): 30-40fps

100.000 örneklenmiş çim yaprağı içeren Three.js sahnesi (her biri 6 üçgen, toplam 600 bin üçgen):

• M1 MacBook: 55fps
• RTX 3060: 60fps
• Intel UHD 620: 12fps
• iPhone 13: 15fps

1 milyon üçgen, 4 LOD seviyesi ve Havok fiziği içeren Babylon.js arazisi:

• M1 MacBook (WebGPU): 60fps
• M1 MacBook (WebGL2): 45fps
• RTX 3060 (WebGPU): 60fps
• RTX 3060 (WebGL2): 55fps

2 milyon splat içeren Gaussian splat sahnesi (gsplat.js aracılığıyla):

• M1 MacBook (WebGL2): 30fps
• RTX 3060 (WebGL2): 45fps
• RTX 3060 (WebGPU): 60fps

Bellek Ölçümleri

Minimal Three.js sahnesi (skybox, arazi, 100 nesne): 80-120 MB GPU belleği, 150-200 MB JS heap Havok fiziği içeren Babylon.js: 200-300 MB GPU belleği, 250-350 MB JS heap (Havok Wasm yaklaşık 50 MB ekler) Tarayıcı sekmesi bellek sınırları (ölçülmüştür, belgelenmemiştir):

• Masaüstü Chrome: genellikle yaklaşık 4 GB'de çöker
• Android Chrome: genellikle yaklaşık 1-1,5 GB'de çöker
• iOS Safari: genellikle yaklaşık 1 GB'de çöker
• Masaüstü Firefox: genellikle yaklaşık 3-4 GB'de çöker

Ağ Ölçümleri

WebSocket gidiş-dönüş gecikmesi (tarayıcıdan Cloudflare edge'e):

• Aynı kıta: 10-30ms
• Kıtalar arası: 80-200ms
• Cloudflare Durable Objects ile: ilk istekte DO'nun uyanması için 5-10ms ekleyin

WebRTC DataChannel gecikmesi (TURN üzerinden tarayıcıdan tarayıcıya):

• Aynı şehir: 5-15ms
• Aynı kıta: 20-50ms
• Kıtalar arası: 100-250ms

WebTransport (HTTP/3 QUIC) gecikmesi WebSocket ile benzerdir; ancak satır başı engelleme olmadığından P99 gecikmesi önemli ölçüde daha iyidir (tek bir kayıp paketten kaynaklanan duraklamalar yaşanmaz).

Yükleme Süresi Ölçümleri

Boş Three.js sahnesi (yalnızca kütüphane): ilk kareye kadar 350ms Boş Babylon.js sahnesi: ilk kareye kadar 500ms fetch + ayrıştırma ile 1 MB GLB modeli: geniş bantta 200-400ms KTX2 dokusu, 1024x1024, Basis Universal: GPU'da çözmek için 50-100ms Draco ile sıkıştırılmış mesh, 50 bin üçgen: Web Worker'da çözmek için 30-80ms

Bu rakamlar, mimari bölümündeki performans bütçesine ulaşılabileceğini doğruluyor. Orta sınıf bir masaüstü bilgisayar, karmaşık bir açık dünya sahnesini 60fps'de render edebilir. Kısıtlayıcı unsur mobil cihazlardır: telefonlarda 30fps'yi korumak için agresif LOD ve daha kısa görüş mesafesi gerekir.

Teknoloji Yığınının Tamamı

Tüm parçaları bir araya getirdiğimizde, tarayıcı tabanlı çok oyunculu bir içerik üretici açık dünyasının mimarisi şöyledir:

İstemci (Tarayıcı)

Katman	Teknoloji	Rol
Render sistemi	Babylon.js (WebGPU + WebGL2 fallback)	Sahne render'ı, arazi, LOD, son işleme
Arazi	Özel yükseklik haritası sistemi + Babylon DynamicTerrain	Splatting destekli, parça tabanlı akışlı arazi
Fizik	Rapier (Wasm) veya Havok (Babylon üzerinden)	Karakter denetleyicisi, çarpışma, ışın izleme
ECS	bitECS	Tüm dünya nesneleri için varlık yönetimi
Ağ	WebSocket + WebRTC DataChannel	Durum eşitleme, konum güncellemeleri, sesli sohbet
Durum	Yjs (CRDT)	Ortak dünya düzenleme, çakışma çözümü
Ses	Web Audio API	Mekânsal ses, ortam sesleri, müzik
Kullanıcı arayüzü	HTML/CSS katmanı	HUD, envanter, sohbet, içerik üretici araçları
Worker'lar	Web Workers	Varlık açma, fizik, arazi üretimi

Sunucu

Katman	Teknoloji	Rol
Dünya shard'ları	Cloudflare Durable Objects	Parça başına yetkili durum, WebSocket uç noktaları
Varlık depolama	Cloudflare R2	GLB modelleri, KTX2 dokuları, yükseklik haritaları, ses
Varlık CDN'i	Cloudflare CDN (R2 public bucket)	Dünya varlıklarının edge önbellekli dağıtımı
Yapay zekâ üretimi	GPU örnekleri (Hetzner/Lambda/RunPod)	3B model üretimi, arazi üretimi, doku üretimi
Varlık işlem hattı	Cloudflare Queue + Workers	LOD üretimi, mesh optimizasyonu, biçim dönüştürme
Kimlik doğrulama	Auth0	İçerik üretici kimliği, izinler
Veritabanı	Cloudflare D1	Dünya meta verileri, içerik üretici envanterleri, izinler
Gerçek zamanlı iletişim	Cloudflare Durable Objects + Pub/Sub	Oyuncu mevcudiyeti, sohbet, etkinlik yayını

Veri Akışı

1. Oyuncu dünyayı tarayıcısında açar
2. İstemci kimlik doğrulaması yapar ve doğma parçası için en yakın Durable Object'e bağlanır
3. DO, mevcut parça durumunu gönderir (arazi + nesneler + yakındaki oyuncular)
4. İstemci render işlemine başlar ve R2/CDN'den komşu parçaları ister
5. Oyuncu hareket ettikçe istemci komşu DO'lara bağlanır ve uzaktakilerle bağlantıyı keser
6. İçerik üreticisi bir nesne yerleştirir: istemci düzenlemeyi DO'ya gönderir, DO bunu doğrular ve CRDT deltası aracılığıyla bağlı tüm istemcilere yayınlar
7. DO, her düzenlemede parça durumunu depolamaya kalıcı olarak yazar (debounce uygulanarak)
8. Diğer oyuncular yeni nesnenin 100-200ms içinde belirdiğini görür

Performans Bütçesi

Orta sınıf bir masaüstünde (RTX 3060 / M1 Mac / 16GB RAM) 60fps deneyimi için:

Kaynak	Bütçe	Notlar
Draw call'lar	Kare başına < 500	Batching, instancing, LOD
Üçgenler	Kare başına < 2M	LOD bunu denetim altında tutar
Doku belleği	< 512 MB	KTX2 sıkıştırma, akış, atlas havuzlama
Geometri belleği	< 256 MB	Paylaşılan tamponlar, havuzlama, agresif boşaltma
JavaScript heap	< 512 MB	ECS nesneler yerine typed array'ler kullanır
Ağ	Sürekli < 500 KB/s	Delta sıkıştırma, mekânsal alaka filtreleme
İlk yükleme	< 10 MB, < 5 saniye	Aşamalı yükleme, önce arazi
Parça yükleme	< 200 KB, < 200ms	Komşu parçaları önceden getirme

Başarılı Tarayıcı Oyunları ve Kanıtladıkları

Tarayıcı oyunları niş bir alan değildir. Oyun sektörünün en büyük pazarlarından birini oluştururlar. Poki, ayda 100 milyondan fazla oyuncuya hizmet veriyor. CrazyGames, Newgrounds ve itch.io ise milyonlarca oyuncuya daha ulaşıyor. Tarayıcılarda başarılı olan oyunlar, incelenmeye değer belirli mimari kalıplara sahiptir.

Günümüzde Yayınlanmış Tarayıcı Tabanlı 3B Oyunlar

Hordes.io: Kalıcı bir 3B tarayıcı MMO'sunda 200'den fazla oyuncu. Özel WebGL, düşük poligonlu stil, 5 saniyeden kısa sürede yüklenir. Tek bir geliştirici tarafından yapılmıştır.

**Hordes.io**, tarayıcı MMO'ları arasında en alakalı örnektir. Özel WebGL işleme teknolojisi kullanan tek bir geliştirici tarafından yapılan oyun; 200'den fazla oyuncuyu gerçek zamanlı savaş, loncalar, sınıflar ve PvP içeren kalıcı bir 3D dünyaya yerleştiriyor. Oyunun tamamı 5 saniyeden kısa sürede yükleniyor. Dünya, görünmeyen öğelerin agresif biçimde ayıklandığı bölgelere ayrılmış. Oyuncu modelleri basit (düşük poligonlu ve düz gölgelendirmeli), ancak parçacık efektleri ve animasyonlar savaşın akıcı ve tepkisel hissettirmesini sağlıyor. Hordes.io üç şeyi kanıtlıyor: tarayıcı MMO'ları tek bir sahnede yüzlerce eş zamanlı oyuncuyu destekleyebilir, tek bir geliştirici böyle bir oyun yapabilir ve stilize grafikler tarayıcıda gerçekçi grafiklerden daha iyi performans gösterir.

Krunker.io: Aylık 10 milyon oyuncu, Three.js ile geliştirilmiş eksiksiz bir tarayıcı içi harita düzenleyicisi ve kullanıcı üretimi içerik pazarı.

Krunker.io, aylık 10 milyondan fazla oyuncuyla zirveye ulaştı ve FRVR tarafından satın alındı. Eksiksiz bir harita düzenleyicisi, özel oyun modları, kullanıcı üretimi içerikler ve bir pazar sunan tarayıcı tabanlı bir FPS'dir. Three.js ile geliştirilen oyun, bloklu görsel tarzı ve agresif optimizasyonu sayesinde düşük özellikli donanımlarda bile 60 FPS'nin üzerinde çalışır. Özellikle bölüm düzenleyicisi dikkate değerdir. Oyuncular voksel benzeri bir blok sistemiyle haritalar oluşturur, bunları pazarda paylaşır ve diğer oyuncular bu haritalarda oynar. Bu, üretici-dünya döngüsünün küçük ölçekli bir örneğidir: bir şey oluştur, paylaş, başkaları da onu deneyimlesin. Krunker, oluşturma araçları yeterince basit olduğunda kullanıcı üretimi 3D içeriğin tarayıcıda çalışabileceğini kanıtladı.

ev.io, Babylon.js ile geliştirilmiş bir tarayıcı FPS'sidir. Çoğu donanımda iyi çalışır, özel haritaları destekler ve Babylon'ın WebGL işleyicisinin bir tarayıcı sekmesinde hızlı tempolu 3D aksiyonu kaldırabildiğini gösterir. Oyun, performans bütçeleri içinde kalmak için agresif doku sıkıştırması ve düşük poligonlu ortamlar kullanır.

Shell Shockers (aylık 5 milyondan fazla oyuncu), yumurta olarak oynadığınız çok oyunculu bir 3D nişancı oyunudur. Three.js ile geliştirilen oyun, tarayıcıda hızlı tepki veren isabet algılamasıyla gerçek zamanlı çok oyunculu oynanışı destekler. Çizgi film tarzındaki görsel yaklaşım, cilalı görünümünü korurken varlık gereksinimlerini en aza indirir.

Townscaper: Binaları yerleştirmek için tıklarsınız; sistem sokakları, kemerleri ve merdivenleri otomatik olarak oluşturur. Menü yok, hedef yok. Yalnızca yaratmanın verdiği keyifle 1 milyondan fazla kopya sattı.

Townscaper bir tarayıcı oyunu değil, ancak dünya oluşturmaya yaklaşımı son derece alakalı. Oyuncular, su yüzeyine binalar yerleştirmek için tıklar. Oyun; yerleştirme düzenlerine göre mimari ayrıntıları, sokakları, kemerleri ve merdivenleri otomatik olarak oluşturur. Menü yok, ayar yok, hedef yok. Yalnızca tıklayın ve inşa edin. Oyun 1 milyondan fazla kopya sattı. Çıkarılacak ders şu: bazen en basit yaratıcı araçlar, en ilgi çekici deneyimleri üretir. Dünyaya nesne yerleştirmeyi Townscaper'daki kadar dolaysız hâle getirebilirsek üreticiler saatlerce inşa yapar.

A-Frame / 8th Wall deneyimleri. A-Frame (Three.js üzerine kurulmuştur), binlerce web tabanlı 3D deneyime güç verir. Niantic'in satın aldığı uzun soluklu WebAR platformu 8th Wall, karmaşık kamera tabanlı AR'nin mobil tarayıcılarda eklenti olmadan çalışabildiğini gösterdi; ancak Niantic, 2025'in sonlarında hizmeti kademeli olarak sonlandıracağını duyurdu (barındırılan deneyimler 2027'ye kadar yayında kalacak). Bunlar oyun değildir, ancak fizik ve etkileşim içeren karmaşık 3D işlemenin eklentiler olmadan bir tarayıcı sekmesinde çalıştığını gösterir. Bu deneyimlerin çoğu 2-3 saniyede yüklenir ve orta segment telefonlarda çalışır.

Vuntra City: Aktif Bir Prosedürel Şehir Laboratuvarı

Vuntra City, tarayıcı oyunu değil yerel bir UE5 projesidir; dolayısıyla teknoloji yığınımız için doğrudan bir performans ölçütü değildir. Yine de geliştirici günlükleri, gerçek üretim baskısı altında sistem tasarımında yapılan ödünleşimler konusunda alışılmadık ölçüde ayrıntılı olduğundan açık dünya mimarimiz için kamuya açık en yararlı vaka çalışmalarından biridir.

En güçlü çıkarımlardan biri, hıza duyarlı ayrıntı politikasıdır. Ulaşım ve optimizasyon videolarında yüksek hızlı hareket çatıların üzerine taşınırken hız arttıkça dünya ayrıntıları azaltılır; böylece akış yöneticisi iç mekânlardaki sürekli değişim yüzünden tıkanmaz (hızlı ulaşım, optimizasyon teknikleri). Bu yaklaşım, hızın önceden getirme yarıçapını, iç mekân etkinleştirme menzilini ve kare başına oluşturma bütçesini doğrudan kontrol etmesi gereken tarayıcı planımızla kusursuz biçimde örtüşüyor.

Bir diğer çıkarım, topoloji verileri ile işlenen nesnelerin kesin biçimde ayrılmasıdır. Harita ve adres uygulaması, yüklenmemiş bölgeler için konum ve adres sorgularını yanıtlayabilen küresel bir topoloji denetleyicisi kullanır (haritalar ve adresler). Bu, sunucu yetkili rota belirleme, ilgi noktası arama ve herhangi bir istemcinin o anda belleğinde bulunanlara bağlı olmaması gereken dünya düzeyindeki sorgular için tam olarak ihtiyaç duyduğumuz kalıptır.

NPC çalışmaları da son derece alakalıdır. Milyon NPC'li sistem, genel program durumunu küresel olarak hesaplar ve maliyetli davranışları yalnızca oyuncuya komşu alanlarda simüle eder (bir milyon kalıcı NPC, kamera arkası). Bu da bizim için iki katmanlı bir simülasyon modelini destekler: uzakta ucuz ve deterministik durum, AOI içinde ise zengin yakın alan davranışları.

Son olarak Vuntra City'nin çevre tasarımı, teknik planlamada unutulması kolay bir noktayı pekiştiriyor: dağılım tasarımı, içerik tasarımıdır. Proje, tekdüze rastgele yerleştirmeden kaçınıyor, sürpriz yaratmak için ağırlıklı aykırı değerler kullanıyor ve keşfi her yerde bulunan mini harita işaretleri yerine dünya içi haritalar ve adreslerle yönlendiriyor (prosedürel ortamların sıkıcı olması gerekmez, gideceğimiz yerde mini haritaya ihtiyacımız olmayacak).

Devasa Ölçeğe Ulaşan Tarayıcı Oyunları

Agar.io (2015), tarayıcı tabanlı çok oyunculu oyunların milyonlara ulaşabileceğini kanıtladı. Zirve döneminde sunucular genelinde 100.000'den fazla eş zamanlı oyuncuya sahipti. Oyun 2D'dir ve mekanik olarak basittir (daha küçük hücreleri emerek büyürsünüz), ancak ağ mimarisi uzamsal bölümleme sayesinde devasa eş zamanlılığı destekler. Her sunucu, oyun dünyasının bir bölgesini çalıştırır. Oyuncular yalnızca görüş alanlarındaki varlıklarla ilgili güncellemeleri alır. Bu, 3D açık dünya için gereken ilgi alanı yönetimi kalıbının 2D biçimidir.

Slither.io, Agar.io'nun başarısını temel alarak modelin ölçeklenebildiğini kanıtladı. Zirve döneminde aylık 67 milyon aktif kullanıcıya ulaştı. Oyun, gerçek zamanlı konum eşitlemesi için WebSocket ve ağ trafiğini sınırlamak için uzamsal bölümleme kullanır. Dikkate değer bir ayrıntı: Slither.io'nun sunucu tarafındaki çarpışma algılaması, uzaktaki oyuncular için (5 Hz) yakındaki oyunculara kıyasla (30 Hz) daha düşük bir tik hızında çalışır. Mesafeye göre değişen bu tik hızı, 3D açık dünyaya da uygulanabilir.

Surviv.io, Kongregate tarafından satın alınmadan önce aylık 50 milyon oyuncuya ulaşan tarayıcı tabanlı bir battle royale oyunuydu. Gerçek zamanlı ağ bağlantılı fizik, yok edilebilir ortamlar ve eşya toplama özellikleriyle 80 oyunculu eksiksiz bir battle royale karşılaşmasını tamamen tarayıcıda çalıştırıyordu. Harita, önceden tasarlanmış bina şablonlarından prosedürel olarak düzenleniyordu; bu, üreticilerin yerleştirdiği yapılar için kullanabileceğimiz bir kalıptır.

Zombs Royale, hızlı yükleme süreleri ve tepkisel ağ iletişimiyle 100 oyunculu bir battle royale oyununu tarayıcıda çalıştırdı. Surviv.io gibi o da gerçek zamanlı tarayıcı oyunlarındaki yüksek oyuncu sayılarının yalnızca teknik açıdan mümkün değil, ticari açıdan da uygulanabilir olduğunu kanıtladı.

Bu başarılı tarayıcı oyunlarının ortak noktaları şunlardır: hızlı yüklenirler (5 saniyeden kısa sürede), her cihazda çalışırlar, görsel tarzları basit ama tutarlıdır ve ağ iletişimleri belirli oynanış için optimize edilmiştir (uzamsal bölümleme, değişken güncelleme hızları ve uzaktaki durumların agresif biçimde ayıklanması).

RuneScape: Tarayıcıya Taşınan Bir MMO

RuneScape: Bir tarayıcı sekmesinde çalışan, 20 yılı aşkın içeriğe sahip eksiksiz bir MMO. Özel ikili protokol, karo tabanlı akış ve sunucu başına 2.000 eş zamanlı oyuncu. Tarayıcı MMO'larının büyük ölçekte çalıştığının kanıtı.

RuneScape, tarayıcı tabanlı açık dünya için en önemli vaka çalışmasıdır; çünkü bu gerçekten yapıldı. Jagex, 20 yıllık içeriğe sahip eksiksiz bir MMO'yu tarayıcıya taşıdı.

RuneScape başlangıçta Java uygulamacığı olarak çalışıyordu. Tarayıcılar Java desteğini bıraktığında Jagex, istemciyi C++ ile yeniden geliştirdi ve ayrıca tam işlevli bir HTML5/WebGL istemcisi yayımladı. Old School RuneScape (retro sürüm) artık Emscripten aracılığıyla WebAssembly'ye derlenen bir istemciyle tamamen tarayıcıda çalışıyor. Oyun; geniş kalıcı dünyaları, sunucu başına yüzlerce oyuncuyla gerçek zamanlı çok oyunculu oynanışı, işlevsel bir büyük takas borsasına (müzayede evi) sahip ekonomiyi ve derin ilerleme sistemleri sunan 23 beceriyi destekliyor.

Önemli teknik ayrıntılar:

• Dünya, harita karelerine (64x64 karoluk bölgeler) ayrılmıştır. İstemci, oyuncunun etrafında 13x13'lük bir bölge ızgarası yükler (104x104 karo görünür). Bu ızgaranın dışındaki bölgeler tamamen ayıklanır.
• Arazi, her karo köşesi için yükseklik değerleri bulunan karo tabanlı bir sistem kullanır. Arazi kaplamaları (yollar, su kenarları, kumsal geçişleri), şekil başına 12 döndürme varyantı içeren bir şekil sistemi kullanır. Bu, bir yükseklik haritasından daha kısıtlıdır; ancak son derece kompakt ve akışla aktarılması hızlıdır.
• Ağ protokolü, WebSocket üzerinden çalışan özel bir ikili protokoldür. Her paket türünün tanımlanmış bir yapısı vardır. Oyuncu konumu güncellemeleri, harita karesi koordinatları için 2 bayt ve hareket türü için değişken uzunluklu kodlama kullanır. Sohbet, ticaret ve savaş olaylarının kendilerine ait kompakt ikili biçimleri vardır. Protokolün tamamı, bant genişliğini en aza indirmek için yoğun biçimde optimize edilmiştir.
• Nesne işleme, sunucunun bir model kimliği gönderdiği ve istemcinin önbelleğe alınmış modeli işlediği bir model sistemi kullanır. Çoğu model bir kez yüklenir ve yeniden kullanılır. Bu, dünyanın geometri akışı yerine meta veri olarak (hangi modelin nereye yerleştirileceği) aktarıldığı anlamına gelir.
• Her sunucu örneği, tüm oyun dünyasında 2.000 eş zamanlı oyuncuyu destekler. Dünya uzamsal olarak parçalara ayrılmamıştır. Tek bir sunucu işlemi; tüm oyuncuları, tüm NPC'leri ve tüm oyun mantığını 600 ms'lik oyun tikleriyle yönetir. Bu mümkündür çünkü her tikteki oyun mantığı basittir: oyuncu eylemlerini işle, NPC yapay zekâsını güncelle, savaş sonuçlarını hesapla ve durum değişikliklerini yayımla.

RuneScape'in bizim durumumuz için kanıtladıkları: Kalıcı dünya durumuna, binlerce oyuncuya, karmaşık oyun sistemlerine ve gerçek bir ekonomiye sahip eksiksiz bir MMO, tarayıcı sekmesinde çalışabilir. İstemcinin indirme boyutu 50 MB'ın altındadır, birkaç saniyede yüklenir ve dizüstü bilgisayarlarda çalışır. 20 yıllık bir Java MMO'su bu geçişi yapabiliyorsa amaca yönelik geliştirilmiş bir tarayıcı dünyası daha da az kısıtlamayla karşılaşır.

RuneScape'in yaklaşımının uymadığı noktalar: RuneScape'in görüntülemesi birinci/üçüncü şahıs 3D değil, izometrik/sabit kameralıdır. Görsel kalitesi modern standartlara göre düşüktür. Ayrıca dünya üreticiler tarafından düzenlenemez. Ancak ağ mimarisi, karo tabanlı akış sistemi ve tarayıcı MMO'larının oyuncuları onlarca yıl boyunca elde tutabildiğinin kanıtı doğrudan alakalıdır.

Habbo Hotel: 25 Yıl Dayanan Sosyal Alanlar

Habbo Hotel 2000 yılında kullanıma sunuldu ve hâlâ çalışıyor. Kullanıcıların odalar oluşturup dekore ettiği, başkalarının odalarını ziyaret ettiği ve sosyalleştiği 2D izometrik bir sosyal dünyadır. Zirve döneminde aylık 9 milyon kullanıcıya sahipti. Deneyimin tamamı Flash üzerinde çalışıyordu (Flash'ın kullanımdan kaldırılmasının ardından artık HTML5 kullanıyor).

Habbo, bir üretici topluluğunu ne kadar uzun süre ayakta tuttuğu için önemlidir. Oda sistemi, aslında geliştirdiğimiz şeyin 2D sürümüdür: kullanıcılar mobilya nesnelerini bir ızgaraya yerleştirir, düzeni özelleştirir ve başkalarını ziyarete davet eder. Ekonomik model (kullanıcılar gerçek parayla sanal mobilyalar satın alır), toplamda 1 milyar doların üzerinde gelir elde etmiştir.

Habbo'nun öğrettikleri:

• Kullanıcıların oluşturduğu iç mekânlara sahip oda tabanlı alanlar, oluşturma araçları basit ve sosyal özellikler güçlü olduğu sürece onlarca yıl boyunca sosyal platform olarak çalışabilir.
• Sanal mobilya ekonomisi, uzun vadeli etkileşimi sürdürür. Kullanıcılar eşyaları satın alır, takas eder ve biriktirir. Eşyaların oynanış açısından hiçbir faydası yoktur. Tamamen kendini ifade etme ve statü içindir.
• Sosyal alanlarda moderasyon sürekli yatırım gerektirir. Habbo birden fazla moderasyon krizi yaşadı. Otomatik içerik filtreleme, insan moderatörler ve topluluk bildirimlerinin birlikte kullanılması, uygulanabilir asgari yaklaşımdır.
• Flash'tan HTML5'e geçiş (yaklaşık 2020-2021'de tamamlandı), büyük bir sosyal dünyanın topluluğunu kaybetmeden görüntüleme teknolojisini değiştirebileceğini kanıtladı. Kullanıcılar temel teknolojiye değil, odalarına ve arkadaşlarına önem verir.

Among Us ve Uzamsal Sosyal Oyunlar

Among Us bir açık dünya değildir, ancak başarısı çok oyunculu alanlar hakkında önemli bir şeyi ortaya çıkardı: oyuncular yalnızca birlikte oyun oynamak değil, birlikte aynı yerde bulunmak istiyor. Viral olan uzamsal yakınlık sohbeti modları, yönlü sesle aynı sanal odada bulunmanın çok oyunculu deneyimi bir oyun mekaniğinden sosyal deneyime dönüştürdüğünü gösterdi. Bir üretici dünyasını zenginleştiren mekânsal sosyal özellikler:

• Yakınlık tabanlı sesli sohbet, mesafe arttıkça ses seviyesini azaltır. Konuşmak için birinin yanına gidin. Uzaklaştığınızda sesi giderek azalır. Bu, ses kanallarını yönetmeye gerek kalmadan doğal sosyal gruplar oluşturur.
• İfade ve jest sistemleri, oyuncuların ses kullanmadan kendilerini ifade etmelerini sağlar. El sallama, dans veya işaret etme hareketi. Bunların uygulanması kolaydır (oyuncu avatarındaki animasyonlar) ve sosyal etkileşimi maliyetlerine kıyasla çok daha fazla artırırlar.
• Dünya içinde gerçekleşen ortak etkinlikler (menüler üzerinden değil), bir alanı buluşma mekânına dönüştürür. İki üretici sanal bir masaya oturup 3B modelleri birlikte inceleyebiliyorsa dünya, statik içerik sergilemenin ötesinde bir varlık nedenine sahip olur.

Poki ve CrazyGames'de Ölçeklenen Tarayıcı Oyunları

Poki ve CrazyGames birlikte ayda 150 milyondan fazla oyuncuya hizmet veriyor. Bu platformlarda en iyi performansı gösteren oyunlar, özellikle tarayıcıda nelerin işe yaradığına dair önemli ipuçları sunuyor.

Tarayıcı oyun portallarında en iyi performans gösteren kalıplar:

• Anında oynama (3 saniyeden kısa sürede etkileşime geçebilme). Giriş yapmak gerekmez. Eğitim gerekmez. Oyunun, açıldıktan sonraki 5 saniye içinde anlaşılır olması gerekir.
• Esnek oturum süreleri. Oyuncular 2 dakikalığına da 2 saatliğine de katılabilir. Oyun her ikisine de uyum sağlar. Bir üretici dünyası için bu, dünyayı keşfetmek üzere uzun bir oturuma bağlı kalmanın gerekmemesi demektir. Etrafta dolaşın, ilginç şeyler görün ve çıkın. Ya da kalıp saatlerce inşa edin.
• Mobil uyumluluk. Poki trafiğinin %60'ından fazlası mobilden geliyor. Yalnızca masaüstünde çalışan bir tarayıcı dünyası, potansiyel ziyaretçilerin çoğunu kaybeder.
• Arkadaş gerektirmeyen sosyal özellikler. Liderlik tabloları, diğer oyuncuların içeriklerine tepki verme ve eşzamansız özellikler (aynı anda çevrimiçi olmadan diğer oyuncuların neler inşa ettiğini görme).

Bu portallardaki en başarılı 3B oyunlar (Shell Shockers, 1v1.LOL ve Smash Karts gibi) poligon sayısını düşük, dokuları basit ve kare hızını yüksek tutar. Deneyim akıcı ve duyarlı olduğu sürece oyuncuların basit grafikleri kabul ettiğini kanıtlarlar.

Tarayıcı Tabanlı Üretici Platformları

Mozilla Hubs (artık topluluk tarafından sürdürülüyor). Three.js ve A-Frame üzerine kurulu, tarayıcıda çalışan çok kullanıcılı 3B alanlar. Sesli sohbeti, avatarları ve paylaşılan nesneleri destekler. Açık dünya değildir (oda tabanlıdır), ancak ağ ve görüntüleme mimarisi konuyla ilgilidir. Mozilla, barındırılan hizmeti kapatmadan önce projeyi açık kaynak hâline getirdiğinden kod tabanının tamamı incelenebilir. GitHub.

Hyperfy. Tamamen tarayıcıda çalışan, web tabanlı bir metaverse platformu. Three.js ile görüntüleme, çok oyunculu özellikler, avatar özelleştirme ve dünya inşası sunar. Üretici araçlarını öne çıkardığı için hedefimize Hubs'dan daha yakındır. Dünyalar herhangi bir indirme gerektirmeden bir tarayıcı sekmesinde yüklenir. hyperfy.io.

Ethereal Engine (eski adıyla XREngine). Three.js ve bitECS üzerine kurulu, çok kullanıcılı dünyalara yönelik açık kaynaklı bir motor. WebXR'ı, mekânsal sesi ve dünya düzenlemeyi destekler. Yerleşik ECS mimarisi, ağ katmanı ve düzenleyici araçları vardır. Tarif ettiğimiz şeye en yakın mevcut açık kaynaklı projedir. Varlık yönetimi için bitECS'yi Three.js ile nasıl bütünleştirdiklerini ve ağ sistemlerinin mekânsal durumu nasıl ele aldığını incelemeye değer. GitHub.

Dusk (eski adıyla Rune). Web oyunları için çok oyunculu oyun SDK'sı. Geliştiricilerin oynanışa odaklanabilmesi için ağ katmanını yönetir. Durum eşitleme yaklaşımı, duyarlı çok oyunculu oyunların standart modeli olan sunucu uzlaştırmalı tahminî durumu kullanır. SDK, geri sarma tabanlı ağ kodunun karmaşıklığını soyutlar. Geliştirici deneyimi açısından incelenmeye değer.

Niantic Studio. Başkalarının tarayıcıda ziyaret edebileceği 3B ve XR deneyimleri oluşturmaya yönelik, tarayıcı tabanlı görsel bir düzenleyici ve web oyun motorudur (8th Wall araçlarının devamı). Araçlar anlaşılır olduğunda teknik bilgisi olmayan üreticilerin de tarayıcıda 3B sahneler oluşturabileceğini gösterir. (Niantic, coğrafi mekânsal çalışmalarını Niantic Spatial adıyla ayırdı ve Pokemon GO dâhil oyun işini 2025'te Scopely'ye sattı.)

PlayCanvas Editor. Başlı başına bir oyun değildir, ancak PlayCanvas'ın bulut tabanlı 3B düzenleyicisi, ortak dünya inşa araçlarının tarayıcıda çalışabileceğini gösterir. Birden fazla ekip üyesi aynı sahneyi eşzamanlı olarak düzenleyebilir. Düzenleyici, değişiklikleri gerçek zamanlı bir eşitleme katmanı üzerinden iletir. İhtiyacımız olan iş birliğine dayalı üretim modeli budur; tek fark, oyun düzenleyicisi yerine dünyamızın tuval olmasıdır.

Yerel Üretici Platformları (Tarayıcı İçin Dersler)

Bu platformlar yerel uygulamalar olarak çalışsa da üretici araçları, dünyanın kalıcılığı ve sosyal dinamiklerle ilgili tasarım kararları doğrudan uygulanabilir.

Roblox: Günlük 80 milyondan fazla kullanıcı, 2023'te üreticilere ödenen 740 milyon dolar. Üretim motor içinde gerçekleşir. Keşif sosyaldir. Üretici platformlarının kendi kendini sürdürebileceğini kanıtlayan iş modeli.

Roblox, bir üretici dünyası için açık ara en önemli referanstır. Günlük 80 milyondan fazla aktif kullanıcıya sahiptir. Üreticiler, diğer oyuncuların ziyaret ettiği eksiksiz 3B deneyimler (oyunlar, sosyal alanlar ve mağazalar) oluşturur. Platform; barındırma, ağ, keşif ve para kazanma süreçlerini yönetir.

Roblox'un doğru yaptığı şeyler:

• Üretim motor içinde gerçekleşir. Roblox Studio, oyuncuların deneyimlediği ortamla aynıdır. Üreticiler çalışmalarını anında test eder. Dışa aktarma/yükleme/bekleme döngüsü yoktur. Bir tarayıcı dünyasında düzenleyici, dünyanın kendisi olmalıdır.
• Betik yazımı erişilebilirdir. Lua (Roblox'un betik dili), çocukların öğrenebileceği kadar basittir. Karmaşık davranışlar mümkündür ancak zorunlu değildir. Başlangıç eşiği düşük, potansiyel sınırı yüksektir.
• Keşif sosyaldir. Deneyimleri, arkadaşlarınız oynadığı için bulursunuz. Ana sayfa, trend olan deneyimleri gösterir. Bir tarayıcı dünyasında keşif yüzeyi, dünyanın kendisidir. Etrafta dolaşarak keşfeder ve bir şeyler bulursunuz.
• Para kazanma sistemi işler. Üreticiler gerçek para kazanır (Roblox, 2023'te üreticilere 740 milyon dolar ödedi). Bu, ciddi bir yaratıcı çabayı teşvik eder. Ekonomik teşvik olmadan üretici platformları, zamanla sönüp giden hobi projelerine dönüşür.
• Roblox'un görüntüleme motoru özeldir ve tarayıcıda değil, yerel bir uygulamada çalışır. Ancak deneyim başına varlık bütçeleri modern standartlara göre makuldür (önerilen üst sınır 100 MB). Başarılı Roblox deneyimlerinin çoğu, tarayıcıda görüntüleme kısıtlamalarıyla uyumlu olan düşük poligonlu, stilize görseller kullanır.

Fortnite Creative / UEFN (Unreal Editor for Fortnite). Epic, Unreal Engine'in tam düzenleyicisini Fortnite üreticilerine sundu. Sonuç olarak insanlar, profesyonel düzeyde araçlarla adalar (bağımsız dünyalar) oluşturabildiği bir platform ortaya çıktı. Fortnite; barındırma, çok oyunculu özellikler ve dağıtım süreçlerini yönetir.

İlgili çıkarımlar:

• Profesyonel araçlar, profesyonel içerikleri çeker. Üreticiler UE5'in tüm yeteneklerine erişebildiği için UEFN görsel açıdan etkileyici deneyimler ortaya çıkarır. Bunun bedeli karmaşıklıktır. UEFN'in öğrenme eğrisi diktir.
• Ada tabanlı örnekleme (her üretimin ayrı bir dünya olması), tek bir paylaşımlı dünyanın denetim ve çatışma sorunlarını önler. Ancak bu aynı zamanda üreticilerin keşif sırasında birbirlerinin çalışmalarını doğal biçimde bulamadığı anlamına gelir. Adaları yürüyerek değil, menüler üzerinden ziyaret edersiniz.
• İş modeli işler. Fortnite'ın üretici programı, etkileşim düzeyine göre ödeme yapar. En başarılı üreticiler yılda milyonlar kazanır. Ekonomik teşvik burada da kaliteyi artırır.

Dreams (Media Molecule / PlayStation). Dreams, konsol oyuncularına eksiksiz bir 3B üretim araç paketi (modelleme, animasyon, müzik, mantık ve seviye tasarımı) ile üretimleri paylaşabilecekleri bir platform sundu. Araç derinliği açısından bugüne kadar geliştirilmiş en iddialı üretici platformudur.

İlgili çıkarımlar:

• Poligon düzenleme yerine heykel tabanlı modelleme. Üreticiler, ZBrush'a benzeyen ancak daha sezgisel olan taşıma/tutma/yumuşatma araçlarıyla yumuşak hacimleri şekillendirir. Öğrenme eğrisi hafiftir. Bu yaklaşım, köşeleri ve UV haritalarını anlamayı gerektirmediği için tarayıcı içi üretime uygundur.
• Her şey paylaşılan bir varlıktır. Birisi bir ağaç modeli oluşturursa herkes bunu kendi üretiminde (atıfla) kullanabilir. Böylece her üretimin platformu daha değerli kıldığı, katlanarak büyüyen bir yaratıcı ekosistem oluşur.
• Dreams, eleştirmenlerin övgüsüne rağmen ticari açıdan zorlandı. Sorun dağıtımdı: PlayStation'a bağlıydı ve üretim araçları o kadar derindi ki çoğu oyuncu hiçbir zaman içerik tüketmenin ötesine geçmedi. Çıkarılacak ders şudur: Üretim araçları, kullanıcıların yalnızca küçük bir bölümü ciddi inşacılara dönüşse bile çoğunluğun bunları deneyeceği kadar basit olmalıdır.

Core (Manticore Games). Unreal Engine üzerine kurulu, basitleştirilmiş bir düzenleyiciyle çok oyunculu oyunlar oluşturup oynamaya yönelik ücretsiz bir platformdur. Core'un düzenleyicisi yerel uygulama olarak çalışır, ancak yaklaşımı konuyla ilgilidir. Şablonlar ve topluluk tarafından paylaşılan betikler, yeni başlayanların önceden hazırlanmış bileşenlerden oyunlar oluşturmasını sağlar. İleri düzey üreticiler, özel davranışlar için Lua betikleri yazabilir. Core, kısmen oyunların Core başlatıcısı üzerinden oynanmak zorunda olması nedeniyle geniş bir kitleye ulaşmakta zorlandı. Tarayıcı tabanlı bir sürümde bu engel olmazdı.

VRChat ve Rec Room, üreticilerin başkalarının ziyaret ettiği alanlar oluşturduğu sosyal platformlardır. VRChat Unity kullanır ve PC/VR'da çalışır. Rec Room ise mobil dâhil her yerde çalışır. Her ikisi de kullanıcı üretimi 3B dünyaların büyük toplulukları sürdürebileceğini kanıtlar. VRChat teknik açıdan daha etkileyicidir (özel gölgelendiriciler ve karmaşık avatarlar). Rec Room ise daha erişilebilirdir (uygulama içi üretim araçları, daha basit grafikler ve daha geniş platform desteği). Bir tarayıcı dünyası için Rec Room'un basit uygulama içi üretim araçları yaklaşımı, VRChat'in haricî araçlara dayalı iş akışından daha uygundur.

Second Life: 2003'te kullanıma sunuldu, günlük 200 binden fazla kullanıcıyla hâlâ çalışıyor. Tamamen kullanıcılar tarafından oluşturuldu. Parsel tabanlı mülkiyet, yılda yaklaşık 500 milyon dolar değerinde sanal ekonomi. Kalıcılık ve denetim konusunda 20 yıllık dersler.

Second Life, tüm üretici dünyalarının atasıdır. 2003'te kullanıma sunulan platform, günlük 200 binden fazla aktif kullanıcıyla hâlâ çalışıyor. Dünyanın tamamı kullanıcılar tarafından oluşturulmuştur. Araziler alınıp satılır. Üreticiler nesneler, giysiler ve binalar satar. Dünya içi betik dili (LSL), etkileşimli içerikleri mümkün kılar.

Second Life'ın 20 yılı aşkın sürenin ardından öğrettikleri:

• Kalıcılık, grafiklerden daha önemlidir. Second Life'ın görselleri eskimiştir, ancak dünya kalıcıdır. Üretimler yerleştirdiğiniz yerde kalır. İlişkiler ve geçmiş zamanla birikir. İnsanların geri gelmesini sağlayan şey bu kalıcılıktır.
• Ekonomi, üretimi teşvik eder. Second Life'ın GSYİH'sinin yılda 500 milyon dolar olduğu tahmin ediliyor. Üreticiler satış yapabildikleri için üretir. Ekonomik teşvik olmadığında üretici içeriklerinin hacmi ve kalitesi düşer.
• Kullanıcı üretimi içerik, denetim altyapısı gerektirir. Second Life, 20 yıldır denetim sorunlarıyla uğraşıyor. Kullanıcıların paylaşımlı bir alana istedikleri içerikleri yerleştirebildiği her platform; otomatik tarama, bildirim araçları ve insan incelemesi gerektirir.
• Arazi tabanlı mekânsal düzenleme işe yarar. Second Life, dünyasını kullanıcıların sahip olduğu parsellere ayırır. Her parselin bir prim (nesne) sınırı vardır. Bu, herhangi bir üreticinin tüm kaynakları tüketmesini doğal olarak önler. Bir tarayıcı dünyasında bunun karşılığı, öbek tabanlı mülkiyet ve öbek başına nesne bütçeleridir.

Karşılaştırmalı Analiz: Her Oyun Bize Ne Öğretiyor?

Oyun	Temel Ders	Uygulanabilir Teknoloji	Göz Ardı Edilirse Risk
Skyrim	Hücre ızgarasıyla parça tabanlı akış	Yükseklik haritalı arazi, LOD katmanları, iç/dış mekân ayrımı	Dünya tarayıcı belleğine sığmaz
The Witcher 3	Ayrı ekiplerce oluşturulan katmanlı dünya kompozisyonu	İçeriğe duyarlı akış, impostor render etme	İçerik üreticileri bağımsız çalışamaz
Breath of the Wild	Sistemik kurallar, betiklenmiş içerikten daha etkilidir	Malzeme etkileşim sistemi, fizik tabanlı oynanış	Dünya durağan ve cansız hissettirir
GTA V	Ortam yaşamı, dünyaların gerçek hissettirmesini sağlar	NPC davranış sistemleri, trafik, günün saati	İçerik üreticisinin dünyası boş bir müze gibi hissettirir
Elden Ring	Yoğunluk çeşitliliği ve varlıkların yeniden kullanımı	Modüler varlık kütüphanesi, seyrek ve yoğun bölgeler	Dünya ya fazla boş kalır ya da doldurulması çok pahalı olur
No Man's Sky	Tuval için prosedürel üretim, ruh için içerik üreticisi içeriği	Seed tabanlı arazi, kompakt üs veri modeli	Sonsuz ama sıkıcı arazi
Minecraft	Tamamen düzenlenebilir dünya, basit araçlar, sonsuz derinlik	Parça akışı, palet sıkıştırması, blok düzenleme protokolü	İçerik üreticileri dünyanın kendisini yeniden şekillendiremez
Roblox	Üretim motor içinde yapılır, ekonomi kaliteyi artırır	Dünya içi editör, içerik üreticisi para kazanma sistemi	Üretmek için bir neden olmadığından kimse bir şey inşa etmez
Krunker.io	Tarayıcı tabanlı kullanıcı üretimi içerik, basit araçlarla büyük ölçekte çalışır	Three.js render sistemi, voksel tabanlı editör, pazar yeri	Üretim araçları sıradan içerik üreticileri için fazla karmaşık olur
Hordes.io	Tarayıcıda 200'den fazla oyunculu 3D deneyim, tek geliştiriciyle uygulanabilir	Özel WebGL, uzamsal ayıklama, stilize görsel tasarım	Çok oyunculu katman gereğinden fazla karmaşıklaştırılır
Vuntra City (yerel referans)	Hıza duyarlı akış ve iki katmanlı dünya simülasyonu, devasa bir prosedürel şehri tutarlı kılar	Hıza bağlı LOD politikası, topoloji sorgu katmanı, uzak alan zaman çizelgesi simülasyonu + yakın alan davranışı	Yüksek hızlı hareket, ani belirmelere ve simülasyon yükü sıçramalarına yol açar
Agar.io / Slither.io	Uzamsal bölümleme, devasa eşzamanlılığı mümkün kılar	Mesafeye göre değişken tick hızı, ilgi alanı yönetimi	Ağ, büyük ölçekte çöker
Second Life	Kalıcılık ve ekonomi, 20 yıllık toplulukların devamlılığını sağlar	Parsel tabanlı sahiplik, nesne bütçeleri, pazar yeri	Uzun vadeli kullanıcı tutma sağlanamaz
Dreams	Heykel tabanlı üretim, poligon düzenlemekten daha sezgiseldir	Hacim tabanlı modelleme, ortak varlık kütüphanesi	Üretim araçları bir CAD programı gibi hissettirir
Fortnite Creative	Profesyonel araçlar, profesyonel içerikleri çeker	Platform içinde eksiksiz editör yetenekleri	İçerik kalitesinin üst sınırı çok düşük kalır
RuneScape	Wasm ve ikili protokoller sayesinde eksiksiz bir MMO tarayıcıda çalışabilir	Emscripten, özel ikili WebSocket protokolü, karo akışı	Tarayıcıların nelerin üstesinden gelebileceği küçümsenir
Habbo Hotel	Basit oda oluşturma, 25 yıllık bir topluluğu ayakta tutar	Izgara tabanlı yerleştirme, sanal mobilya ekonomisi	Üretim araçları gereğinden fazla karmaşıklaştırılır

Bizim özel durumumuz (tarayıcı tabanlı, içerik üreticisi odaklı ve çok oyunculu) açısından en önemli oyunlar Minecraft (düzenlenebilir dünya, kompakt veri), Roblox (motor içi üretim, ekonomi), Krunker (büyük ölçekte tarayıcı tabanlı kullanıcı üretimi içerik) ve Hordes.io'dur (tarayıcı MMO mimarisi). AAA oyunlar (Skyrim, BotW, Witcher 3) render ve akış konusunda dersler sunar. Tarayıcı hitleri (Agar.io, Slither.io, Surviv.io) büyük ölçekli ağ mimarisini öğretir. İçerik üretici platformları (Roblox, Dreams, Second Life) topluluk dinamiklerini öğretir. Vuntra City ise modern bir prosedürel şehirde hıza duyarlı akış, diegetik navigasyon ve milyonlarca ajanı kapsayan simülasyon kalıpları için güncel, uygulama düzeyinde bir referans sağlar.

Skyrim ve The Witcher Tarayıcıda Nasıl Görünürdü?

Somutlaştıralım. Skyrim'deki Whiterun'ı alıp tarayıcı üzerinden sunulacak şekilde yeniden inşa etseydiniz:

Arazi: Whiterun çevresindeki alan yaklaşık 2 km x 2 km'dir. Bizim parça boyutumuzla (64 m) bu, yaklaşık 32x32 = 1024 parça eder. Her parçanın yükseklik haritası 2-4 KB olduğunda toplam arazi verisi 2-4 MB olur. KTX2 atlas karoları olarak sunulan arazi dokuları (çim, toprak, kaya, kar) buna 5 MB daha ekleyebilir. Toplam arazi verisi: bölgenin tamamı için 10 MB'tan az.

Yapılar: Whiterun'ın kendisinde yaklaşık 40-50 bina bulunur. Optimize edilmiş birer GLB olarak sunulan her bina (3 LOD seviyesiyle) en yüksek ayrıntı düzeyinde 200-500 KB olabilir. Ancak tam ayrıntıya yalnızca en yakın 5-10 bina için ihtiyacınız vardır. Geri kalanlar orta veya düşük LOD seviyesinde olur (her biri 50-100 KB). Herhangi bir anda görünen yapıların toplamı: 2-5 MB.

Bitki örtüsü: Skyrim'de Whiterun çevresindeki ağaçların ve çimlerin tümü örneklenerek oluşturulur. Belki 10 benzersiz ağaç modeline (tam LOD seviyesinde her biri 200 KB, billboard impostor olarak 20 KB) ve GPU üzerinde bir yoğunluk haritasından çim yaprakları üreten bir sisteme ihtiyacınız olur. Toplam bitki örtüsü varlıkları: 2-3 MB. 5x5 parçalık bir alanın örnekleme verisi (konumlar, dönüşler, ölçekler): 500 KB'tan az.

NPC'ler: Whiterun'da yaklaşık 70 isimli NPC ve ayrıca muhafızlar bulunur. Orta kalitedeki her avatar: 100-200 KB. Ancak herhangi bir anda bunların yalnızca 10-20'si görünür. Toplam NPC render verisi: 2-4 MB.

Herhangi bir anda görünen Whiterun ölçeğindeki bir alanın genel toplamı: 15-25 MB. Bu, bir tarayıcı için kesinlikle uygulanabilir. İlk yüklemede arazi ve başlıca yapılar geniş bant bağlantıda 3-5 saniye içinde görünür, ayrıntılar ise sonraki birkaç saniye boyunca tamamlanır.

The Witcher 3'teki Novigrad daha büyük ve yoğundur, ancak aynı ilkeler geçerlidir. Daha agresif LOD ve akış gerekir, fakat herhangi bir anda görünen toplam veri tarayıcı belleği sınırları içinde kalır.

İlk Olarak Ne İnşa Ederdik?

Eksiksiz bir açık dünya, yıllar süren bir projedir. İçerik üreticilerinin eline hızla gerçek bir şey ulaştırmanın yolu şöyle:

Aşama 1: Paylaşımlı Ada (3 ay). Yükseklik haritalı arazi, su, temel bitki örtüsü ve gece/gündüz döngüsü içeren tek bir arazi parçası (512x512 m'lik ada). Durable Objects üzerinden çok oyunculu deneyim (50'ye kadar eşzamanlı kullanıcı). İçerik üreticileri, mevcut Cinevva kütüphanelerindeki yapay zekâyla üretilmiş 3D varlıkları yerleştirebilir. Bunu paylaşımlı bir diorama olarak düşünün.

Aşama 2: Genişletilebilir Dünya (3 ay). 4x4 km'lik bir dünya için parça akışı. İçerik üreticilerinin düzenleme iznine sahip olduğu, kendilerine ait arsalar. Arazi ve nesneler için LOD sistemi. Kalıcı dünya durumu. Dünya genelinde 200'e kadar eşzamanlı kullanıcı.

Aşama 3: Yaşayan Dünya (6 ay). Yapay zekâ destekli arazi şekillendirme. Prosedürel bitki örtüsü ve atmosfer. İçerik üreticilerinin yalnızca statik sahneler değil, etkileşimli deneyimler de oluşturabilmesi için görev/etkinlik sistemi. Sesli sohbet. Avatar özelleştirme. Dünya, bir demo olmaktan çıkıp ziyaret edilmek istenen bir yere dönüşür.

Açık Sorular

Görsel tarz. Stilize yaklaşımın (düşük poligonlu, cel-shaded) render maliyeti daha düşüktür ve yapay zekâyla üretilmiş varlıklardaki kusurları daha iyi tolere eder. Gerçekçi yaklaşım ise daha yüksek kaliteli varlıklar ve daha fazla render bütçesi gerektirir. Skyrim, eskimiş grafiklerine rağmen görsel yönü tutarlı olduğu için başarılı oldu. BotW, cel-shaded tarzı düşük poligon sayılarını gizlediği için tablet sınıfı donanımlarda muhteşem görünür. Minecraft 16x16 dokular kullanır ve tüm zamanların en kolay tanınan oyunlarından biridir. Krunker.io ve Hordes.io da tarayıcıda basit, stilize grafiklerle başarılıdır. Kanıtlar ezici biçimde tarayıcı dünyası için stilize bir yönü destekliyor. Belirli bir görsel kimliği erkenden seçmeli ve yapay zekâyla üretilen tüm varlıklarda tutarlılığı zorunlu kılmalıyız.

Dünya kalıcılığı mı, örnekleme mi? Herkes tek bir dünyayı mı paylaşacak (bir MMO veya Second Life gibi), yoksa her içerik üreticisi başkalarının ziyaret edebileceği kendi örneğine mi sahip olacak (Minecraft sunucuları veya Fortnite Adaları gibi)? Teknoloji her ikisini de destekliyor, ancak sosyal dinamikleri tamamen farklı. Second Life'ın kalıcı ve paylaşımlı dünyası tesadüfi keşifler yaratır (dolaşırken başka insanların çalışmalarına rastlarsınız). Fortnite'ın örneklenmiş adaları ise keşif için bir menü veya portal sistemi gerektirir. Roblox merkez tabanlı bir yaklaşım kullanır: oyunlar ayrıdır, ancak ortak bir arayüz üzerinden göz atar ve keşfedersiniz. Hibrit bir yaklaşım işe yarayabilir: içerik üreticilerinin arsalara sahip olduğu kalıcı ve paylaşımlı bir üst dünya (Second Life parselleri gibi) ve portallar üzerinden bağımsız deneyimlere girme seçeneği.

Üretim araçlarının derinliği. Dreams, derin üretim araçlarının eleştirmenleri etkilediğini ancak kullanıcıların gözünü korkuttuğunu kanıtladı. Townscaper ise son derece sade araçların bir milyon kopya satabileceğini kanıtladı. Roblox Studio ikisinin ortasında yer alır: çocuklar için yeterince basit, profesyoneller için yeterince derindir. Krunker'ın voksel editörü daha da basittir. Bir tarayıcı dünyası için Townscaper düzeyinde basitlikle başlamalı (nesneleri yerleştirin, otomatik hizalanıp bağlansınlar) ve zamanla derinlik eklemeliyiz. Dünyaya ilk nesnenizi yerleştirme deneyimi 30 saniyeden kısa sürmelidir.

Ekonomi. Roblox, Second Life ve Fortnite Creative, ekonomik teşvikin bir oyuncağı platforma dönüştüren unsur olduğunu kanıtlıyor. İçerik üreticilerinin çalışmalarından gelir elde etmesini sağlayacak bir yol olmazsa en yetenekli içerik üreticileri başka yerlerde üretim yapar. Bunun ilk gün kullanıma sunulması gerekmez, ancak mimari bunu desteklemelidir (nesne sahipliği, ziyaret takibi, içerik üreticisi atfı).

Mobil. Mobil cihazlarda WebGPU'nun güvenilir hâle gelmesine daha yıllar var. Mobil deneyimin küçültülmüş bir sürüm olması gerekir: daha basit arazi, daha az nesne, daha kısa görüş mesafesi. Rec Room'un uyarlanabilir kaliteyle her cihazda çalışma yaklaşımı incelenmeye değer. Alternatif olarak mobil için yerel bir uygulama sunup tam deneyimi tarayıcıda tutabiliriz.

Moderasyon. Herkesin istediği her şeyi yerleştirebildiği açık bir dünya, moderasyon açısından bir kâbustur. Second Life 20 yıldır bununla uğraşıyor. Yerleştirilen her varlık, başkalarına görünür hâle gelmeden önce otomatik içerik incelemesinden geçmelidir. Bu, üretim sürecine gecikme ekler ancak vazgeçilemez bir gerekliliktir. İçerik üreticilerinin kendi içerik sınırlarını seçebilmesi için parsel tabanlı içerik derecelendirmelerini de değerlendirmeliyiz (Second Life'ın Genel/Orta/Yetişkin sistemi gibi).

Sistemik etkileşimler. BotW ve Minecraft, malzeme tabanlı etkileşim sistemlerinin statik nesne yerleştirmeye kıyasla katlanarak daha ilginç dünyalar oluşturduğunu gösteriyor. Bir içerik üreticisi ahşap bir köprü yerleştirir ve başka bir içerik üreticisi yakında ateş yakarsa köprü yanmalı mı? Birisi baraj yerleştirirse su arkasında birikmeli mi? Bu etkileşimler dünyanın canlı hissettirmesini sağlar ancak içerik üreticilerinin oluşturduğu tüm içeriklerde tutarlı fizik ve malzeme kuralları gerektirir. Sistemik tasarımın ne kadar ileri götürüleceğine karar vermek, erken aşamada alınması gereken bir mimari karardır.

Temel Çıkarımlar

Tarayıcı tabanlı 3D açık dünyalar bugün uygulanabilir durumda. Hordes.io, tarayıcıda 3D olarak 200'den fazla oyuncuyu çalıştırıyor. Krunker.io, eksiksiz bir 3D harita editörüyle aylık 10 milyon oyuncuya ulaşmıştı. .io oyunları, tarayıcı tabanlı çok oyunculu deneyimlerin milyonlarca kullanıcıya ölçeklenebildiğini kanıtladı. Teknoloji varsayımsal değil.

Render teknolojisi hazır. Three.js ve Babylon.js, 2010'ların başındaki AAA oyunlarla karşılaştırılabilir 3D sahnelerin üstesinden geliyor. WebGPU, arazi ve bitki örtüsü için compute shader'ların önünü açıyor. Wasm fizik motorları, yerel performansın 2-3 katı sınırları içinde çalışıyor. Whiterun ölçeğindeki bir alan, 15-25 MB görünür veriye sığıyor.

Ağ teknolojisi hazır. Cloudflare Durable Objects, parça başına uçta çalışan yetkili sunucular sağlar. CRDT'ler, çakışma olmadan ortak düzenlemeyi yönetir. Uzamsal bölümleme (Agar.io'dan Skyrim'e kadar her oyun tarafından kanıtlanmıştır), yüzlerce eşzamanlı oyuncu varken ağ trafiğini yönetilebilir düzeyde tutar.

AAA açık dünyalar (Skyrim, Witcher 3, BotW, Elden Ring, Minecraft, No Man's Sky) yalnızca grafik ölçütleri değildir. Bunlar parça akışı, LOD yönetimi, prosedürel üretim, sistemik tasarım ve dünya kompozisyonu üzerine ders kitaplarıdır. Kullandıkları her tekniğin tarayıcıyla uyumlu bir karşılığı vardır.

İçerik üretici platformları (Roblox, Second Life, Fortnite Creative, Dreams) sosyal ve ekonomik dersleri öğretir. Üretim harici bir araçta değil, dünyanın içinde gerçekleşmelidir. Ekonomik teşvik kaliteyi artırır. Kalıcılık bağlılık yaratır. Basit araçlar, güçlü araçlara kıyasla daha fazla içerik üreticisine ulaşır.

Cinevva'nın avantajlı olduğu alan yaratıcı içerik üretim hattıdır. Zaten 3D varlıklar, dokular ve sesler üretiyoruz. Bu üretim hattını bir dünya yerleştirme sistemine bağlamak, eksik olan parçadır. Yapay zekâyla üretilen içerik dünyayı doldurur. İçerik üreticilerinin seçimi ve düzenlemesi ise ona ruh kazandırır.

Sonunda ortaya çıkacak şey, tarayıcıda çalışan Skyrim olmazdı. Daha çok Minecraft'ın (düzenlenebilir dünya), Roblox'un (içerik üreticisi ekonomisi) ve BotW'nin (sistemik etkileşimler) kesişimine yakın; yapay zekâ destekli üretim araçlarıyla bir tarayıcı sekmesinde çalışan bir deneyim olurdu. Bunu inşa edecek teknoloji mevcut. Asıl mesele uygulama.

Araştırma Makaleleri ve Akademik Kaynaklar

Bu rehberdeki teknikler sıfırdan icat edilmedi. Onlarca yıllık araştırmaya dayanıyorlar. Aşağıda, her alt sistem için en önemli makaleler ve bunların tarayıcı tabanlı bir açık dünyaya nasıl uygulanacağına dair notlar yer alıyor.

Arazi Üretimi ve Render

"Bir Görüntü Sentezleyici" -- Ken Perlin (SIGGRAPH 1985). DOI. Perlin gürültüsünü tanıtan makale. 1985'ten bu yana her oyundaki her prosedürel arazi üreticisinin kökeni buna dayanır. Gürültü fonksiyonu, oktavlar hâlinde katmanlandığında (kesirli Brown hareketi) doğal görünümlü yükseklik haritaları üreten yumuşak bir rastlantısallık oluşturur. Simplex gürültüsü (Perlin, 2001) bunun daha hızlı halefidir. Arazi üretim hattımız açısından temel budur: gürültü tabanlı yükseklik haritası üretimi, bir WebGPU compute shader'ında etkileşimli hızlarda çalışır.

"Dokulama ve Modelleme: Prosedürel Bir Yaklaşım" -- Ebert, Musgrave, Peachey, Perlin, Worley (1994, 3. baskı 2003). Prosedürel üretim üzerine temel ders kitabı. Musgrave'in erozyon benzeri özelliklere sahip çoklu fraktal arazi de dâhil olmak üzere arazi modellemesini ele alan bölümleri, modern oyunlardaki arazi üreticilerinin doğrudan temelini oluşturur. Burada açıklanan fBm parametreleri (lacunarity, persistence, octave count), arazi özelleştirmesi için içerik üreticilerine sunacağımız parametrelerle aynıdır.

"Geometri Clipmap'leri: İç İçe Geçmiş Düzenli Izgaralar Kullanarak Arazi Render Etme" -- Losasso and Hoppe (SIGGRAPH 2004). DOI. Bu makale, eş merkezli LOD halkaları (clipmap'ler) kullanarak devasa arazilerin etkileşimli hızlarda nasıl render edileceği sorununu çözdü. Arazi mesh'i, kameranın merkezinde bulunan sabit bir iç içe ızgara kümesidir. Kamera hareket ettikçe ızgaralar kayar ve güncellenir. Bu, arazi bölümümüzde WebGL 2 için önerilen tekniktir ve dünya boyutundan bağımsız olarak GPU iş yükünün sabit kalması sayesinde çalışır. Özgün uygulama WebGL'den önce geliştirilmiş olsa da doğrudan ona uyarlanabilir. "GPU Üzerinde Hızlı Hidrolik Erozyon Simülasyonu ve Görselleştirmesi" -- Mei, Decaudin, Hu (2007). PDF. Hidrolik erozyonu CPU'ya bağımlı çevrimdışı bir süreç olmaktan çıkarıp gerçek zamanlı bir GPU hesaplamasına dönüştürdü. Makalenin sığ su simülasyonu modeli (suyu bir yükseklik alanı olarak ele alıp ızgara hücreleri arasındaki akışı hesaplayan) bir compute shader içinde çalışır. İşlem hattımızda sunucu taraflı GPU erozyonu, gürültüyle üretilen araziyi bir saniyeden kısa sürede jeolojik açıdan gerçekçi manzaralara dönüştürebilir ve yapay zekâyla üretilen arazinin elle şekillendirilmiş görünmesini sağlayabilir.

"Prosedürel Olarak Üretilen Gezegenlerin Gerçek Zamanlı İşlenmesi" -- No Man's Sky'ın GDC konuşmalarından ve Sean Murray'nin açıklamalarından derlenen hibrit yaklaşımlar. Tek bir makale olmasa da Innes McKendrick'in (Hello Games) GDC 2017'deki "Matematik Kullanarak Dünyalar İnşa Etmek" konuşması, No Man's Sky'ın üst üste bindirilmiş gürültü fonksiyonları, marching cubes kullanan voksel temsili ve GPU taraflı üretim yoluyla gezegen ölçeğinde araziyi nasıl oluşturduğunu ayrıntılarıyla açıklar. Özellikle yükseklik haritalarının temsil edemediği arazi özelliklerini (mağaralar, kemerler) üretmek açısından prosedürel arazi yaklaşımımızla doğrudan ilgilidir.

"C-DBLOD: Arazi İşleme için Hibrit LOD" -- Filip Strugar (2014). Makale. Kamera konumu çevresinde daha iyi uyarlanabilirlik sağlamak için dört ağaç tabanlı seçim ekleyen, geometri clipmap'lerinin geliştirilmiş bir sürümüdür. Temel fikir şudur: sabit eş merkezli halkalar yerine, farklı çözünürlüklerdeki arazi parçalarını seçmek için bir dört ağaç kullanılır. Bu yaklaşım, düzensiz arazilerde (bazı bölgelerin diğerlerinden daha fazla ayrıntı gerektirdiği durumlarda) saf clipmap'lerden daha iyi sonuç verir. WebGL 2'de küçük bir CPU taraflı dört ağaç dolaşımıyla uygulanabilir.

3D Gaussian Splatting ve Nöral İşleme

"Gerçek Zamanlı Işınım Alanı İşleme için 3D Gaussian Splatting" -- Kerbl, Kopanas, Leimkühler, Drettakis (SIGGRAPH 2023). Proje sayfası. Gaussian splatting devrimini başlatan makaledir. Bir sahne; her biri konum, kovaryans (şekil), opaklık ve küresel harmonik renk katsayılarına sahip milyonlarca 3D Gauss ile temsil edilir. İşleme süreci, splat'leri derinliğe göre sıralar ve bunları 2D Gauss'lar olarak rasterleştirir. Bu yaklaşımın eğitimi NeRF'lerden 100-1000 kat daha hızlıdır ve gerçek zamanlı hızlarda işleme yapar. Birden fazla WebGL/WebGPU uygulaması mevcuttur. Platformumuzda bu teknoloji, içerik üreticilerinin gerçek dünyadaki nesneleri telefon fotoğraflarıyla yakalayıp tarayıcı dünyasına yerleştirmelerini sağlar.

"NeRF: Görünüm Sentezi için Sahnelerin Nöral Işınım Alanları Olarak Temsili" -- Mildenhall ve diğerleri (ECCV 2020). Proje sayfası. Nöral sahne temsiline temel oluşturan makaledir. Bir sinir ağı, 3D koordinatları renk ve yoğunluğa eşleyerek bir dizi girdi fotoğrafından fotogerçekçi yeni görünüm sentezlenmesini sağlar. NeRF'ler doğrudan tarayıcıda işlenemeyecek kadar maliyetli olsa da (piksel başına ağ değerlendirmesi gerektirirler), NeRF'ten mesh'e çıkarım işlem hattı (bir NeRF'i eğitip ardından yoğunluk alanında marching cubes çalıştırmak) fotoğraflardan yüksek kaliteli, dokulu mesh'ler üretir.

"Çok Çözünürlüklü Hash Kodlamasıyla Anında Nöral Grafik Primitifleri" -- Müller, Evans, Schied, Keller (SIGGRAPH 2022). Proje sayfası. Uzamsal kodlama için çok çözünürlüklü bir hash tablosu kullanarak NeRF eğitimini saatlerden saniyelere indirdi. Bu, NeRF'i üretimde kullanılabilir hâle getirdi. Hash kodlama tekniği, bir tarayıcı dünyasındaki diğer uzamsal verilere de uygulanabilir (büyük 3D veri kümelerinde hızlı aramalar).

"Neuralangelo: Yüksek Doğruluklu Nöral Yüzey Rekonstrüksiyonu" -- Li ve diğerleri (CVPR 2023). Proje sayfası. SDF (işaretli uzaklık fonksiyonu) tahmini için çok çözünürlüklü hash kodlaması ve sayısal gradyanlar kullanarak nöral temsillerden yüksek kaliteli üçgen mesh'ler çıkarır. Çıktı mesh'leri doğrudan tarayıcı tabanlı 3D motorlarda kullanılabilir. Varlık işlem hattımızda Neuralangelo (veya NeuS2 gibi benzer araçlar), NeRF yakalamalarını temiz geometriye ve pişirilmiş dokulara sahip, web'e hazır GLB dosyalarına dönüştürebilir.

Çok Oyunculu Ağ İletişimi ve Durum Senkronizasyonu

"Devasa Çok Oyunculu Çevrimiçi Oyunlarda İlgi Alanı Yönetimi" -- Boulanger, Kienzle, Verbrugge (2006). DOI. MMO'lara yönelik ilgi alanı (AOI) yönetimi tekniklerinin kapsamlı bir incelemesidir. Ağ güncellemelerini uzamsal uygunluğa göre filtrelemek için ızgara tabanlı, aura tabanlı ve hibrit yaklaşımları ele alır. Izgara tabanlı yaklaşım (parça sistemimizle örtüşür) eşit yoğunluklu dünyalar için en verimli seçenektir. Aura tabanlı yaklaşım (varlık başına etki yarıçapı) değişken yoğunlukta daha iyi çalışır. AOI içindeki öncelik tabanlı güncelleme hızlarıyla birlikte parça tabanlı AOI önerimiz bu araştırmaya dayanır.

"Dead Reckoning: Ağ Bağlantılı Oyunlarda Gecikmeyi Gizleme" -- Pantel ve Wolf (2002). DOI. Ağ bağlantılı oyunlar için dead reckoning'i (son bilinen hıza göre varlık konumlarını tahmin etmeyi) biçimsel olarak tanımlar. Makale şu ödünleşimi nicelendirir: daha yüksek tahmin eşikleri bant genişliğini azaltır ancak düzeltmeler sırasında görünür konum hatasını artırır. 50-200 ms gecikmeli tarayıcı oyunlarında 0,5-1,0 metrelik bir tahmin eşiği, konum güncelleme bant genişliğini %60-80 azaltırken düzeltmelerin fark edilmemesini sağlar.

"Çakışmasız Çoğaltılmış Veri Türleri" -- Shapiro, Preguiça, Baquero, Zawirski (2011). DOI. CRDT'lere temel oluşturan makaledir. Koordinasyon olmadan yakınsayan durum tabanlı ve işlem tabanlı CRDT'leri tanımlar. Dünya düzenleme sistemimiz için ilgili CRDT'ler şunlardır: tek bir değere sahip nesne özellikleri (konum, dönüş, renk) için LWW-Register (Son Yazan Kazanır Yazmacı) ve bir parçadaki nesne koleksiyonu için OR-Set (Gözlemlenmiş-Silme Kümesi; eş zamanlı ekleme/silme işlemlerini çakışma olmadan yönetir). Yjs bunları JavaScript'te verimli biçimde uygular.

"Time Warp: Dağıtık Simülasyon için Bir Mekanizma" -- Jefferson (1985). DOI. İyimser dağıtık simülasyon üzerine ilk makaledir. Time Warp'ın kendisi bir tarayıcı oyunu için fazla karmaşık olsa da temel fikri (olayları iyimser biçimde işlemek ve başka bir düğümden çakışma gelirse geri almak), sunucu uzlaştırmalı modern istemci taraflı tahminin temelini oluşturur. Duyarlı çalışan tüm çok oyunculu oyunlar bu şekilde işler: istemci yerel olarak tahminde bulunur, eylemleri sunucuya gönderir ve sunucu aynı fikirde değilse düzeltme yapar.

"TRIBES Motorunun Ağ Modeli" -- Frohnmayer ve Gift (GDC 1999). İlgi alanı yönetimi, önceliklendirilmiş durum güncellemeleri ve bant genişliği bütçelemesi içeren istemci-sunucu oyun ağ iletişiminin ilk pratik açıklamalarından biridir. "Ghost manager" kavramı (sunucu, her istemci için istemcinin bildiklerinin ayrı bir görünümünü tutar ve yalnızca bu görünüme göre farkları gönderir), parça tabanlı Durable Object mimarimizin tam olarak uyguladığı yaklaşımdır. Bu GDC konuşması, modern oyun ağ iletişimi yaklaşımlarının çoğunun düşünsel atasıdır.

"Source Çok Oyunculu Ağ İletişimi" -- Valve (2009). Geliştirici belgeleri. Valve'ın Source motorunun (Half-Life 2, CS:GO ve Team Fortress 2'de kullanılan) ağ iletişimi modeline ilişkin belgeleridir. İstemci taraflı tahmin, varlık enterpolasyonu, gecikme telafisi ve sunucunun düzenli aralıklarla tam dünya durumunu gönderirken istemcinin anlık görüntüler arasında enterpolasyon yaptığı "anlık görüntü" sistemini kapsar. Yetkili sunucu ağ iletişimi için altın standarttır ve mimarimize doğrudan uygulanabilir.

Prosedürel Üretim

"Model Sentezi: Genel Amaçlı Bir Prosedürel Modelleme Algoritması" -- Merrell (2007). DOI. Wave Function Collapse'ın öncüllerinden biridir. Yerel kısıtlamaları yayarak örnek modellerden 3D yapılar üretir. Algoritma, en az olasılığa sahip hücreleri yinelemeli olarak çökerterek (minimum entropi sezgiseli) genel tutarlılık sağlar. Townscaper ve benzeri üreteçler, basit kullanıcı girdilerinden tutarlı yapıları bu şekilde üretir.

"WaveFunctionCollapse" -- Maxim Gumin (2016). GitHub. Geleneksel bir makale değil, kapsamlı belgelere sahip, çığır açıcı bir açık kaynak projesidir. Algoritma küçük bir örnek görüntü veya karo kümesini alıp girdiye yerel olarak benzeyen daha büyük çıktılar üretir. Bir içerik üreticisi dünyasında WFC; içerik üreticisinin tanımladığı küçük bir kural kümesinden bina yerleşimleri, yol ağları, zindan haritaları ve arazi ayrıntıları üretebilir. Birden fazla JavaScript uygulaması mevcuttur.

"Wave Function Collapse Doğal Ortamda Kısıt Çözümüdür" -- Karth ve Smith (FDG 2017). DOI. WFC'nin kısıt tatminiyle ilişkisini açıklığa kavuşturan ve nasıl analiz edilip genişletilebileceğini gösteren akademik bir incelemedir. WFC'nin sınırlamalarını (takılıp geri izlemeye ihtiyaç duyabilmesi) ve bu sorunları önleyen karo kümelerinin nasıl tasarlanacağını anlamak açısından önemlidir.

"Süperpozisyon Teoremi ve Oyun İçeriğinin Prosedürel Üretimine Etkileri" -- Sandhu ve diğerleri (2022). Prosedürel içerik üretimi için kuantumdan esinlenen süperpozisyon kavramlarının kullanımını inceler. Spekülatif olsa da nihai bir yapılandırmaya "çökmeden" önce birden fazla olası durumu korumaya yönelik matematiksel çerçeve, WFC'nin çalışma biçimiyle aynıdır ve daha gelişmiş üretim sistemlerine yön verebilir.

Gerçek Zamanlı İşleme Teknikleri

"Gerçek Zamanlı İşleme" -- Akenine-Möller, Haines, Hoffman (4. baskı, 2018). Alanın standart ders kitabıdır. Bölüm 19 (Hızlandırma Yapıları), Bölüm 20 (Verimli Gölgelendirme) ve Bölüm 21 (Sanal ve Artırılmış Gerçeklik) özellikle önemlidir. Burada açıklanan görüş hacmi ayıklama, örtülme ayıklama ve LOD algoritmaları; Three.js, Babylon.js ve tüm oyun motorlarının uyguladığı tekniklerdir. Bir makale değil, alanın kesin başvuru kaynağıdır.

"Gerçek Zamanlı Görünüm Sentezi için Nöral Işınım Alanlarını Pişirme Yöntemleri Üzerine Bir İnceleme" -- Reiser ve diğerleri (2023). DOI. NeRF'leri gerçek zamanlı işlenebilen biçimlere (mesh'ler, dokular, seyrek voksel ızgaraları) dönüştürme yöntemlerini inceler. Sunucu taraflı nöral yakalamanın tarayıcıda işlenebilir çıktılar üretmesi gereken varlık işlem hattımızla doğrudan ilgilidir.

"3D Gaussian Splatting Kullanarak Ölçeklenebilir ve Doğru Çevrimiçi Özellik Eşleştirme" -- Çeşitli gruplar (2024-2025). Yakın tarihli birçok makale, Gaussian splat'lerle düzenleme, birleştirme ve dinamik sahneleri inceler. İçerik üreticisi dünyalarının birden fazla splat sahnesini (her içerik üreticisinin yakaladığı nesneleri) tek ve tutarlı bir sahnede birleştirmesi gerektiğinden önemlidir. Splat düzenleme yöntemleri (yeniden renklendirme, deformasyon, birleştirme) aktif araştırma alanlarıdır.

"Verimli GPU Ekran Uzayı Işın İzleme" -- McGuire ve Mara (JCGT 2014). DOI. Su işleme bölümümüzde kullanılan ekran uzayı yansımalarının temelindeki makaledir. Tam ışın izlemenin maliyetine katlanmadan yaklaşık yansımalar elde etmek için derinlik tamponu boyunca ışınları izler. "Hiyerarşik izleme" çeşidi (min-max derinlik mipmap'i kullanarak) WebGL 2'de verimli çalışır.

"Okyanus Suyunun Simülasyonu" -- Jerry Tessendorf (2001). PDF. FFT tabanlı okyanus simülasyonu üzerine temel oluşturan makaledir. Phillips spektrumunu (okyanus dalgalarının istatistiksel modeli) ve ters FFT yoluyla uzamsal bir yer değiştirme haritasına nasıl dönüştürüleceğini açıklar. Gerçekçi okyanuslara sahip tüm büyük oyunlarda (Sea of Thieves, Assassin's Creed, Uncharted) kullanılır. FFT hesaplaması WebGPU compute shader'larına doğrudan uyarlanabilir.

"Önceden Hesaplanmış Atmosferik Saçılma" -- Bruneton ve Neyret (EGSR 2008). DOI. Fiziksel açıdan doğru gökyüzü işlemenin temelindeki makaledir. Atmosferik saçılmayı, bir fragment shader'ın gerçek zamanlı örneklediği arama tablolarına önceden hesaplar. Doğru gökyüzü renklerini, hava perspektifini (uzaktaki nesnelerin mavimsi/puslu görünmesi) ve gün batımı/gün doğumu renklerini temel fizik ilkelerinden üretir. Önceden hesaplanan tablolar küçüktür (birkaç yüz KB) ve çalışma zamanı shader'ı düşük maliyetlidir. Hem Three.js'in Sky shader'ı hem de Babylon.js'in prosedürel gökyüzü bu yaklaşımın basitleştirilmiş sürümleridir.

"Ortam Örtülme Hacimleri" -- McGuire (HPG 2010) ve "Ölçeklenebilir Ortam Örtülmesi" -- McGuire, Mara, Luebke (HPG 2012). PDF. Modern SSAO uygulamalarının temelindeki makalelerdir. SAO, verimli olması (piksel başına bir derinlik tamponu örneği) ve gerçekçi temas gölgeleri üretmesi nedeniyle tarayıcı tabanlı 3D motorlarda en yaygın uygulanan çeşittir. Algoritma, her pikselin yakınındaki geometriler tarafından ne kadar "örtüldüğünü" tahmin etmek için piksel çevresindeki derinlik tamponunu örnekler. Hem Three.js hem de Babylon.js, SAO'dan türetilmiş SSAO uygular.

Kalabalık İşleme ve Animasyon

"GPU Kalabalık İşleme" -- Dudash (2007) ve örneklemeli kalabalık işleme üzerine sonraki GDC/SIGGRAPH sunumları. Temel teknik şudur: iskelet animasyonu karelerini dokulara pişirin (Vertex Animation Textures), ardından kalabalıkları örneklemeli mesh'ler olarak işleyin; her örnek, kemik dönüşümlerini mevcut karesine göre animasyon dokusundan okur. Bu, animasyon değerlendirmesini çizim çağrılarından ayırarak tek bir örneklemeli çizim çağrısının benzersiz biçimde canlandırılmış yüzlerce karakteri işlemesini sağlar.

"Konum Tabanlı Dinamikler" -- Müller ve diğerleri (2007). DOI. Modern oyun motorlarının kumaş, saç ve yumuşak cisimleri simüle etme yöntemi olan PBD üzerine temel oluşturan makaledir. Rapier (önerdiğimiz Wasm fizik motoru), PBD'den türetilmiş çözücüler kullanır. Avatar özelleştirmesinde (pelerinler, dalgalanan saçlar, bol giysiler) PBD, oyun kare hızlarında hızlı tepki veren simülasyon sağlar. Wasm uygulaması bu işi ana JavaScript iş parçacığının dışında tutar. "FABRIK: Ters Kinematik Problemi için Hızlı ve Yinelemeli Bir Çözücü" -- Aristidou ve Lasenby (2011). DOI. Avatar bölümümüzde önerilen IK çözücüsünün temelini oluşturan makale. FABRIK, uç efektörden köke ve kökten uç efektöre dönüşümlü olarak uzanıp 3-5 yinelemede yakınsar. Jacobian tabanlı IK'den daha hızlıdır, eklem kısıtlamalarını doğal biçimde işler ve uygulaması kolaydır (temel çözücü yaklaşık 50 satır koddan oluşur). Hem Three.js hem de Babylon.js IK uygulamaları FABRIK'ten türetilmiştir.

Sanal Dünyalar ve İş Birliğine Dayalı Ortamlar

"Devasa Çok Oyunculu Çevrimiçi Oyunlar: Güncel Durum Araştırması" -- Yahyavi ve Kemme (2013). DOI. İstemci-sunucu modellerini, eşler arası yaklaşımları, ilgi alanı yönetimini, tutarlılık modellerini, ölçeklenebilirlik tekniklerini ve hile önlemeyi kapsayan kapsamlı bir MMO mimarisi araştırması. Tutarlılık modellerinin sınıflandırması (katı, nihai, nedensel), CRDT tabanlı yaklaşımımızla (vektör saatleri aracılığıyla nedensel sıralamaya sahip nihai tutarlılık) örtüşür.

"İnternet Üzerindeki Çok Oyunculu Etkileşimli Uygulamalar için Dağıtık Bir Mimari" -- Diot ve Gautier (1999). DOI. Temel gerilimi belirleyen dağıtık sanal ortamlar üzerine erken dönem araştırması: katı tutarlılık koordinasyon gerektirir (gecikmeyi artırır), zayıf tutarlılık ise hızlı tepki sağlar ancak görünür tutarsızlık riski taşır. Makale, orta yol olarak "yerel gecikmeyi" (uzak güncellemelerin ulaşmasına zaman tanımak için yerel görüntüyü kısa bir süre geciktirmeyi) savunur. Dünya düzenlemelerinde (nesne yerleştirme gibi) 100-200 ms'lik yerel gecikme fark edilmez ve sunucuya doğrulama için zaman kazandırır.

"Second Life Grid: Yakın Dönemli Açık Kaynaklı Bir Sanal Dünyanın Mimarisi" -- Linden Lab teknik belgeleri ve topluluk tarafından gerçekleştirilen tersine mühendislik çalışmaları. Tek bir makale olmasa da Second Life mimarisinin teknik analizi kapsamlı biçimde belgelenmiştir. Temel çıkarımlar şunlardır: her 256x256 m bölge, ayrılmış bir sunucu örneğinde çalışır. Nesneler, "primitiflerden" (dönüşümleri, dokuları ve betikleri olan temel şekiller) oluşan bir ağaç olarak depolanır. Görüntüleyici, nesne açıklamalarını ve dokuları gerektiğinde akış yoluyla yükler. Nesne başına kalıcılığa sahip bu parsel tabanlı model, geliştirdiğimiz sisteme en yakın mevcut mimaridir ve Second Life'ın 20 yılı aşkın süredir faaliyet göstermesi bunun ölçeklenebildiğini kanıtlar.

Web Grafikleri ve Tarayıcı Performansı

"WebGPU: Web için Yüksek Performanslı Bir Grafik API'si" -- W3C Web için GPU Çalışma Grubu (2023-devam ediyor). Spesifikasyon. WebGPU'nun resmî spesifikasyonu. Bir araştırma makalesi değildir ancak tarayıcıda GPU programlama için en yetkin teknik belgedir. Hesaplama gölgelendiricisi spesifikasyonu (Bölüm 23), bu rehber boyunca açıklanan arazi üretimi, bitki örtüsü dağıtımı ve parçacık sistemleri açısından özellikle önemlidir.

"WebAssembly: Derlenmiş Kodu Tarayıcıda Çalıştırmak için Bir Çerçeve" -- Haas ve diğerleri (PLDI 2017). DOI. Tarayıcı sağlayıcılarının yayımladığı özgün WebAssembly makalesi. Wasm'ın yoğun hesaplama gerektiren iş yüklerinde yerel performansın 2 katı sınırları içinde kaldığını gösterir. Bu, tarayıcı tabanlı açık dünyalar için Wasm'a derlenmiş fizik motorlarını (Rapier, Havok) önerme kararımızı doğrular. Makalenin performans analizi, ek yükün esas olarak derleme modelinin kendisinden değil, sınır denetimlerinden ve dolaylı fonksiyon çağrılarından kaynaklandığını gösterir.

"O Kadar da Hızlı Değil: WebAssembly ile Yerel Kodun Performans Analizi" -- Jangda ve diğerleri (USENIX ATC 2019). PDF. Wasm ile yerel performansı karşılaştıran titiz bir kıyaslama. Wasm'ın SPEC CPU kıyaslama paketi genelinde yerel C kodundan ortalama 1,45-1,55 kat daha yavaş çalıştığını tespit eder. Özellikle oyun fiziğinde (yoğun kayan nokta işlemleri, az sayıda sistem çağrısı) ek yük alt sınıra daha yakındır (~1,3 kat). Bu, tarayıcıdaki Wasm fiziğinin gerçek zamanlı oyun iş yükleri için uygulanabilir olduğunu doğrular.

"WebAssembly ile Web'i Hızlandırmak" -- Rossberg ve diğerleri (2018). DOI. WebAssembly'nin tasarım gerekçesini ve biçimsel semantiğini açıklar. Özellikle önemli olan nokta şudur: bellek güvenliği garantilerinin ele alındığı bölüm (Bölüm 3), Wasm modüllerinin yerel eklentilerin güvenlik risklerini taşımadan JavaScript ile aynı tarayıcı sekmesini nasıl güvenle paylaşabildiğini açıklar. Geleneksel olarak C++ kütüphaneleri olan fizik motorlarını tarayıcıda güvenle çalıştırmayı mümkün kılan budur.

Yapay Zekâ Destekli İçerik Üretimi

"Hem 2B hem de 3B Ön Bilgileri Kullanan Çift Yönlü Difüzyon ile Metinden 3B Üretim" -- Çeşitli gruplar (2023-2025). Yakın tarihli birçok makale (DreamFusion, Magic3D, ProlificDreamer, MVDream, Zero-1-to-3++), 2B difüzyon modellerini 3B optimizasyon için ön bilgi olarak kullanarak metin istemlerinden 3B varlık üretimini inceler. Kalite, 2023 başından 2025'e kadar biçimsiz şekillerden ayrıntılı, dokulu ağlara geçerek çarpıcı ölçüde iyileşti. Platformumuzda bu modeller (sunucu tarafında GPU'larda çalıştırılarak), içerik üreticisi varlık işlem hattındaki "yapay zekâyla üretim" adımını oluşturur.

"DreamFusion: 2B Difüzyon Kullanarak Metinden 3B'ye" -- Poole ve diğerleri (ICLR 2023). Proje sayfası. Önceden eğitilmiş bir 2B difüzyon modelini 3B optimizasyona yön vermek için kullanan Skor Damıtma Örneklemesi (SDS) hakkındaki temel makale. Ana fikir şudur: bir 3B nesnenin işlenmiş görünümlerinin bir metin istemiyle eşleşip eşleşmediğini mevcut bir 2B modelle değerlendirebiliyorsanız 3B eğitim verilerine ihtiyacınız yoktur. Bu yaklaşım, metinden 3B üretimin önünü açmış ve kaliteyi ve hızı artıran sonraki çalışmaların (Magic3D, ProlificDreamer) temelini oluşturmuştur.

"LRM: Tek Görüntüden 3B'ye Büyük Yeniden Oluşturma Modeli" -- Hong ve diğerleri (ICLR 2024). Proje sayfası. Tek bir GPU'da, tek bir görüntüden 5 saniyede 3B model oluşturur. Model, ağa dönüştürülebilen NeRF benzeri bir temsil üretir. İçerik üreticilerine yönelik bir dünyada bu, içerik üreticisinin gerçek dünyadaki herhangi bir nesnenin fotoğrafını çekip saniyeler içinde 3B modelini elde edebileceği anlamına gelir. Hızı sayesinde toplu işlem yerine etkileşimli bir araç olarak kullanılabilir.

"Makine Öğrenimi Yoluyla Prosedürel İçerik Üretimi (PCGML)" -- Summerville ve diğerleri (2018). DOI. Oyunlarda prosedürel içerik üretimi için makine öğreniminin kullanımını inceleyen bir araştırma. Seviye, eşya, anlatı ve dünya üretimini kapsar. Tasarımcıların üst düzey parametreleri belirlediği ve makine öğrenimi modelinin ayrıntıları tamamladığı "kontrol edilebilir üretim" tartışması özellikle önemlidir. Yapay zekâ destekli dünya oluşturmanın paradigması budur: içerik üreticileri niyeti belirler ("bu alanı ürkütücü bir ormana dönüştür"), yapay zekâ ise geometriyi, dokuları ve yerleşimi tamamlar.

Bu Makalelerin Mimarimizle Bağlantısı

Araştırmalar, mimarimizin katmanlarıyla şu şekilde eşleşir:

Arazi işlem hattı: Perlin/simplex gürültüsü (Perlin 1985, 2001) temel yükseklik haritasını üretir. Hidrolik erozyon (Mei ve diğerleri 2007) jeolojik gerçekçilik katar. Geometri klip haritaları (Losasso ve Hoppe 2004) veya CDLOD (Strugar 2014), araziyi tarayıcıda verimli biçimde işler. Atmosferik saçılım (Bruneton ve Neyret 2008), uzaktaki arazinin doğru görünmesini sağlar.

Varlık işlem hattı: Metinden 3B'ye (DreamFusion ve diğerleri) ve görüntüden 3B'ye (LRM) modelleri, varlıkları sunucu tarafında üretir. Gaussian splatting (Kerbl ve diğerleri 2023), fotogrametriyle yakalamayı mümkün kılar. Neuralangelo (Li ve diğerleri 2023), nöral yakalamalardan temiz ağlar çıkarır. Tüm çıktılar, tarayıcıya hazır GLB/KTX2 biçimlerine dönüştürülür.

İşleme: SSAO (McGuire 2012) derinlik katar. Ekran uzayı yansımaları (McGuire ve Mara 2014) su görsellerini oluşturur. FFT okyanusu (Tessendorf 2001) suyu simüle eder. Köşe animasyonu dokuları (Dudash 2007) kalabalıkları işler. FABRIK (Aristidou ve Lasenby 2011), karakter IK'sini yönetir.

Ağ iletişimi: İlgi alanı yönetimi (Boulanger ve diğerleri 2006), güncellemeleri mekânsal uygunluğa göre filtreler. Ölü hesap yöntemi (Pantel ve Wolf 2002) bant genişliği kullanımını azaltır. CRDT'ler (Shapiro ve diğerleri 2011) iş birliğine dayalı düzenlemeyi yönetir. Sunucu uzlaştırmalı istemci tahmini (Jefferson 1985, Valve Source Networking), hızlı tepki sağlar.

Dünya üretimi: WFC (Gumin 2016, Karth ve Smith 2017) yapılar ve yerleşimler üretir. PCGML (Summerville ve diğerleri 2018), içerik üreticilerinin niyeti belirlediği ve modellerin ayrıntıları tamamladığı yapay zekâ destekli üretim çerçevesini sağlar.

Araştırma alanı olgunlaşmış durumda. Bu tekniklerin çoğu yıllardır yayımlanmış oyunlarda kullanılıyor. Bunları tarayıcıya taşımanın yenilikçi yanı algoritmalar değil; tarayıcının bellek, GPU ve ağ kısıtları içinde çalışabilmelerini sağlayan mühendisliktir. Bu rehberin geri kalanı da tam olarak bunu ele alıyor.

Ek Okumalar

• 2026'da Web Oyunları Teknoloji Yığını, WebGL, WebGPU ve WebAssembly'nin temellerini ele alır
• Web Oyun Motorları Karşılaştırması, tarayıcıda sunum için oyun motorlarını karşılaştırır
• Three.js + USDC Teknik Raporu, 3B varlıkların tarayıcıda yüklenmesini ele alır
• Öncü Açık Kaynak Üretken Yapay Zekâ Modelleri, yapay zekâ üretim işlem hattını ele alır
• Eşli Oyun Tasarımı, oyuncuların ilgisini canlı tutan çok oyunculu tasarım kalıplarını ele alır
• Tarayıcı Tabanlı Açık Dünyalar için Arazi Üretimi — arazi, erozyon ve bitki örtüsü işleme
• WebSocket ile çok oyunculu oyunların temelleri — tarayıcı tabanlı çok oyunculu ağ iletişimine başlangıç
• WebGPU'ya başlangıç — yeni nesil tarayıcı tabanlı 3B grafikler için işleme API'si
• Akış yoluyla varlık yükleme — büyük 3B dünyalar için aşamalı yükleme kalıpları

Hemen deneyinHemen şimdi tarayıcınızda bir açık dünya deneyin

Tek bir cümle yazın, yürünebilir bir 3B dünya oluşturun.

Ücretsiz oluştur →Ücretsiz, tarayıcınızda çalışır, kurulum yok.