Apa yang sebenarnya diperlukan untuk membangun dunia terbuka di browser
Oleh Mariana Muntean, CEO Cinevva
Tim Cinevva baru saja menerbitkan salah satu jurnal rekayasa paling transparan dalam sejarah terkini pengembangan gim: sebuah seri 12 bagian yang mendokumentasikan upaya kami membangun dunia terbuka multipemain yang berjalan sepenuhnya di browser. Tanpa unduhan. Tanpa toko aplikasi. Hanya sebuah URL.
Proyek ini mencakup 24 eksperimen teknis yang kami sebut "spike" -- prototipe singkat dan terfokus yang masing-masing dirancang untuk menjawab satu pertanyaan berisiko. Setiap spike dirilis dengan kode sumber aktif yang dapat Anda buka dan jalankan di browser saat ini juga. Seri ini ditulis oleh Oleg Sidorkin, CTO dan salah satu pendiri Cinevva, dan lebih terasa seperti jurnal lapangan dari garis depan kemampuan browser yang sebenarnya pada 2026 daripada materi pemasaran.
Hal yang membuat seri ini layak dibaca -- bahkan jika Anda tidak pernah berencana membangun sistem medan -- adalah metode yang mendasarinya. Ini merupakan studi kasus tentang cara mengurangi risiko proyek ambisius sebelum Anda berkomitmen pada sesuatu yang mahal.
Memulai dari pertanyaan tersulit
Sebagian besar proyek dunia terbuka gagal dalam urutan yang dapat diprediksi. Pertama, Anda mendapatkan konsep yang indah. Lalu, adegan yang menarik. Kemudian, Anda menyadari bahwa seluruh anggaran frame sudah habis bahkan sebelum gameplay tersedia.
Tim kami membalik urutannya. Spike pertama sengaja dibuat sederhana dan tidak menarik: mesh medan sepanjang 512 meter, 500 objek instans, noise ketinggian prosedural, bidang air, dan kabut. Tanpa bayangan, tanpa tahap pemolesan visual. Satu-satunya pertanyaan adalah apakah browser dapat mempertahankan frame rate yang stabil saat kamera bergerak melintasinya.
Ternyata bisa. Dan jawaban "ya" itu menetapkan sesuatu yang disebut Oleg sebagai "kontrak baseline" -- biaya referensi terukur untuk adegan minimal, yang menjadi pembanding bagi setiap fitur berikutnya untuk membuktikan kelayakannya. Jika efek baru tampak hebat tetapi melampaui anggaran frame, efek itu tidak dirilis. Setidaknya, belum.
Disiplin semacam itu terdengar jelas dan masuk akal. Dalam praktiknya, hal tersebut jarang ditemui di lingkungan pembuatan prototipe yang bergerak cepat, tempat semua orang bersemangat mengejar pencapaian visual berikutnya.
Pertaruhan fisika
Eksperimen kedua menangani perdebatan arsitektur yang memecah para pengembang gim browser: apakah fisika sebaiknya dijalankan di thread utama, yang lebih sederhana, atau di Web Worker, yang tidak dapat memblokir rendering?
Fisika berbasis worker lebih bersih di atas kertas. Dalam praktiknya, kekhawatiran utamanya adalah latensi. Setiap peristiwa input harus dua kali melintasi batas pesan: sekali untuk mencapai worker, dan sekali lagi untuk membawa hasilnya kembali. Jika perjalanan bolak-balik itu terlalu lambat, jeda antara menekan tombol dan melihat karakter bergerak akan terasa lamban.
Tim mengintegrasikan mesin fisika Rapier (dikompilasi dari Rust ke WebAssembly) dalam worker khusus, merangkai pipeline pesan, lalu melakukan pengukuran. Overhead-nya dapat diabaikan. Kontrol tetap terasa instan. Namun, kami berhati-hati untuk mencatat bahwa yang divalidasi adalah satu skenario tertentu, bukan aturan universal. Ketika tekanan GPU dan kompleksitas streaming berubah di kemudian hari, asumsi tersebut perlu diperiksa kembali.
Spike membosankan yang menyelamatkan proyek
Bagian ketiga dari seri ini tidak memiliki tangkapan layar. Bagian tersebut membahas tiga eksperimen yang tampak tidak menarik, tetapi memiliki konsekuensi di tingkat produk.
Eksperimen pertama menguji apakah Cloudflare Durable Objects dapat menangani siaran posisi secara real-time pada tick rate setara gim -- tulang punggung sistem multipemain. Jika gagal, seluruh arsitektur jaringan akan memerlukan sharding sejak awal, alih-alih kepemilikan satu pulau oleh satu instance.
Eksperimen kedua memvalidasi profil kualitas seluler: bukan preset desktop yang sekadar diganti namanya, melainkan jalur rendering berbiaya rendah yang dirancang secara eksplisit dari baseline medan yang sama. Pertanyaannya adalah apakah dunia tersebut dapat tetap mudah dibaca dan responsif di bawah keterbatasan GPU seluler tanpa menulis ulang renderer.
Eksperimen ketiga mengevaluasi apakah skrip perilaku yang dihasilkan AI untuk alur kerja kreator cukup andal untuk digunakan dalam produksi.
Tak satu pun menghasilkan demo yang memukau. Namun, ketiganya menetapkan batasan tegas yang membentuk setiap keputusan arsitektur setelahnya. Oleg menulis bahwa "spike yang tidak mencolok ini mengubah arsitektur lebih cepat daripada spike visual."
Streaming: titik runtuhnya proyek-proyek yang indah
Anda dapat menyembunyikan banyak hal dalam satu frame diam. Namun, Anda tidak dapat menyembunyikan tersendat selama 40 milidetik ketika pemain berlari melintasi batas chunk.
Tim menguji streaming sebelum membangun medan tingkat lanjut, dengan sengaja memisahkan berbagai aspek pengembangan. Spike 6 memvalidasi pemuatan chunk di sekitar pemain menggunakan konten sederhana. Baru setelah mendapatkan sinyal yang jelas itu, Spike 11 memperkenalkan streaming heightmap terkompresi dengan penyempurnaan progresif -- memuat medan terlebih dahulu pada resolusi 17 sampel, kemudian 33, lalu grid penuh 65 sampel.
Urutan tersebut ternyata lebih penting daripada yang kami duga. Seandainya kami langsung memulai dengan chunk ketinggian terkompresi, penyebab setiap gangguan akan menjadi ambigu. Apakah masalahnya terletak pada decoding, kemacetan saat mengunggah tekstur, atau pembaruan geometri? Menguji streaming sederhana terlebih dahulu menghilangkan satu kategori ketidakpastian secara keseluruhan.
Sebuah pelajaran praktis pun muncul: ukur kemacetan saat pengunggahan secara langsung, bukan melalui FPS rata-rata. Nilai rata-rata menyembunyikan lonjakan waktu frame, padahal lonjakan itulah yang benar-benar dirasakan pemain.
Perebutan anggaran visual
Tiga eksperimen terpisah membedah biaya rendering secara terisolasi, alih-alih menggabungkannya. Kepadatan dan animasi angin pada vegetasi. Material medan berlapis dengan pemetaan triplanar untuk permukaan tebing. Cascaded shadow maps di bawah beban medan yang realistis.
Spike vegetasi mengungkap bahwa mengelompokkan berbagai instance ke dalam lebih sedikit mesh jauh lebih penting daripada mengurangi jumlah poligon per helai. Spike material menemukan bahwa proyeksi triplanar pada permukaan vertikal sepadan dengan biaya GPU-nya, tetapi penambahan lapisan texture splat kelima tidak. Spike bayangan menentukan bahwa tiga cascade pada resolusi 1024 menghasilkan contact shadow yang memadai tanpa melampaui 2 milidetik waktu GPU.
Tim menerapkan aturan tegas: sebuah fitur hanya boleh dilanjutkan jika biayanya dapat dijelaskan dengan data waktu frame yang terukur. Batasan yang ditetapkan sejak awal itu membuat keputusan arsitektur selanjutnya seputar medan volumetrik dan clipmap menjadi jauh lebih jelas.
Perubahan arah yang mengubah lintasan proyek
Sebelum Spike 10, model mental kami adalah "dunia yang lebih besar berarti lebih banyak geometri." Setelah Spike 10, model itu berubah menjadi "anggaran geometri konstan, dengan pembaruan cincin yang berpusat pada kamera."
Geometry clipmap -- cincin-cincin medan konsentris yang berpusat pada kamera, dengan setiap cincin semakin kasar -- membuat jumlah segitiga tetap relatif konstan, berapa pun jarak gambarnya. Trik praktisnya adalah geomorphing pada batas cincin: memadukan ketinggian vertex secara halus di shader sehingga perpindahan antara tingkat resolusi tidak terlihat saat bergerak.
Ada pelajaran halus dari metodologi pengujian. Clipmap tampak baik-baik saja dalam tangkapan layar. Artefaknya baru terlihat saat kamera terus bergerak melintasi batas cincin. Tim menghabiskan waktu melakukan lintasan berkecepatan konstan dan mengamati noise temporal. "Tangkapan layar berbohong," tulis Oleg. "Gerakan menunjukkan kenyataan."
Menjelajah ke bawah tanah
Heightmap tidak dapat merepresentasikan gua. Heightmap hanya menyimpan satu nilai elevasi untuk setiap titik pada grid. Begitu Anda membutuhkan terowongan, bagian batu yang menggantung, atau permukaan batu yang dipahat, Anda memerlukan medan volumetrik.
Spike 12 mengimplementasikan marching cubes di GPU menggunakan compute shader WebGPU, dengan mengekstraksi mesh segitiga dari signed distance field 3D. Empat chunk berukuran 64 kubik berjalan secara bersamaan, dengan pembaruan mesh per frame dari pengeditan SDF yang dianimasikan. Compute shader menangani semuanya -- mengevaluasi field, mengklasifikasikan sel, menghasilkan vertex -- tanpa readback CPU sama sekali.
Tantangannya bukan sekadar membuatnya bekerja. Tantangannya adalah membuatnya bekerja berdampingan dengan semua sistem lain. Integrasi dengan scene graph Three.js, pengelolaan siklus hidup buffer (buffer WebGPU tidak dapat diubah ukurannya), penanganan fence agar resource GPU yang masih diproses tidak dihancurkan -- seri ini mencurahkan dua bagian penuh untuk hal yang kami sebut "pengerasan bertahap", yaitu proses tidak glamor untuk menambahkan satu kemampuan pada satu waktu dan memastikan lapisan sebelumnya tetap berfungsi setelah setiap penambahan.
Mimpi buruk sambungan
Bagian paling menguras tenaga secara teknis dalam seri ini mencakup Bagian 9 hingga 11, yang membahas apa yang terjadi saat chunk medan dengan resolusi berbeda saling bertemu.
Ketika chunk beresolusi tinggi berdampingan dengan chunk beresolusi rendah, mesh yang dibuat secara independen tidak sejajar pada batasnya. Hasilnya adalah retakan yang terlihat, tepian yang berkedip, dan T-junction yang membuat cahaya bocor. Algoritma Transvoxel menyelesaikannya dengan sel transisi khusus yang menjembatani perbedaan resolusi -- tetapi mengimplementasikannya dengan benar untuk semua konfigurasi chunk, dengan urutan winding yang konsisten, pengelolaan buffer yang tepat, dan draw range yang akurat, menghabiskan enam eksperimen terpisah.
Kisah debugging tim yang paling berkesan: dua hari dihabiskan untuk memburu artefak sambungan yang kami kira berasal dari logika transisi. Penyebab sebenarnya adalah data usang. Compute shader GPU menulis N vertex ke dalam buffer, tetapi draw call masih dikonfigurasi untuk merender N+M vertex dari frame sebelumnya. Vertex tambahan tersebut berisi data sampah yang menghasilkan segitiga setipis silet dan berkedip-kedip. Perbaikannya hanya satu baris: batasi draw range ke jumlah vertex aktif dari atomic counter.
"Bug rendering sering menyamar sebagai bug meshing," kata Oleg. "Geometrinya ternyata sudah benar sejak awal."
Dari kekacauan menuju tata kelola
Setelah pergulatan dengan sambungan, tim mengganti perilaku chunk ad hoc dengan sistem kebijakan yang eksplisit. Kini, sebuah fungsi pusat menentukan tingkat LOD setiap chunk, mode rendering-nya (heightmap atau marching cubes), serta sisi mana yang membutuhkan sel transisi. Cincin jarak menentukan LOD dasar. Batasan ketetanggaan memastikan tidak ada dua chunk bersebelahan yang berbeda lebih dari satu tingkat resolusi. Bitmap pengeditan mempertahankan chunk volumetrik dalam mode marching-cubes berapa pun jaraknya jika chunk tersebut berisi modifikasi dari kreator.
Overlay debug berkode warna -- hijau untuk chunk heightmap, biru untuk marching cubes, oranye untuk sisi transisi -- mengubah laporan seperti "Saya melihat bug di suatu tempat dekat punggung bukit itu" menjadi "bug muncul di posisi (142, 12, -67) menghadap barat laut."
"Kebijakan tidak mengurangi kompleksitas," tulis Oleg. "Kebijakan menata kompleksitas."
Hasil akhirnya
Spike terakhir menggabungkan cincin clipmap, kabut langit per fragmen (mengambil sampel warna skybox sebenarnya ke arah setiap fragmen medan), dan perangkaian modul Three.js menjadi satu demonstrasi terpadu. Hasilnya adalah sistem medan yang menggabungkan pengeditan volumetrik jarak dekat, chunk heightmap jarak menengah, dan cincin clipmap jarak jauh di bawah lapisan kebijakan yang mengatur mode, LOD, dan transisi.
Seri ini ditutup dengan pelajaran yang menurut Oleg akan ia terapkan kembali pada proyek apa pun di masa depan:
- Mulailah dengan spike risiko sebelum mengerjakan fitur. Tuntaskan pertanyaan "apakah ini bahkan bisa dilakukan?" sebelum berinvestasi dalam pipeline konten.
- Bekukan baseline yang sudah terbukti baik sebelum melakukan lompatan integrasi. Satu hari yang dihabiskan untuk menetapkan checkpoint bersih akan menghemat beberapa hari untuk melacak sumber regresi di kemudian hari.
- Terapkan kebijakan dan observabilitas sebelum menjalani maraton optimasi. Kondisi yang diberi nama dan disertai aturan pemicu selalu lebih baik daripada bug misterius.
- Uji dalam gerakan, bukan melalui tangkapan layar. Perubahan mendadak, kedipan, dan gangguan streaming semuanya tersembunyi dalam frame diam.
- Ukur waktu frame per fitur, bukan FPS rata-rata. Nilai rata-rata menyembunyikan lonjakan yang benar-benar dirasakan pengguna.
- Publikasikan bagian-bagian yang berantakan. Jalan buntu, perburuan bug semu, dua hari menyalahkan sistem yang keliru. Bagian-bagian itulah yang benar-benar dapat dipelajari orang lain.
Mengapa ini penting di luar Cinevva
Seri ini penting karena tiga alasan yang melampaui pipeline medan milik satu perusahaan.
Pertama, seri ini menunjukkan bahwa compute shader WebGPU, fisika WebAssembly, dan Durable Objects yang diterapkan di edge telah melewati sebuah ambang batas. Dunia terbuka multipemain dengan medan volumetrik, pengeditan real-time, dan streaming LOD kini layak secara arsitektural untuk dijalankan dalam satu tab browser pada 2026. Hal itu belum berlaku dua tahun lalu.
Kedua, metodologi spike -- eksperimen kecil dan terfokus yang masing-masing menjawab satu pertanyaan berisiko dengan hasil langsung serta terukur -- menawarkan pola bagi tim mana pun yang mencoba sesuatu yang mungkin tidak berhasil. Disiplin untuk mengukur sebelum berkomitmen, menetapkan baseline sebelum melakukan integrasi, dan mengidentifikasi kasus tepi sebelum mengoptimalkan dapat diterapkan jauh melampaui sistem medan.
Ketiga, transparansi radikal adalah inti utamanya. Menerbitkan kode sumber untuk seluruh 24 eksperimen, termasuk jalan buntu dan penyimpangan debugging selama dua hari, menjadikan ini lebih dari sekadar blog teknis. Ini adalah buku catatan rekayasa publik yang memperlakukan pembaca sebagai rekan kerja, bukan pelanggan. Seri lengkapnya tersedia di panduan seri, dengan setiap eksperimen teknis yang dapat dijalankan langsung di browser.
Artikel ini awalnya diterbitkan di Medium.