Bagaimana Roblox Mengevaluasi Pembuatan Game Build

Build, alat pembuatan berbasis seluler pertama kami yang baru, memungkinkan pengguna Roblox membuat game menggunakan petunjuk teks dan menerbitkannya kepada pemain di seluruh dunia. Membuat game yang holistik memerlukan sistem agen end-to-end untuk pembuatan game: sistem yang mengoordinasikan kode, aset visual, sistem gameplay, antarmuka pengguna, dan kontrol menjadi satu artefak gabungan. Sistem ini harus dapat menangani berbagai skenario yang muncul akibat masukan pemain dan interaksi multipemain dengan kokoh. Sejak peluncuran versi alpha di Selandia Baru, lebih dari 100.000 pemain telah menggunakan Build untuk mencoba membuat game, dan sekitar 9.000 game Build telah dipublikasikan.¹ Dari ribuan orang yang telah menggunakan Build untuk membuat game, 71% di antaranya belum pernah menggunakan Roblox Studio sebelumnya,¹ yang menunjukkan bahwa mereka mencoba hal baru dengan Build.

Namun, para kreator hanya akan menggunakan alat baru ini jika mudah digunakan dan kualitas game yang dihasilkannya cukup tinggi untuk dikembangkan lebih lanjut. Untuk memahami kualitas game yang dibuat dengan Build, kami mengevaluasi perjalanan pembuatan dari awal hingga akhir dan menggunakan evaluasi tersebut serta umpan balik dari kreator untuk meningkatkan produk. Kerangka kerja evaluasi (eval) kami telah membantu kami memprioritaskan dan meningkatkan pemahaman niat, kelancaran permainan 3D, dan penyempurnaan. Sejak peluncuran alpha Build di Selandia Baru, kepuasan kreator telah meningkat 10%, hasil yang tidak diinginkan turun dari 18% menjadi 3%, dan sekitar 14% dari sesi yang dipicu serta 19% dari uji coba permainan telah dipublikasikan.² Ini adalah indikator deskriptif kemajuan, bukan perkiraan kausal dari dampak evaluasi saja.

Mengapa Evaluasi Pembuatan Game Berbeda

Game memiliki beberapa tantangan evaluasi yang sama dengan sistem lain yang menghasilkan artefak gabungan, seperti aplikasi, video, dan model dunia. Misalnya, kualitas bergantung pada bagaimana berbagai komponen bekerja sama, dan tidak ada skor komponen tunggal yang sepenuhnya menggambarkan hasilnya. 

Yang membedakan game adalah bahwa artefak tersebut merupakan sistem yang dapat dijalankan secara real-time dan dikendalikan oleh pemain. Sifat-sifat seperti responsivitas, kebebasan bertindak, perkembangan, dan nuansa permainan muncul melalui interaksi dan tidak dapat dievaluasi sepenuhnya hanya dengan memeriksa kode atau aset saja. Oleh karena itu, sebuah game harus memenuhi standar yang sangat tinggi dalam hal keakuratan tingkat rendah (bebas dari cacat dan dapat dimainkan), serta pengalaman pemain tingkat tinggi (game yang terasa selesai, bukan sekadar prototipe). 

Pertanyaan yang ingin kami jawab melalui evaluasi bukanlah apakah satu bagian tertentu sudah benar, melainkan apakah artefak secara keseluruhan sesuai dengan maksud pembuatnya, dan apakah pemain dapat menjalani seluruh pengalaman tersebut. Untuk menjawabnya, dibutuhkan lebih dari satu metrik.

Empat Sinyal, Satu Kerangka Kerja

Kerangka kerja evaluasi pembuatan Build kami menggabungkan empat sinyal. Masing-masing menjawab pertanyaan yang berbeda, mendeteksi jenis kegagalan yang berbeda, dan menghasilkan skor kuantitatif yang konkret:

1. Kualitas spesifikasi game (skor 0–100): Build adalah agen penciptaan end-to-end: Ia menerjemahkan prompt pembuat menjadi spesifikasi, lalu menggunakannya untuk menghasilkan game. Penilai mengevaluasi apakah spesifikasi tersebut membuat keputusan penting secara eksplisit, mempertahankan niat pembuat, mempertimbangkan kelayakan dalam runtime Roblox, dan menghindari penambahan persyaratan yang tidak pernah diungkapkan.

2. Kualitas game statis (skor 0–100): Penilai bagian statis memeriksa game yang dihasilkan dalam mode edit Roblox Studio. Hal ini mencakup struktur game, skrip, aset, properti, koneksi, serta batas klien/server. Kami berusaha menjawab dua pertanyaan pada tahap ini. Yang pertama adalah apakah game tersebut dibangun dengan benar: implementasi sistem yang diperlukan, pilihan API mesin dan jaringan, keberadaan kontrol dan komponen UI yang diharapkan, serta ketangguhan dan koherensi arsitektur game. 

Yang kedua adalah apakah game tersebut dirancang agar menyenangkan: kedalaman loop inti, variasi dan eskalasi konten, perkembangan, daya ulang, serta inovasi di luar standar genre. Sebuah game bisa saja memiliki arsitektur yang rapi tetapi tidak memiliki kedalaman konten, atau penuh dengan ide tetapi penghubungannya buruk. 

Memisahkan kedua sudut pandang ini dan mengukurnya berdasarkan praktik terbaik memberi kita gambaran yang lebih terperinci mengenai di mana letak kegagalan game tersebut.

3. Uji Coba (tingkat kelulusan 0–100%): Penilai uji coba menjalankan permainan dan melaksanakan rencana pengujian dengan masukan yang menyerupai pemain sungguhan, termasuk ketukan, klik, penekanan tombol, dan navigasi, bukan dengan memicu peristiwa dari kode. Rencana pengujian per kasus memeriksa apakah game dapat dimulai, merespons, berjalan lancar, pulih dari kegagalan, dan bebas dari kesalahan saat dijalankan. Setiap item dinilai lulus/gagal, dilaporkan sebagai tingkat kelulusan yang diberi bobot berdasarkan tingkatan, disertai dengan penilaian sederhana dapat dimainkan/tidak dapat dimainkan. Kami mengulangi pengujian untuk mengukur konsistensi.

4. Kualitas visual dan pengalaman (skor 0–100): Beberapa aspek terpenting dari tampilan dan nuansa permainan tidak dapat dibaca dari kode, sehingga penilai visual memberikan skor presentasi secara terpisah menggunakan rekaman gameplay pada tampilan yang mewakili perangkat berbeda. Kriteria penilaian ini hanya melihat bagaimana permainan terlihat dan terdengar berdasarkan kualitas aset, penyelesaian antarmuka pengguna (UI), gerakan, pencahayaan, dan audio. Pertanyaan intinya adalah: Apakah game ini terlihat seperti produk yang siap dirilis, atau seperti prototipe? Memisahkan aspek visual dari mekanika berarti bahwa “kode berfungsi” dan “game terlihat selesai” tidak digabungkan menjadi satu skor yang menyesatkan.

Selain sinyal yang diberi skor, setiap eksekusi merekam metrik yang hanya bersifat informatif, seperti penggunaan token, panggilan alat, keterampilan yang dipicu, dan latensi. Metrik ini tidak memengaruhi skor evaluasi, tetapi dapat menjelaskan bagaimana suatu hasil dihasilkan dan mendeteksi regresi yang terlewatkan oleh rubrik, seperti build yang biayanya menjadi dua kali lipat untuk game yang sama.

Sinyal-sinyal tersebut dipetakan ke kegagalan yang terdeteksi:

Menjelajahi Lintasan Obby 3D yang Dipandu

Sinyal-sinyal tersebut paling mudah dilihat pada prompt yang sebenarnya. Misalnya, “Game obby 3D sejati, dengan platform awal, rintangan bergerak, titik pemeriksaan, dan garis finis.” Obby adalah jenis game platforming yang populer di Roblox. Maksud pembuatnya jelas, meskipun tidak merinci setiap detail implementasinya. Pembuat perlu mengisi detail tersebut dengan asumsi yang masuk akal.

Rencana dan Spesifikasi

Tim Pengembangan membuat dokumen spesifikasi untuk game baru berjudul Skyforge Ascent, yang merinci lintasan lima bagian dengan titik pemeriksaan dan tiga jenis bahaya. Dokumen tersebut mendefinisikan loop inti, kurva kesulitan, arahan seni, layar, overlay, dan kontrol. Evaluasi spesifikasi memberikan skor 91/100, dengan nilai sempurna pada kelengkapan, kepatuhan terhadap tenggat waktu, kelayakan, dan konsistensi internal. Pengurangan skor berasal dari dua dimensi spesifik: detail implementasi dan cakupan kriteria penerimaan. 

Spesifikasi tersebut tidak pernah menetapkan konstanta numeriknya, seperti kecepatan putaran, jarak selip, waktu ubin, dimensi platform, atau ketinggian bidang reset, sehingga seorang insinyur masih harus menentukannya sendiri. Selain itu, beberapa kriteria penerimaan (seperti “sekitar 24 platform” atau “palet celestial-forge”) tidak sepenuhnya dapat diuji kebenarannya. Skor spesifikasi yang tinggi hanya membuktikan bahwa dokumen tersebut siap untuk dikembangkan. Apakah komitmen-komitmen tersebut tetap bertahan saat berhadapan dengan pengembangan game yang sebenarnya adalah hal yang akan diukur pada tiga tahap berikutnya.

Pemeriksaan Statis: Kualitas Kode dan Kualitas Konten

Juri virtual memeriksa berkas tempat (placefile) Skyforge Ascent tanpa memainkannya, dan kedua sudut pandang evaluasi tersebut mencapai kesimpulan yang berbeda.

Lensa teknik, yang membaca placefile yang sama, memberinya skor 98/100. Lensa ini menemukan sebuah build yang patut dicontoh dengan lima bagian dan tiga rintangan bergerak, yang sepenuhnya memenuhi maksud pembuatnya dengan menggunakan titik pemeriksaan berurutan yang otoritatif dari server, sistem reset jatuh, dan UI yang dibangun di atas kerangka kerja StyleSheet. Semua yang diuraikan dalam spesifikasi telah terpenuhi. Satu-satunya masalah adalah dua ekspor fungsi pembantu yang tidak digunakan.

Sudut pandang desain memberinya skor 31/100. Semuanya berfungsi, tetapi game ini mendapat skor nol untuk progres, daya ulang, kebebasan pemain, dan daya tarik orisinal. Loop inti game ini sederhana dan linier—mencapai setiap titik pemeriksaan, menyeberangi garis finis—dengan variasi yang minim di setiap putaran dan tidak ada alasan untuk memainkannya kembali. Ini adalah ciri khas genre obby, bukan game dengan daya tariknya sendiri.

Kesenjangan itulah yang menjadi temuan utama. Kualitas kode dan kualitas konten adalah dimensi yang secara fundamental berbeda, dan sebuah build bisa hampir sempurna dalam satu aspek namun gagal dalam aspek lainnya. Skor kualitas tunggal yang digabungkan hanya akan merata-ratakan keduanya menjadi sesuatu yang tidak berarti.

Uji Coba

Agen pengujian bermain game ini menggunakan input yang mirip dengan pemain sungguhan dan berhasil melewati kesembilan item dalam rencana pengujian: memunculkan karakter di platform awal, menavigasi geometri 3D melintasi celah, menerima dampak bahaya, memicu titik pemeriksaan dan pemulihan jatuh otomatis, menyelesaikan lari, serta memulai ulang, semuanya tanpa kesalahan runtime. Dalam putaran pengujian ini, Skyforge Ascent meraih skor 100/100.

Skor playtest yang sempurna hanya membuktikan bahwa mekaniknya berfungsi dan game tersebut secara teknis dapat dimainkan dari awal hingga akhir. Hal ini tidak menunjukkan apakah game tersebut benar-benar menarik atau menyenangkan untuk dimainkan—perbedaan itulah yang menjadi alasan mengapa penilaian dari sudut pandang desain memberinya skor 31.

Kualitas Visual

Terakhir, sistem evaluasi menilai sesi yang direkam pada tampilan seukuran ponsel untuk presentasi visual. Skyforge Ascent meraih skor 86/100: bersih, padu, dan sejalan dengan visual game platformer tipikal; geometri platform yang mudah dibaca; rintangan yang jelas; serta HUD modern yang tidak mengganggu. Batasan visual minor menghalangi game ini mencapai kesempurnaan, tetapi tidak ada yang rusak, dan tidak ada yang akan membuat pemain berhenti menggulir.

Metrik Pelacakan

Proses yang sama juga merekam metrik proses. Game ini membutuhkan waktu sekitar delapan menit untuk dibangun, tidak ada kesalahan alat, dan Build menggunakan keterampilan 3D, UI, pengeditan skrip, penyisipan aset, serta audio game. Metrik ini tidak memengaruhi skor evaluasi secara langsung, tetapi memberi tahu kami bagaimana game ini dibuat dan akan menandai build di masa depan yang menjadi lebih lambat atau lebih mahal tanpa keuntungan apa pun.

Melalui lima tahap, Skyforge Ascent memperoleh skor yang berbeda-beda dalam spesifikasi game, kualitas kode, kualitas konten, uji coba, dan kualitas visual. Empat dari dimensi tersebut menunjukkan bahwa Build dapat mengubah satu prompt menjadi pengalaman Roblox yang lengkap, benar, dapat dimainkan, dan layak ditampilkan. Satu dimensi menunjukkan bahwa ini bukanlah game yang akan dipilih siapa pun untuk dimainkan dua kali. Mengukur kesenjangan tersebut, alih-alih mengabaikannya dengan menghitung rata-rata, adalah inti dari evaluasi Build.

Bagaimana Evaluasi Dini Telah Meningkatkan Build 

Hasil evaluasi tidak hanya menghasilkan skor, tetapi juga memberikan arahan yang dapat ditindaklanjuti untuk perbaikan produk. Dengan menggabungkan debugging komponen individu dengan pengujian holistik tingkat sistem, evaluasi batch offline melalui rangkaian prompt standar telah secara langsung membentuk pengembangan Build. 

1. Menyelesaikan masalah utama pembuat alpha dengan cepat: Dalam peluncuran alpha di Selandia Baru, pengguna memberi masukan bahwa Build terkadang menghasilkan game 2D padahal mereka menginginkan game 3D. Kerangka kerja evaluasi membantu tim kami dengan cepat meningkatkan kemampuan 3D Build. Dalam waktu dua minggu, kami meningkatkan kemampuan Build untuk memahami niat pengguna dalam membuat game 3D—bahkan jika mereka tidak secara eksplisit menyatakannya. Kami juga menyempurnakan kelancaran bermain dan penyempurnaan 3D dengan memperbaiki masalah umum terkait penempatan objek, pencahayaan, dan sebagainya. Sejak saat itu, keluhan “bukan yang saya inginkan” turun dari 18% menjadi 3% di antara semua keluhan; reaksi ketidakpuasan secara keseluruhan setelah uji coba turun 10 poin persentase. Kami juga memperoleh pembelajaran saat melakukan iterasi pada kerangka kerja itu sendiri. 
2. Perbandingan benchmark antar model dan arsitektur: Kami menggunakan kerangka kerja evaluasi kami untuk membandingkan konfigurasi sistem Build secara ketat dengan rangkaian prompt standar. Sebelum menerapkan perubahan ke produksi, laporan evaluasi A/B offline membandingkan rilis yang diusulkan dengan baseline produksi kami di keempat dimensi berikut: 

Misalnya, perbedaan offline ini memungkinkan kami mengisolasi bagaimana berbagai peningkatan model dan keputusan perutean agen memengaruhi sinyal kualitas individu:

• Kinerja model dasar: Peningkatan model dasar kami menghasilkan peningkatan yang konsisten di setiap sinyal—yang mengakibatkan lebih sedikit build yang gagal pada percobaan pertama, penyempurnaan visual yang lebih baik, dan konten gameplay yang lebih mendalam.
• Arsitektur perutean agen: Sebaliknya, mendelegasikan sub-tugas tertentu ke model ringan dalam pengaturan agen ganda mempertahankan kedalaman dan keragaman konten, tetapi menyebabkan kemunduran tajam dalam hal kemudahan bermain dan hasil akhir visual.

1. Melacak tolok ukur kualitas di berbagai paradigma pembuatan: Kami juga menggunakan kerangka kerja ini untuk memahami kualitas build saat ini pada waktu yang berbeda dengan kumpulan evaluasi yang paling relevan. Kumpulan ini memberikan gambaran sekilas tentang tugas-tugas pembuatan yang semakin luas dan kompleks.
   Kumpulan paling awal terdiri dari game 2D sepenuhnya dengan mekanisme yang relatif sederhana. Logika gimnya mudah dibuat, sehingga skor playtest cenderung lebih tinggi; di sisi lain, skor konten tetap rendah karena alasan yang sama persis.
   Saat kami mengalihkan fokus ke game 3D, distribusi skor bergeser secara alami: permainan bebas bug menjadi lebih menantang, sehingga menurunkan skor playtest. Skor visual tetap datar karena kurangnya penyempurnaan aset, yang membuat game terasa seperti prototipe. Skor konten lebih tinggi karena game 3D berpotensi lebih mendalam—tetapi skor keseluruhan cenderung tetap rendah karena prompt satu giliran menawarkan ruang terbatas untuk perluasan konten.

1. Mengungkap hambatan spesifik genre: Data evaluasi juga menyoroti variasi kinerja yang signifikan di berbagai genre. Genre yang menekankan mekanisme permainan (misalnya, RPG, game penembak, dan game balap) cenderung menghadapi lebih banyak masalah terkait kemudahan bermain. Genre dengan logika yang relatif sederhana (misalnya, game survival dan tycoon) sering kali menunjukkan kinerja yang lebih baik dalam uji coba permainan, sehingga penyempurnaan visual dan desain UI menjadi tonggak berikutnya yang harus diselesaikan. Mengetahui perbedaan antar genre mendorong kami untuk memperluas set evaluasi dengan pengambilan sampel yang lebih seimbang di seluruh game Build.
2. Pelajaran yang dipetik dalam desain kerangka kerja evaluasi: Mengulangi pengembangan kerangka kerja itu sendiri mengajarkan kami pelajaran penting tentang keandalan kerangka kerja:

• Metrik sistem vs. metrik komponen: Struktur kode yang rapi atau penggunaan API tidak menjamin sebuah game dapat dimainkan. Kami memisahkan keakuratan, desain, dan presentasi untuk menghindari tersembunyinya bug yang dapat ditindaklanjuti.
• Kelemahan kerangka kerja evaluasi dan kalibrasi manusia: Pemeriksaan statis dapat melewatkan penghambat runtime yang menyebabkan game crash, sementara pengujian bermain otomatis kesulitan menangani fisika yang kompleks. Juri virtual terus dikalibrasi berdasarkan pengembang game profesional dan pengulas komunitas yang berpengalaman.
• Memperluas ke multiturn dan lalu lintas nyata: Karena kreator sungguhan terus melakukan iterasi (menambahkan sistem, menyesuaikan tingkat kesulitan, memperbaiki bug), kami memperluas kerangka kerja evaluasi kami untuk mengevaluasi pengeditan multiturn dan distribusi prompt di dunia nyata.

Langkah Selanjutnya

Saat ini kami berfokus pada perluasan sistem evaluasi pembuatan Build ke lima arah:

1. Cakupan yang lebih luas di berbagai genre, pengalaman 2D/2.5D/3D, skenario multipemain, dan tingkatan kompleksitas
2. Dukungan yang lebih kuat untuk pengeditan multi-putaran
3. Bukti playtest, tangkapan layar, video, dan audio yang lebih andal
4. Kalibrasi terhadap penilaian manusia dalam skala besar dan kasus tolok ukur yang dipimpin oleh kreator
5. Integrasi yang lebih baik antara evaluasi offline, sinyal produk online, dan pengujian regresi

Tujuan jangka panjang kami adalah sistem evaluasi yang transparan dan terus ditingkatkan, yang mengukur Build pada tingkat yang menjadi perhatian para kreator: kualitas pengalaman yang dapat mereka buat, uji, bagikan, dan kembangkan lebih lanjut. Saat ini, sinyal-sinyal ini digunakan untuk mengevaluasi game yang dihasilkan oleh Build. Seiring waktu, saat kami terus menyempurnakan dan menyesuaikannya dengan penilaian manusia, sinyal-sinyal ini mungkin dapat diterapkan pada alur kerja pembuatan lainnya dan membantu menyediakan bahasa bersama untuk memahami kualitas game di seluruh ekosistem Roblox yang lebih luas.

Untuk pandangan terkait mengenai evaluasi sistem agen untuk Roblox Assistant, lihat artikel “Menggunakan OpenGameEval untuk Membandingkan Asisten AI Berbasis Agen di Roblox Studio”.