Game yang Dibangun Khusus untuk Browser Semakin Serius: Apa yang Diungkap Proyek Pertarungan Sumber Terbuka

Saya memulai riset ini dengan perkiraan bahwa saya hanya akan menemukan segelintir eksperimen pertarungan browser yang menarik. Ternyata, saya menemukan ekosistem yang jauh lebih luas: prototipe aksi orang ketiga yang nyata dengan penargetan lock-on, pohon combo bercabang, perfect parry, kekebalan saat dodge, sistem posture, serangan udara, indikasi serangan bos, motion warping, hit-stop, benturan senjata secara fisik, dukungan gamepad, kontrol sentuh, dan simulasi deterministik.

Itulah hasil yang penting. Ini bukan lagi sekadar game kecil yang kebetulan dirender di dalam halaman web. Sebagian di antaranya menyelesaikan masalah rekayasa yang sama seperti game aksi konvensional, tetapi didistribusikan sebagai URL dan bisa langsung dimainkan.

Bagi saya sebagai pengembang web, bagian itulah yang paling menarik. Gambaran lama tentang game didominasi oleh installer, unduhan besar, patcher, launcher, serta jeda antara menemukan sebuah game dan benar-benar bisa mencobanya. Browser memangkas jalur itu secara drastis: buka tautan, muat aset, lalu mulai bermain.

Riset ini berfokus pada proyek yang memiliki build browser yang dapat dimainkan dan kode sumber publik. Ekspor Unity WebGL sengaja dikecualikan karena saya ingin mempelajari game yang dibangun di atas teknologi web, bukan game yang sekadar diekspor ke web.

Proyek terkuat yang saya temukan

Temuan yang paling berguna tidak semuanya kuat karena alasan yang sama. Sebagian memiliki sistem combo paling dalam. Yang lain memiliki arsitektur orang ketiga yang lebih baik, simulasi pertarungan yang lebih bersih, atau benturan fisik yang terasa lebih meyakinkan.

Mengapa hasilnya mengejutkan saya

Hal yang mengejutkan bukan sekadar grafisnya terlihat bagus. Merender adegan yang rapi hanyalah satu bagian dari pengembangan game. Proyek-proyek yang menonjol menerapkan sistem yang sulit dipalsukan secara meyakinkan: input buffering, transisi state pertarungan, pemilihan target, pergerakan serangan, timing animasi, deteksi hit, reaksi musuh, jendela pertahanan, perilaku kamera, dan umpan balik benturan.

Hal itu menghasilkan pembedaan yang berguna:

• timing animasi bukan timing pertarungan;
• frame rate rendering bukan laju simulasi;
• collision tidak otomatis berarti hit yang valid;
• animasi tidak selalu menjadi otoritas pergerakan;
• kontak visual tidak sama dengan benturan yang dirasakan.

Pembedaan ini muncul berulang kali di proyek-proyek terkuat, dan lebih penting daripada logo renderer di README.

Voxel Musou: pertarungan browser bisa memiliki tata bahasa gerakan yang nyata

Voxel Musou adalah salah satu contoh paling jelas bahwa pertarungan browser tidak lagi harus berarti satu animasi serangan yang dipetakan ke satu tombol. Kode sumbernya tersedia di mike007jd/voxel-musou.

Proyek ini menggunakan rantai serangan normal yang panjang dan cabang charge, bukan combo yang sepenuhnya linear. Hal ini penting dari sisi arsitektur karena sistemnya dapat dimodelkan sebagai:

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

Ini merupakan fondasi yang jauh lebih baik untuk game character-action dibanding kumpulan percabangan kondisi kasus khusus yang terus bertambah. Proyek ini juga mendemonstrasikan serangan udara, rangkaian khusus, beberapa kit karakter, perilaku bos, hit-stop, dan pertarungan melawan kelompok musuh dalam jumlah besar.

Pelajaran rekayasa yang lebih luas adalah bahwa gerakan harus menjadi data dan transisi harus dibuat eksplisit. Setelah itu tercapai, menambahkan karakter lain tidak lagi mengharuskan penulisan ulang seluruh controller pertarungan.

Long Wind: yang paling mendekati game aksi browser modern

Long Wind adalah salah satu referensi terpadu terkuat karena menggabungkan pergerakan orang ketiga dengan serangan ringan dan berat, lock-on, guarding, perfect parry, kekebalan saat dodge, tekanan posture, eksekusi, reaksi launch dan knockdown, proyektil, bos, serta beberapa arketipe musuh. Kode sumbernya tersedia di jbang2004/long-wind.

Nilainya bukan karena setiap fiturnya secara individual belum pernah ada, melainkan karena fitur-fitur itu hidup berdampingan dalam satu prototipe aksi yang memang dibangun untuk browser. Itu menjadikannya referensi yang berguna untuk menelusuri seluruh alur dari input ke pemilihan target, state serangan, animasi, kontak, reaksi, hit-stop, hingga umpan balik kamera.

Motion warping menyelesaikan masalah yang sering diabaikan demo web

Samurai Third-Person Template ThreeJS sangat menarik karena menangani masalah klasik pertarungan jarak dekat orang ketiga. Kode sumbernya tersedia di achrefelouafi/SamuraiThirdPersonTemplateThreeJS.

Animasi serangan yang dibuat sebelumnya mengasumsikan target berada pada jarak tertentu ketika pukulan mencapai frame kontaknya. Dalam game nyata, posisi target hampir tidak pernah benar-benar sempurna. Jika karakter hanya memainkan animasi di tempat, pedang bisa terlihat meleset meskipun game menerapkan damage. Jika karakter diteleportasikan ke posisi yang tepat, serangan terlihat artifisial.

Motion warping memberi jawaban yang lebih baik: sesuaikan rotasi dan translasi selama serangan agar karakter mencapai posisi kontak yang diharapkan pada momen yang tepat.

Pembedaan pentingnya adalah:

animation intent != movement authority

Karakter dapat mempertahankan maksud visual dari animasi yang dibuat sebelumnya sementara controller gameplay tetap menjadi otoritas atas ke mana karakter benar-benar bergerak.

Deteksi collision dan validasi hit adalah dua masalah yang berbeda

Stick & Steel mengeksplorasi model pertarungan yang sangat berbeda. Kode sumbernya tersedia di Rabneba/stick-steel.

Alih-alih memperlakukan pedang terutama sebagai animasi dengan damage volume, proyek ini memberi senjata keberadaan fisik. Kecepatan kontak, orientasi senjata, bagian tubuh, guard, benturan senjata, knockdown, dan pelucutan senjata semuanya berpengaruh.

Pelajaran yang paling mudah diterapkan di tempat lain bukan bahwa setiap game aksi harus memakai senjata yang sepenuhnya berbasis fisika. Intinya adalah ini:

Collision memberi tahu bahwa dua objek bersentuhan. Collision tidak memberi tahu apakah terjadi hit yang bermakna.

Sistem pertarungan yang meyakinkan sering membutuhkan lapisan kedua yang menentukan apakah kontak memiliki kecepatan yang cukup, arah yang benar, bagian senjata yang benar, timing yang benar, serta state target yang valid agar dapat dihitung sebagai damage.

Resolusi pertarungan terpusat membuat pertahanan kompleks lebih mudah dipahami

Hollowmere, dengan kode sumber di euuuuuuan/hollowmere-public, lebih menonjol karena arsitektur perangkat lunaknya daripada tontonan visual.

Simulasi pertarungannya dipisahkan dari rendering, dan resolusi pertahanan dipusatkan. Ini menghindari mode kegagalan umum dalam game aksi ketika sistem dodge, sistem parry, sistem reaksi hit, dan lapisan animasi dapat secara independen tidak sepakat apakah serangan yang sama benar-benar mengenai target.

Model mental yang lebih bersih adalah:

incoming attack -> evade | parry | hit

Renderer seharusnya menampilkan hasil, bukan menciptakan versi kedua dari kebenaran pertarungan.

Pembedaan ini semakin penting ketika sistem pertarungan membesar. Simulasi deterministik dan transisi state yang eksplisit bukan fitur yang glamor, tetapi keduanya membuat pertarungan kompleks lebih mudah diuji, di-debug, dan dikembangkan.

Game feel adalah sistem rekayasa, bukan dekorasi

Fabled Revolutions, dengan kode sumber di ericrius1/FabledRevolutions, berguna justru karena memisahkan efek-efek yang membuat hit terasa berbobot.

Sistem pertarungan yang secara logika benar tetap bisa terasa lemah. Collision bisa akurat, damage bisa diterapkan pada frame yang tepat, tetapi hasilnya masih bisa terasa seperti dua model saling menembus.

Benturan yang dirasakan sering berasal dari tumpukan efek berumur pendek:

• hit-stop;
• guncangan atau hentakan kamera;
• jejak visual senjata;
• partikel benturan;
• kilatan saat terkena hit;
• knockback;
• reaksi animasi;
• suara dengan timing yang tepat.

Ini menunjukkan pembedaan berguna lainnya: kebenaran mekanis pertarungan bukanlah game feel pertarungan. Game browser membutuhkan keduanya.

Renderer bukan prediktor utama kualitas pertarungan

Salah satu pola yang lebih menarik dalam riset ini adalah bahwa pertarungan terbaik tidak ditentukan oleh apakah sebuah proyek memakai API rendering terbaru.

Three.js muncul berulang kali. Beberapa proyek memakai teknologi rendering terkait WebGPU, sementara yang lain menggunakan stack konvensional berbasis WebGL. Engine fisika, TypeScript, JavaScript, Vite, WebAssembly, dan berbagai pendekatan rendering semuanya muncul dalam riset ini.

Namun pertarungan yang canggih lebih konsisten bergantung pada arsitektur: simulasi fixed-step, state eksplisit, penargetan yang andal, kepemilikan animasi yang masuk akal, gerakan berbasis data, resolusi damage terpusat, dan umpan balik benturan yang baik.

Ini kabar baik bagi pengembang web. Anda tidak perlu menunggu setiap pengguna memiliki stack grafis terbaru sebelum bereksperimen dengan desain pertarungan yang serius.

Mengapa distribusi melalui browser mengubah perhitungannya

Browser memiliki keunggulan yang tidak banyak berkaitan dengan grafis: hambatan distribusinya sangat rendah.

Game tradisional sering menempatkan beberapa langkah antara penemuan dan interaksi: menemukan halaman toko, mengunduh paket besar, menginstalnya, menjalankannya, menunggu pembaruan, dan terkadang membuat akun sebelum mencapai gameplay yang bermakna.

Game browser dapat memangkas jalur itu menjadi sebuah tautan.

Hal ini mengubah cara prototipe dapat dibagikan dan diuji. Pengembang dapat memublikasikan build, mengirim URL, membuat orang lain langsung masuk ke versi yang sama, mengumpulkan umpan balik, lalu men-deploy iterasi lain tanpa meminta tester menginstal paket baru secara manual.

Keunggulan ini menjadi sangat penting untuk game eksperimental dan pengembangan independen. Browser bukan hanya runtime; browser juga merupakan sistem distribusi.

Di mana browser masih kalah

Riset ini tidak meyakinkan saya bahwa browser telah menggantikan platform game native. Belum.

Beberapa batasan tetap penting:

• Payload aset besar. Akses instan berhenti terasa instan ketika game membutuhkan unduhan awal yang sangat besar.
• Tekanan memori. Browser harus hidup berdampingan dengan tab lain dan sistem operasi, dan perilaku memorinya kurang dapat diprediksi dibanding proses native khusus.
• Batas termal perangkat seluler. Game 3D yang secara teknis berfungsi tetap bisa mengalami throttling parah dalam sesi yang lebih panjang.
• Perbedaan antar-browser. Grafis, audio, pointer lock, perilaku fullscreen, controller, dan karakteristik performa tidak sepenuhnya seragam.
• Persiapan shader dan aset. Proses kompilasi atau upload masih dapat menimbulkan jeda yang terlihat jika pipeline tidak dirancang dengan hati-hati.
• Batasan offline dan persistensi lokal. Aplikasi native memiliki kontrol yang lebih langsung atas instalasi lokal besar dan file.
• Keamanan kompetitif. Anti-cheat yang serius dan asumsi klien yang dianggap tidak tepercaya menjadi jauh lebih sulit ketika klien berupa aplikasi web.

Batasan ini penting karena menentukan di mana game browser paling kuat saat ini: game yang mendapat manfaat dari akses langsung, iterasi cepat, distribusi lintas platform, serta anggaran aset/runtime yang terkendali.

AI membuat loop dari prototipe ke URL jauh lebih singkat

AI relevan di sini, tetapi bukan karena AI secara ajaib mengubah satu kalimat menjadi game berkualitas tinggi yang sudah selesai. Keunggulan yang lebih realistis adalah kecepatan iterasi.

Pengembangan game modern memiliki banyak tugas kecil yang jika dijumlahkan menjadi mahal: menyiapkan state machine, membuat tampilan debug, menulis pengujian, bereksperimen dengan perilaku musuh, membuat format data untuk gerakan, merefaktor kode input, membuat prototipe shader, memeriksa bug fisika, dan merangkai konten sementara.

AI dapat mempersingkat banyak loop tersebut. Jika digabungkan dengan distribusi web, alur kerjanya menjadi sangat langsung:

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

Browser sudah membuat deployment menjadi cepat. AI juga dapat mempercepat sisi implementasi dari loop yang sama.

Catatan pentingnya adalah bahwa generasi cepat tidak menggantikan selera atau validasi. Controller pertarungan yang dihasilkan bisa salah secara struktural. Timing animasi tetap membutuhkan penilaian manusia. Fisika tetap perlu di-debug. Performa tetap perlu diukur. AI mengurangi biaya untuk mencoba ide; AI tidak menghilangkan kebutuhan untuk memutuskan ide mana yang bagus.

Apa artinya ini bagi pengembang web

Batas antara pengembangan web dan pengembangan game semakin tidak kaku.

Game browser yang serius sekarang dapat memakai perangkat web yang familiar sekaligus membutuhkan konsep rekayasa game klasik:

• langkah simulasi tetap;
• state machine;
• input buffering;
• graf animasi;
• kueri spasial;
• fisika;
• anggaran frame;
• manajemen sumber daya GPU;
• timing audio;
• sistem deterministik.

Pada saat yang sama, pengembang game yang menargetkan browser mendapatkan hal-hal yang sudah sangat dikuasai web: URL, deployment instan, pengiriman lewat CDN, pembaruan cepat, telemetri, sistem akun, antarmuka responsif, dan berbagi tanpa hambatan.

Riset ini mengubah cara pandang saya sendiri. Saya tidak lagi melihat game browser terutama sebagai versi sederhana dari game native. Saya melihat browser sebagai platform game yang semakin mampu dengan serangkaian kekuatan berbeda: distribusi instan, iterasi cepat, kemampuan 3D yang semakin serius, serta ekosistem pengembangan yang sudah sangat besar.

Web bukan sekadar semakin baik dalam menampilkan game yang dibuat di tempat lain. Web semakin menjadi tempat di mana sistem game yang serius dapat dirancang, diimplementasikan, diuji, didistribusikan, dan dimainkan secara langsung.