WebGL dan WebAssembly: Kenapa Game Browser Sekarang Cepat

Sebuah mobil melompat dari satu platform ke platform lain di Car Stunt Master 3D, dan seluruh adegan itu berjalan di dalam tab peramban. Tidak ada pemasangan, tidak ada mesin game yang diunduh, dan tidak ada pengaturan grafis. Dua teknologi di balik layar membuat hal itu mungkin, dan keduanya mengerjakan pekerjaan yang sangat berbeda.

Menyebut keduanya sebagai satu paket adalah kesalahan umum. WebGL dan WebAssembly tidak saling menggantikan, dan memahami pembagian tugasnya menjelaskan kenapa sebagian game browser terasa mulus sementara yang lain tersendat meski grafisnya sederhana.

Dua pekerjaan berbeda: menggambar dan menghitung

Pembagian ini penting karena dua jenis beban itu berbeda sifatnya. Menggambar lebih berat di pengolah grafis, sementara perhitungan lebih berat di prosesor. Game yang mulus biasanya berhasil menyeimbangkan keduanya, bukan hanya salah satunya.

WebGL: memberi peramban akses ke pengolah grafis

Sebelum WebGL, peramban hanya bisa menggambar lewat kanvas dua dimensi, dan hampir semua pekerjaannya dilakukan prosesor. Untuk game sederhana itu cukup. Untuk objek tiga dimensi yang berubah setiap frame, hasilnya tersendat karena prosesor harus menghitung posisi setiap titik gambar satu per satu.

WebGL memindahkan pekerjaan itu ke pengolah grafis, yang memang dirancang untuk menggambar ribuan segitiga secara paralel. Konsekuensinya, jumlah objek dan pencahayaan bisa jauh lebih banyak tanpa membuat frame rate jatuh. Di game jalur langit seperti di atas, setiap platform, mobil, dan bayangan adalah kumpulan segitiga yang harus digambar ulang puluhan kali per detik, dan itulah beban yang ditangani WebGL.

Yang tidak dilakukan WebGL adalah berpikir. Ia tidak tahu bahwa mobil sedang jatuh atau bahwa tabrakan harus mengurangi kecepatan. Ia hanya menggambar apa yang diperintahkan.

WebAssembly: mesin hitung yang mendekati kecepatan asli

WebAssembly adalah format biner yang dijalankan peramban dengan kecepatan mendekati kode asli. Sebelumnya, logika game ditulis dalam JavaScript, bahasa yang nyaman tapi tidak dirancang untuk perhitungan berat seperti simulasi fisika dengan banyak objek.

Dengan WebAssembly, pengembang bisa membawa mesin fisika yang sudah ada, menulisnya dalam bahasa seperti C atau Rust, lalu menjalankannya di browser tanpa menulis ulang semuanya. Hasilnya terasa di hal-hal kecil: mobil yang memantul tidak kehilangan momentum, tabrakan tidak tertunda satu frame, dan jumlah objek yang bisa dihitung bertambah.

Bagi pemain, perbedaannya muncul sebagai rasa. Game yang perhitungannya berjalan di JavaScript sering terasa "lengket" ketika banyak hal terjadi sekaligus, terutama saat ledakan atau tabrakan beruntun.

Analogi dapur, dan satu contoh yang gagal

Bayangkan restoran. WebAssembly adalah dapur: memotong, memasak, menghitung porsi. WebGL adalah bagian penataan: menaruh makanan di piring serapi mungkin. Kalau dapurnya lambat, penyajian tidak akan menolong; kalau penataannya kacau, makanan enak tetap terlihat tidak menarik. Yang membuat restoran berjalan adalah keduanya bekerja dengan kecepatan yang sepadan.

Contoh kegagalannya mudah ditemukan. Sebuah game bisa menggambar model tiga dimensi yang indah lewat WebGL, tapi jika logika tabrakannya masih dihitung dengan cara yang boros, mobil akan menembus dinding tepat ketika layar penuh objek. Gejalanya khas: gambar tetap halus, tapi aturan permainan terasa terlambat.

Sebaliknya, ada game yang perhitungannya rapi tapi gambarnya berat, sehingga perangkat kelas bawah kehabisan tenaga sebelum sempat menikmati mekaniknya. Dalam dua kasus itu, masalahnya bukan salah satu teknologi, melainkan ketidakseimbangan.

Arti bagi perangkat kelas bawah

Kabar baiknya, kedua teknologi ini tidak menuntut perangkat baru. WebGL sudah tersedia di hampir semua peramban modern, dan WebAssembly berjalan di perangkat yang sama. Laptop lima tahun dengan grafis terintegrasi tetap bisa menjalankan game tiga dimensi sederhana, seperti game satu jalur yang hanya butuh beberapa objek di layar.

Yang tetap membatasi adalah hal-hal di luar teknologi: memori, panas, dan baterai. Game yang memuat banyak tekstur besar akan menghabiskan memori peramban, dan game yang memaksa pengolah grafis bekerja terus-menerus akan membuat perangkat panas. Karena itu, pengembang biasanya mengurangi bayangan, jarak pandang, dan jumlah efek di versi yang ditargetkan untuk ponsel.

Kalau game terasa lambat di perangkatmu, urutan pemeriksaan yang masuk akal: tutup tab lain, matikan mode hemat daya, lalu coba layar penuh. Kalau masih tersendat, masalahnya kemungkinan ada pada beban memori, bukan pada kecepatan gambar.

Ada satu konsekuensi yang jarang dibicarakan: karena kedua teknologi ini tersedia di hampir semua peramban, perbedaan antar game lebih ditentukan oleh keputusan pengembang daripada oleh perangkat pemain. Dua game bisa memakai teknologi yang sama dan terasa sangat berbeda, karena satu memilih tekstur besar dengan banyak efek, sementara yang lain memilih bentuk sederhana dengan warna datar. Ketika kamu membandingkan game dalam satu daftar, yang sebenarnya kamu bandingkan adalah pilihan-pilihan itu.

Batas yang tidak bisa dilewati juga jelas. Dunia terbuka besar dengan tekstur beresolusi tinggi tetap terlalu berat untuk dimuat lewat halaman web, karena ukuran asetnya akan melebihi kesabaran siapa pun. Jadi sampai batas tertentu, kecepatan game browser sekarang bukan tanda bahwa semuanya bisa dibawa ke browser, melainkan tanda bahwa genre yang tepat sudah ditemukan.

Itu juga alasan game balap satu jalur dan game lintasan pendek lebih sering muncul daripada game dengan peta luas. Bukan karena pengembangnya kurang ambisius, tapi karena batas memori peramban lebih ketat daripada batas kesabaran pemain.