Mengapa kami membangun mesin WebGPU sendiri alih-alih melakukan fork PlayCanvas

Oleh Oleg Sidorkin, CTO dan Salah Satu Pendiri Cinevva

Setiap orang teknis yang melihat Cinevva World menanyakan hal yang sama dalam waktu lima menit. Tim Anda kecil. Mesin 3D web yang matang sudah tersedia. Mengapa Anda menulis renderer, fisika karakter, dan sistem animasi sendiri, alih-alih memanfaatkan PlayCanvas atau Babylon agar bisa merilis lebih cepat?

Itu pertanyaan yang wajar, dan sindrom "bukan buatan sendiri" bukanlah jawaban yang tepat. Kami melakukan riset. Kami menjalankan mesin-mesin yang sudah ada, membaca kode sumbernya, dan membuat purwarupa di atas dua di antaranya sebelum mengambil keputusan. Tulisan ini adalah versi jujur dari keputusan tersebut: apa yang benar-benar dikuasai oleh opsi siap pakai, empat bagian tempat kebutuhan kami menyimpang cukup jauh sehingga layak dibangun sendiri, serta situasi ketika Anda sebaiknya memilih salah satunya daripada meniru kami. Proses pembangunannya sendiri kami dokumentasikan dalam seri rekayasa dunia terbuka di browser yang berlangsung panjang, jadi jika sebuah pernyataan di bawah memiliki catatan implementasi yang mendukungnya, saya akan menautkannya.

Opsi yang benar-benar kami evaluasi

Ada empat hal yang disebut "mesin game web," dan semuanya bukan jenis perangkat yang sama.

Three.js adalah pustaka rendering, bukan mesin game. Three.js memberi Anda scene graph, material, loader, dan renderer, lalu membiarkan Anda bekerja sesuka hati. Tidak ada editor, fisika, sistem entitas, maupun ketentuan tentang cara game Anda harus disusun. Itulah daya tarik sekaligus biayanya. Anda membangun sendiri segala sesuatu di atas renderer, tetapi tidak ada yang menghalangi Anda. Lisensinya MIT, ekosistemnya adalah yang terbesar di bidang ini, dan ketika Anda menemukan bug shader yang tidak lazim pada pukul 2 pagi, biasanya sudah ada jawaban yang menunggu di forum.

Babylon.js adalah mesin lengkap dengan scene graph, integrasi fisika (Havok), pipeline aset, dan editor web. Lisensinya MIT, didukung oleh tim di Microsoft, dan pengembangan WebGPU-nya bergerak cepat. Jika Anda menginginkan solusi lengkap dan nyaman bekerja dalam struktur mesin tersebut, Babylon.js adalah pilihan awal yang kuat.

PlayCanvas adalah hal yang paling mendekati "Unity untuk web." Saat tulisan ini dibuat, mesinnya berada di v2.19.6, yang dirilis pada 5 Juni 2026, dan mesin itu sendiri bersifat sumber terbuka di bawah lisensi MIT. Namun, yang sebenarnya digunakan oleh kebanyakan orang adalah editor visual yang di-host, dan editor tersebut merupakan produk komersial, bukan sumber terbuka. PlayCanvas menggunakan sistem entitas-komponen, Anda menulis skrip dalam TypeScript atau JavaScript, aset diproses melalui pipeline GLB sisi server, dan game komersial sungguhan telah dirilis dengannya (salah satunya, Snap menjalankan proyek produksi menggunakan PlayCanvas). Renderer-nya berjalan dengan WebGL2, sedangkan jalur WebGPU-nya masih dalam tahap pematangan dan belum menjadi pilihan default. Detail terakhir itu lebih penting daripada kelihatannya, dan saya akan membahasnya lagi nanti.

Unity WebGL sebenarnya bukan mesin web. Ini adalah target ekspor. Anda membangun di editor desktop Unity lalu mengompilasinya menjadi bundle WebGL. Ini adalah alat yang tepat jika Anda sudah memiliki game Unity dan ingin menghadirkannya di browser, tetapi alat yang keliru jika "langsung dimuat di tab pada ponsel kelas menengah" merupakan persyaratan mutlak, karena runtime dan besarnya unduhan ikut terbawa.

Semua opsi ini merupakan fondasi yang masuk akal untuk game web biasa. Game web kami tidak biasa.

Keputusan pertama: WebGPU adalah titik awal kami, bukan garis finis

Perbedaan yang membuat kami meninggalkan semua solusi siap pakai adalah ini. Bagi kami, WebGPU merupakan persyaratan, bukan fitur yang akan kami gunakan kelak.

Terrain kami bukan heightmap statis. Terrain ini merupakan perpaduan antara bidang heightmap yang dialirkan dan chunk marching cubes yang didukung oleh signed-distance field, sehingga dunia dapat memiliki gua dan bagian tebing menjorok yang nyata, serta kreator dapat memahatnya secara langsung. Kuas pemahat, penyebaran vegetasi, dan pembuatan mesh terrain semuanya berjalan sebagai compute shader. Hilangkan komputasi, dan dunia ini bukan sekadar mengalami penurunan kualitas—dunia ini tidak akan berjalan.

Itu berkebalikan dengan posisi mesin serbaguna saat ini. Dukungan WebGPU mereka dirancang sebagai peningkatan progresif di atas renderer yang mengutamakan WebGL2, dengan jalur fallback untuk browser yang tidak mendukungnya. Secara khusus, PlayCanvas mengutamakan WebGL2, sementara WebGPU masih dalam versi beta. Itu merupakan keputusan yang tepat bagi mereka karena tugas mereka adalah menjalankan sebanyak mungkin jenis game di sebanyak mungkin perangkat. Tugas kami lebih sempit dan lebih mendalam, jadi kami mengambil keputusan sebaliknya: kami sepenuhnya beralih ke WebGPU pada purwarupa ke-13 dan tidak pernah menoleh ke belakang. Browser tanpa WebGPU tidak mendapatkan versi dengan kualitas lebih rendah, melainkan tidak didukung, dan kami mencatatnya sebagai angka jangkauan alih-alih berpura-pura bahwa fallback WebGL2 hanya membutuhkan perubahan satu opsi konfigurasi. Kenyataannya tidak demikian. Itu akan menjadi penulisan ulang sebagian dari tahap terrain dan vegetasi kami.

Membangun di atas mesin yang mengutamakan WebGL2 berarti kami harus melawan asumsi fallback-nya pada setiap fitur komputasi atau selamanya memelihara dua jalur rendering. Dengan memiliki renderer sendiri, kami dapat menjadikan komputasi sebagai fondasi dasar.

Keputusan kedua: solver karakter, bukan mesin fisika

Langkah yang lazim adalah memasukkan mesin fisika. Kami mencobanya. Purwarupa awal memvalidasi Rapier yang berjalan dalam worker, dan hasilnya terasa cukup baik.

Kami tetap menulis solusi sendiri, dan tidak ada Rapier, Cannon, maupun Ammo di mana pun dalam versi yang dirilis. Alasannya adalah cakupan. Kami tidak membutuhkan rigid body, joint, ragdoll, atau constraint solver. Kami membutuhkan satu kapsul yang bergerak dengan benar terhadap terrain, serta membutuhkan berjalan, meluncur di permukaan, melayang, memanjat, dan berenang agar semuanya menyepakati satu jawaban yang sama untuk pertanyaan "apakah saya berpijak, di permukaan apa, dan pada sudut berapa." Mesin fisika serbaguna justru membuat hal itu lebih sulit, bukan lebih mudah, karena mode-mode tersebut akhirnya harus melawan pegas dan peredam internalnya.

Jadi, pengontrol karakter kami adalah state machine multikanal yang dapat dipasang-lepas. Setiap mode adalah unit kecil yang menyatakan apakah ia ingin mengambil kendali pada frame ini dan, jika menang, menetapkan kecepatan serta arah hadap. Semuanya bersaing berdasarkan prioritas di tiga kanal—resource, lalu stance, kemudian locomotion—dan semuanya membaca kueri terrain yang sama. Tabrakan menggunakan probe kapsul terhadap heightmap atau signed-distance field, tergantung pada chunk-nya.

Detail yang paling saya banggakan justru tidak glamor. Deteksi pijakan memindai setiap permukaan dalam kolom vertikal di bawah kaki Anda dan memilih permukaan tertinggi yang berada tepat pada atau di bawah kapsul, alih-alih memercayai gradien SDF. Di tepi bagian tebing yang menjorok, permukaan terdekat secara horizontal adalah sisi tebing, sehingga normal berbasis gradien berubah-ubah antara "lantai" dan "dinding" dan membuat Anda seolah-olah meluncur tanpa sebab. Kueri kolom membuat berdiri di tepian terasa biasa saja, dan memang itulah yang diinginkan. Collider heightfield siap pakai tidak akan memberi kami kemampuan itu secara cuma-cuma karena sejak awal ia tidak dapat melihat terrain kami. Terrain tersebut berada di GPU dalam format kami sendiri. Tidak ada mesin eksternal yang dapat menangani tumbukan terhadapnya tanpa mengharuskan kami menyalin seluruh bidang ke dalam format collider mesin itu setiap kali terjadi pengeditan.

Keputusan ketiga: animasi yang dapat dipindahkan antar-rig

Avatar menggunakan rig Synty POLYGON, dan klip gerakan kami berasal dari pustaka animasi terbuka yang besar. Karena rig dan klip tersebut memiliki nama tulang yang sama, kasus umum tidak memerlukan retargeting saat runtime; track cukup di-bind berdasarkan nama. Kami menulis keseluruhan pipeline karakter dalam karakter universal.

Pekerjaan yang menarik muncul ketika keduanya tidak cocok. Kami membangun tahap retargeting yang memetakan satu skeleton ke skeleton lain, dan agar hasilnya tepat, kami harus menyelesaikan tiga masalah khusus. Pertama, Anda menyelaraskan bind pose karena A-pose yang dipasangkan dengan T-pose secara diam-diam menambahkan sekitar tiga puluh derajat pada setiap joint. Kedua, Anda menskalakan root motion dan langkah menggunakan dua rasio berbeda: pinggul-ke-lantai untuk arah vertikal dan proporsi keseluruhan untuk arah horizontal. Ketiga, Anda menguji klip hasil retargeting terhadap sumbernya pada sample rate tetap agar regresi terlihat sebelum pemain menemukannya. Pipeline itulah yang memungkinkan kami menambahkan sumber animasi baru, dan kelak karakter buatan kreator, tanpa memperbaiki setiap klip secara manual.

Di atasnya terdapat state machine animasi yang memilih kelompok klip yang tepat pada setiap frame berdasarkan status gerakan: variasi lompatan berdasarkan kecepatan, tingkat kerasnya pendaratan berdasarkan benturan, arah lereng dari dot product antara kecepatan dan gradien terrain, penghentian yang disesuaikan dengan fase kaki agar karakter tidak berjalan mundur seperti moonwalk saat berhenti, serta debounce seratus milidetik agar benturan dengan dinding tidak membuat animasi berkedip antara berjalan dan jatuh. Tidak satu pun dari hal ini terasa eksotis, tetapi inilah jenis kemampuan yang hanya Anda peroleh dengan memiliki sendiri lapisan tersebut.

Keputusan keempat: bagian yang tidak disediakan oleh mesin mana pun

Tiga keputusan lainnya membahas cara dunia ini berjalan. Keputusan ini membahas produk yang sebenarnya kami bangun, dan inilah alasan mengapa perbandingan dengan PlayCanvas pada akhirnya merupakan kekeliruan kategori.

PlayCanvas, Babylon, Unity, dan aplikasi Three.js buatan sendiri semuanya mengasumsikan pola yang sama: Anda membuat game di meja kerja, dalam editor 2D, melihat dunia dari luar, lalu menekan tombol play dan merilis runtime terpisah. Bahkan pengeditan di dalam mesinnya tetap berarti Anda berada di workstation sambil memanipulasi scene yang sedang Anda lihat.

Cinevva World membalikkan pola tersebut. Anda berkreasi dari dalam dunia, sebagai avatar yang berdiri di ruang yang sama dengan tempat para pemain akan berdiri, dengan mendeskripsikan apa yang Anda inginkan dan menyaksikannya muncul. Kreasi dan permainan merupakan satu sesi berkelanjutan, bukan tahap build yang dijembatani ke runtime. Referensi yang paling mendekati adalah Roblox, Rec Room, dan Horizon Worlds, bukan mesin 3D web, dan bahkan platform-platform tersebut masih melakukan sebagian besar proses kreasi dari meja kerja. Hal yang membuat pendekatan ini memungkinkan tanpa editor berbasis mouse adalah pembangun AI, yang mengubah "letakkan dermaga dengan penerangan lentera di sini" menjadi geometri dan penempatan.

Anda tidak bisa sekadar menambahkan kemampuan itu ke mesin serbaguna karena ini bukan fitur rendering. Ini adalah premis seluruh stack, mulai dari cara terrain dapat diedit saat runtime hingga cara jaringan memperlakukan setiap objek sebagai sesuatu yang baru saja dibuat oleh seseorang yang berdiri di dekatnya.

Kapan Anda tidak seharusnya melakukan apa yang kami lakukan

Inilah bagian yang biasanya dilewatkan oleh tulisan bertema "kami membangun mesin sendiri." Jika Anda ingin merilis game browser pada kuartal ini, jangan tiru kami. Gunakan PlayCanvas jika Anda menginginkan editor bergaya Unity dan pipeline terkelola. Gunakan Babylon jika Anda menginginkan mesin lengkap yang sudah menyertakan fisika dan Anda nyaman dengan strukturnya. Gunakan Three.js jika Anda menginginkan kendali maksimal dengan ketentuan minimal dan memiliki tim yang mampu membangun di atasnya. Lakukan port dari Unity jika Anda sudah memiliki game Unity.

Menulis renderer, fisika, dan animasi sendiri hanya merupakan pilihan yang tepat ketika premis produk Anda tidak kompatibel dengan solusi siap pakai—ketika hal yang Anda bangun bukanlah game yang berjalan di atas sebuah mesin, melainkan sebuah tempat yang kebetulan tersusun darinya. Hal itu berlaku bagi kami. Kemungkinan besar hal itu tidak berlaku bagi Anda, dan tidak ada masalah dengan itu. Tujuan evaluasi yang jujur adalah mengetahui Anda berada dalam situasi yang mana sebelum menulis baris pertama.