Tarayıcıya Özgü Oyunlar Ciddileşiyor: Açık Kaynaklı Dövüş Projeleri Ne Gösteriyor

Bu araştırmaya başlarken birkaç ilginç tarayıcı dövüş deneyi bulmayı bekliyordum. Bunun yerine çok daha geniş bir ekosistemle karşılaştım: lock-on hedefleme, dallanan kombo ağaçları, kusursuz parry, dodge sırasında hasar almama, posture sistemleri, hava saldırıları, boss telegraph'ları, motion warping, hit-stop, fiziksel silah çarpışmaları, gamepad desteği, dokunmatik kontroller ve deterministik simülasyon içeren gerçek üçüncü şahıs aksiyon prototipleri.

Asıl önemli sonuç bu. Bunlar artık yalnızca bir web sayfasının içinde render edilen küçük oyunlar değil. Bazıları geleneksel aksiyon oyunlarıyla aynı mühendislik problemlerini çözüyor; ancak bir URL olarak dağıtılıyor ve anında oynanabiliyor.

Bir web geliştiricisi olarak benim için büyüleyici olan taraf da bu. Oyunlara dair eski zihinsel model; kurulum dosyaları, büyük indirmeler, patcher'lar, launcher'lar ve bir oyunu keşfetmekle gerçekten oynamaya başlamak arasındaki gecikme etrafında şekilleniyordu. Tarayıcı bu yolu ciddi biçimde kısaltıyor: bağlantıyı aç, asset'leri yükle ve oynamaya başla.

Bu araştırmada, oynanabilir bir tarayıcı build'i ve herkese açık kaynak kodu bulunan projelere odaklandım. Unity WebGL export'larını özellikle dışarıda bıraktım; çünkü yalnızca web'e export edilmiş oyunları değil, web teknolojileri etrafında geliştirilmiş oyunları incelemek istiyordum.

Bulduğum en güçlü projeler

En yararlı bulguların hepsi aynı nedenle güçlü değildi. Bazılarında en derin kombo sistemleri vardı. Bazıları ise daha iyi üçüncü şahıs mimarisi, daha temiz dövüş simülasyonu veya fiziksel olarak daha ikna edici darbeler sunuyordu.

Sonuçlar beni neden şaşırttı

Şaşırtıcı olan yalnızca grafiklerin iyi görünmesi değildi. İyi işlenmiş bir sahneyi render etmek, oyun geliştirmenin yalnızca bir parçası. Öne çıkan projeler; inandırıcı biçimde taklit edilmesi zor sistemleri gerçekten uyguluyordu: input buffering, dövüş durumu geçişleri, hedef seçimi, saldırı hareketi, animasyon zamanlaması, hit detection, düşman tepkileri, savunma pencereleri, kamera davranışı ve darbe geri bildirimi.

Bu da yararlı bir ayrım ortaya çıkarıyor:

• animasyon zamanlaması, dövüş zamanlaması değildir;
• render frame rate'i, simülasyon hızı değildir;
• collision, otomatik olarak geçerli bir hit anlamına gelmez;
• animasyon, hareket üzerinde mutlaka otorite sahibi değildir;
• görsel temas ile hissedilen darbe aynı şey değildir.

Bu ayrımlar en güçlü projelerin birçoğunda tekrar tekrar karşıma çıktı ve README'deki renderer logosundan daha önemli.

Voxel Musou: tarayıcı dövüşü gerçek bir hareket gramerine sahip olabilir

Voxel Musou, tarayıcı dövüşünün artık tek bir düğmeye bağlanmış tek bir saldırı animasyonu anlamına gelmek zorunda olmadığını gösteren en açık örneklerden biriydi. Kaynak kodu mike007jd/voxel-musou adresinde mevcut.

Proje, tamamen doğrusal bir kombo yerine uzun normal saldırı zincirleri ve charge dalları kullanıyor. Bu mimari açıdan önemli; çünkü sistem şu şekilde modellenebilir:

current move + buffered input + combat state -> next move

Bu, giderek büyüyen özel durum koşulları koleksiyonuna kıyasla character-action türü bir oyun için çok daha iyi bir temel. Ayrıca hava saldırılarını, özel sekansları, birden fazla karakter kit'ini, boss davranışlarını, hit-stop'u ve büyük düşman gruplarına karşı dövüşü de gösteriyor.

Daha genel mühendislik dersi şu: hareketler veriye dönüşmeli, geçişler ise açık biçimde tanımlanmalı. Bu yapıldığında yeni bir karakter eklemek artık tüm dövüş kontrolcüsünü yeniden yazmayı gerektirmez.

Long Wind: modern bir tarayıcı aksiyon oyununa en yakın örnek

Long Wind, üçüncü şahıs hareketini hafif ve ağır saldırılar, lock-on, guard, kusursuz parry, dodge sırasında hasar almama, posture baskısı, execution'lar, havaya fırlatma ve yere düşürme tepkileri, projectile'lar, boss'lar ve birden fazla düşman arketipiyle birleştirdiği için en güçlü hepsi-bir-arada referanslardan biriydi. Kaynak kodu jbang2004/long-wind adresinde mevcut.

Değeri, her bir özelliğin tek başına daha önce hiç görülmemiş olmasından değil, bu özelliklerin tarayıcıya özgü tek bir aksiyon prototipinde birlikte bulunmasından geliyor. Bu da input'tan hedef seçimine, saldırı durumuna, animasyona, temasa, tepkiye, hit-stop'a ve kamera geri bildirimine uzanan tüm yolu izlemek için onu yararlı bir referans hâline getiriyor.

Motion warping, web demolarının sıkça görmezden geldiği bir problemi çözüyor

Samurai Third-Person Template ThreeJS, klasik bir üçüncü şahıs yakın dövüş problemini ele aldığı için özellikle ilginç. Kaynak kodu achrefelouafi/SamuraiThirdPersonTemplateThreeJS adresinde mevcut.

Önceden hazırlanmış bir saldırı animasyonu, vuruş temas karesine geldiğinde hedefin belirli bir mesafede olacağını varsayar. Gerçek bir oyunda hedef neredeyse hiçbir zaman kusursuz konumda değildir. Karakter animasyonu olduğu yerde oynatırsa oyun hasar uygulasa bile kılıç görünürde hedefi ıskalayabilir. Karakter doğru konuma ışınlanırsa saldırı yapay görünür.

Motion warping daha iyi bir çözüm sunar: saldırı sırasında dönüşü ve konum değişimini ayarlayarak karakterin doğru anda beklenen temas konumuna ulaşmasını sağlar.

Önemli ayrım şudur:

animation intent != movement authority

Karakter, hazırlanmış animasyonun görsel niyetini koruyabilir; buna karşılık karakterin gerçekte nereye gideceği konusunda oyun kontrolcüsü otoritesini korur.

Collision detection ile hit validation farklı problemlerdir

Stick & Steel çok farklı bir dövüş modelini inceliyor. Kaynak kodu Rabneba/stick-steel adresinde mevcut.

Proje, kılıcı öncelikle hasar hacmine sahip bir animasyon olarak ele almak yerine silahlara fiziksel bir varlık kazandırıyor. Temas hızı, silahın yönelimi, vücut bölgesi, guard'lar, çarpışmalar, yere düşmeler ve silahsızlandırma önem taşıyor.

Buradan alınabilecek en genel ders, her aksiyon oyununun tamamen fiziksel silahlar kullanması gerektiği değil. Asıl ders şu:

Bir collision size iki şeyin birbirine temas ettiğini söyler. Anlamlı bir vuruş gerçekleşip gerçekleşmediğini söylemez.

İkna edici bir dövüş sistemi çoğu zaman ikinci bir katmana ihtiyaç duyar. Bu katman, temasın hasar sayılması için yeterli hıza, doğru yöne, silahın doğru bölgesine, doğru zamanlamaya ve geçerli bir hedef durumuna sahip olup olmadığına karar verir.

Merkezi dövüş çözümleme, karmaşık savunmayı anlamayı kolaylaştırır

Hollowmere, kaynak kodu euuuuuuan/hollowmere-public adresinde bulunan bir proje ve görsel gösterişten çok yazılım mimarisiyle öne çıktı.

Dövüş simülasyonu render işleminden ayrılmış ve savunma çözümlemesi merkezileştirilmiş. Bu, aksiyon oyunlarında sık görülen bir hata biçimini önlüyor: dodge sistemi, parry sistemi, hit reaction sistemi ve animasyon katmanının aynı saldırının isabet edip etmediği konusunda birbirinden bağımsız biçimde farklı sonuçlara varması.

Daha temiz bir zihinsel model şudur:

incoming attack -> evade | parry | hit

Renderer sonucu göstermeli; dövüş gerçeğinin ikinci bir sürümünü icat etmemeli.

Dövüş sistemi büyüdükçe bu ayrım giderek daha önemli hâle gelir. Deterministik simülasyon ve açık durum geçişleri gösterişli özellikler değildir; ancak karmaşık dövüş sistemlerini test etmeyi, debug etmeyi ve genişletmeyi kolaylaştırırlar.

Oyun hissi dekorasyon değil, bir mühendislik sistemidir

Fabled Revolutions, kaynak kodu ericrius1/FabledRevolutions adresinde bulunan bir proje ve darbeleri etkili hissettiren efektleri ayrı ayrı ortaya koyduğu için özellikle yararlı.

Mantıksal olarak doğru bir dövüş sistemi yine de zayıf hissettirebilir. Collision doğru olabilir, hasar doğru frame'de uygulanabilir ve sonuç yine de iki model birbirinin içinden geçiyormuş gibi hissedebilir.

Hissedilen darbe çoğu zaman kısa ömürlü efektlerin üst üste eklenmesinden doğar:

• hit-stop;
• kamera sarsıntısı veya kick;
• silah izleri;
• darbe parçacıkları;
• hasar flash'ı;
• knockback;
• animasyon tepkisi;
• doğru zamanlanmış ses.

Bu da başka bir yararlı ayrımı gösteriyor: dövüşün doğruluğu, dövüş hissi değildir. Bir tarayıcı oyununun ikisine de ihtiyacı vardır.

Dövüş kalitesini en çok belirleyen şey renderer değildi

Araştırmada gördüğüm daha ilginç örüntülerden biri, en iyi dövüş sistemlerinin bir projenin en yeni render API'sini kullanıp kullanmamasına göre belirlenmemesiydi.

Three.js tekrar tekrar karşıma çıktı. Bazı projeler WebGPU ile ilişkili render teknolojileri kullanırken diğerleri geleneksel WebGL tabanlı stack'ler kullanıyordu. Fizik motorları, TypeScript, JavaScript, Vite, WebAssembly ve farklı render yaklaşımlarının tümü araştırmada yer aldı.

Ancak gelişmiş dövüş sistemleri daha tutarlı biçimde mimariye bağlıydı: sabit adımlı simülasyon, açık durumlar, güvenilir hedefleme, mantıklı animasyon sahipliği, veri odaklı hareketler, merkezi hasar çözümleme ve iyi darbe geri bildirimi.

Bu, web geliştiricileri için cesaret verici. Ciddi dövüş tasarımlarıyla denemeler yapmaya başlamadan önce her kullanıcının en yeni grafik stack'ine sahip olmasını beklemek zorunda değilsiniz.

Tarayıcı üzerinden dağıtım neden denklemi değiştiriyor

Tarayıcının grafiklerle pek ilgisi olmayan bir avantajı var: dağıtım sürtünmesi son derece düşük.

Geleneksel oyunlar keşif ile etkileşim arasına çoğu zaman birkaç adım koyar: mağaza sayfasını bul, büyük bir paket indir, kur, başlat, güncellemeleri bekle ve bazen anlamlı oynanışa ulaşmadan önce bir hesap oluştur.

Bir tarayıcı oyunu bu yolu tek bir bağlantıya indirebilir.

Bu, prototiplerin nasıl paylaşılabildiğini ve test edilebildiğini değiştiriyor. Bir geliştirici bir build yayınlayabilir, URL gönderebilir, başka bir kişiyi anında aynı sürüme alabilir, geri bildirim toplayabilir ve test eden kişiden yeni bir paketi elle kurmasını istemeden sonraki iterasyonu deploy edebilir.

Bu avantaj özellikle deneysel oyunlar ve bağımsız geliştirme için önemli hâle geliyor. Tarayıcı yalnızca bir runtime değil; aynı zamanda bir dağıtım sistemidir.

Tarayıcının hâlâ geride kaldığı yerler

Bu araştırma beni tarayıcıların native oyun platformlarının yerini aldığına ikna etmedi. Almadılar.

Bazı kısıtlar hâlâ önemli:

• Büyük asset yükleri. Bir oyun ilk açılışta çok büyük bir indirme gerektiriyorsa anında erişim artık anında hissettirmez.
• Bellek baskısı. Tarayıcılar diğer sekmelerle ve işletim sistemiyle birlikte çalışmak zorundadır; bellek davranışı da ayrılmış bir native süreçte olduğundan daha az öngörülebilirdir.
• Mobil termal sınırlar. Teknik olarak çalışan bir 3D oyun bile uzun bir oturumda ciddi biçimde throttle olabilir.
• Tarayıcı farkları. Grafik, ses, pointer lock, tam ekran davranışı, controller'lar ve performans özellikleri tamamen aynı değildir.
• Shader ve asset hazırlığı. Pipeline dikkatli tasarlanmazsa derleme veya upload işleri hâlâ gözle görülür takılmalara yol açabilir.
• Çevrimdışı ve yerel kalıcılık kısıtları. Native uygulamalar büyük yerel kurulumlar ve dosyalar üzerinde daha doğrudan kontrolü korur.
• Rekabetçi güvenlik. İstemci bir web uygulaması olduğunda ciddi anti-cheat çözümleri ve hostile-client varsayımları çok daha zor hâle gelir.

Bu sınırlamalar önemlidir; çünkü tarayıcı oyunlarının bugün en güçlü olduğu alanları tanımlar: anında erişimden, hızlı iterasyondan, platformlar arası dağıtımdan ve yönetilebilir asset/runtime bütçelerinden yararlanan oyunlar.

Yapay zekâ, prototipten URL'ye giden döngüyü çok daha kısa hâle getiriyor

Yapay zekâ burada önemli; ancak bunun nedeni bir cümleyi sihirli biçimde bitmiş, yüksek kaliteli bir oyuna dönüştürmesi değil. Daha gerçekçi avantaj, iterasyon hızıdır.

Modern oyun geliştirme, tek tek küçük ama toplamda pahalı çok sayıda iş içerir: state machine kurmak, debug görünümleri oluşturmak, test yazmak, düşman davranışlarını denemek, hareketler için veri formatları oluşturmak, input kodunu refactor etmek, shader prototipleri yapmak, fizik hatalarını incelemek ve geçici içeriği sisteme bağlamak.

Yapay zekâ bu döngülerin çoğunu kısaltabilir. Web üzerinden dağıtımla birleştiğinde iş akışı alışılmadık derecede doğrudan hâle gelir:

idea -> prototype -> deploy -> open URL -> test -> iterate

Tarayıcı zaten deploy işlemini hızlandırıyor. Yapay zekâ aynı döngünün uygulama tarafını da hızlandırabilir.

Önemli çekince şu: hızlı üretim, zevkin veya doğrulamanın yerini tutmaz. Üretilmiş bir dövüş kontrolcüsü yapısal olarak yanlış olabilir. Animasyon zamanlaması hâlâ insan değerlendirmesi gerektirir. Fizik hâlâ debug edilmelidir. Performans hâlâ ölçülmelidir. Yapay zekâ fikirleri denemenin maliyetini düşürür; hangi fikirlerin iyi olduğuna karar verme ihtiyacını ortadan kaldırmaz.

Bunun web geliştiricileri için anlamı ne

Web geliştirme ile oyun geliştirme arasındaki sınır giderek daha az katı hâle geliyor.

Ciddi bir tarayıcı oyunu artık tanıdık web araçlarını kullanırken klasik oyun mühendisliği kavramlarına da ihtiyaç duyabilir:

• sabit simülasyon adımları;
• state machine'ler;
• input buffering;
• animasyon grafikleri;
• uzamsal sorgular;
• fizik;
• frame bütçeleri;
• GPU kaynak yönetimi;
• ses zamanlaması;
• deterministik sistemler.

Aynı zamanda tarayıcıyı hedefleyen oyun geliştiricileri, web'in zaten olağanüstü iyi olduğu şeylerden yararlanıyor: URL'ler, anında deploy, CDN üzerinden dağıtım, hızlı güncellemeler, telemetri, hesap sistemleri, responsive arayüzler ve sürtünmesiz paylaşım.

Bu araştırma benim zihinsel modelimi değiştirdi. Artık tarayıcı oyunlarını öncelikle native oyunların basitleştirilmiş sürümleri olarak görmüyorum. Tarayıcıyı; anında dağıtım, hızlı iterasyon, giderek daha ciddi 3D yetenekler ve devasa bir mevcut geliştirme ekosistemi gibi farklı güçlü yönlere sahip, giderek daha yetenekli bir oyun platformu olarak görüyorum.

Web yalnızca başka yerde geliştirilmiş oyunları göstermede daha iyi hâle gelmiyor. Giderek daha fazla, ciddi oyun sistemlerinin doğrudan tasarlanabildiği, uygulanabildiği, test edilebildiği, dağıtılabildiği ve oynanabildiği bir yer hâline geliyor.