Halo. Belakangan ini saya membuat sendiri sebuah game mobile bernama ‘Sumbi’. Ini adalah roguelike vertikal yang terinspirasi dari aktivitas menyelam haenyeo Jeju. Dengan satu tarikan napas, Anda masuk ke laut untuk memanen hasil laut, lalu memutuskan apakah akan lebih serakah atau kembali sekarang.
Saya mulai merancang pada 2 Juli, mengunggah build pertama ke Google Play pada 9 Juli, lalu terus memperbaiki bagian yang terasa kurang saat dimainkan, hingga pada 19 Juli saya mengunggah build v1.1 ke production.
Sejak awal, yang membuat saya penasaran bukan sekadar “seberapa cepat AI bisa menulis kode”. Jika beberapa model AI diberi peran berbeda dan dijalankan seperti satu tim pengembang, sejauh mana mereka benar-benar bisa membuat game yang layak dirilis? Itulah yang ingin saya uji.
Game seperti apa ini
‘Sumbi’ diambil dari ‘sumbisori’, bunyi napas mirip siulan yang dihembuskan haenyeo saat selesai menyelam dan naik ke permukaan.
Satu ronde berlangsung sekitar 10–30 detik. Dengan satu tangan, Anda menggerakkan haenyeo untuk turun lebih dalam atau memanen hasil laut di sekitar. Anda harus menyentuh permukaan dengan selamat agar bisa membawa pulang hasil tangkapan secara utuh, jadi Anda akan terus menimbang apakah ingin sedikit lebih serakah atau kembali sekarang. Setelah naik, Anda menghitung hasil tangkapan, meningkatkan kapasitas paru-paru, kaki katak, jaring, dan ketajaman penglihatan, lalu menyelam lagi.
Saya memasukkan draft roguelike yang memilih satu dari tiga kemampuan tiap ronde, ensiklopedia hasil laut berisi 60 jenis, perlengkapan dan pohon pertumbuhan, kenaikan peringkat haenyeo, serta jalur napas yang berlanjut hingga 100 m. Kontrol dibuat sederhana, tetapi semakin sering menyelam, rekor dan build yang dibidik akan berubah.
Saya tidak memakai AI sebagai satu pengembang serbabisa
Jika satu model menangani semuanya mulai dari perancangan, implementasi, hingga pemeriksaan mandiri, ia cenderung menganggap premisnya sendiri sebagai jawaban yang benar. Karena itu saya membagi perannya seperti ini.
- Fable 5: struktur game dan spesifikasi fitur, target keseimbangan ekonomi, perancangan syarat selesai
- Opus 4.8: implementasi Flutter·Flame, penulisan test, debugging
- Fable 5: membandingkan ulang spesifikasi awal dengan hasil implementasi untuk memeriksa kelalaian dan regresi
- Codex GPT-5.5: meninjau kode dan perubahan secara independen serta menunjukkan edge case
Urutan kerjanya kurang lebih adalah perancangan → implementasi → verifikasi ulang oleh perancang awal → code review independen → test otomatis dan playtest langsung.
Setelah dicoba, ternyata yang lebih penting daripada menulis prompt dengan keren adalah lebih dulu menetapkan syarat selesai yang bisa diverifikasi. Alih-alih “buat rasa progresinya bagus”, saya menetapkan angka seperti jumlah pembelian dalam 10 menit pertama, waktu yang dibutuhkan hingga kenaikan peringkat pertama, dan apakah ada fase progresi di mana pemain terlalu lama tidak bisa membeli apa pun. Setelah itu, saya memeriksanya dengan simulator ekonomi dan test.
Saat ini ada 627 test otomatis dan semuanya lolos. Analisis statis Flutter juga lolos tanpa error pada cakupan kode aplikasi, test, dan tool.
Contoh AI yang salah dengan cara yang tampak meyakinkan
Desain pertama tidak langsung menjadi game yang menyenangkan.
Pada versi awal, target yang bisa dipanen dalam satu ronde hanya 5–9 buah. Padahal ini game memanen, tetapi lautnya terlihat kosong. Setelah saya coba sendiri, struktur ini saya buang. Saya ubah agar medan menjadi semakin kaya seiring progres, dan di tempat yang sudah dipanen hasil laut akan tumbuh lagi. Pada build progresi tertentu, sekitar 40 buah bisa dipanen dalam satu ronde.
Pohon progresinya juga mirip. Nodenya memang mencapai 290, tetapi permainan nyatanya hampir lurus satu jalur. AI memenuhi permintaan “290 node”, tetapi tidak sampai menciptakan keseruan dalam memilih. Akhirnya saya memisahkan lagi strukturnya menjadi tiga jalur spesialisasi dan node permanen.
AI bisa membuat banyak kode dengan cepat, tetapi tidak bisa menjamin keseruan dan prioritas. Bermain langsung sambil mengatakan tegas “ini tidak seru” atau “fiturnya banyak, tetapi tujuan berikutnya tidak terlihat” tetap merupakan porsi manusia.
Saya juga membuat pipeline sendiri untuk gambar dan suara
Aset gambar utama seperti karakter haenyeo, hasil laut, perlengkapan, dan ikon kartu dibuat dengan GPT image generation API. Sheet yang dihasilkan tidak dipakai apa adanya; saya memasukkannya ke pipeline koreksi yang mencakup penghapusan chroma key, perataan frame, penyamaan ukuran, dan kuantisasi piksel, lalu memeriksanya. Latar belakang, gelembung, dan berkas cahaya sebagian besar digambar lewat kode.
Untuk suara, alih-alih mengumpulkan aset eksternal, saya mensintesis WAV dengan kode Dart. Bunyi sumbi yang terdengar saat penyelaman berakhir dijadikan suara inti yang mempertemukan nama game dan akhir sebuah ronde.
Pemikiran saya berubah setelah selesai membuatnya
Sering dikatakan bahwa “AI akan bekerja baik kalau diberi instruksi dengan baik”. Kali ini, yang lebih besar saya pelajari justru bahwa “harus ada struktur yang bisa menangkap kesalahan saat AI keliru”.
Saya memisahkan perancang, implementator, dan pemeriksa, lalu membiarkan model yang berbeda menelaah rencana dan kode secara agresif. Penilaian akhirnya saya serahkan pada angka, test, dan permainan nyata. Cara ini jauh lebih stabil daripada melanjutkan percakapan panjang dengan satu model lalu menyerahkan semuanya padanya.
Meski AI makin cepat, bottleneck pengembangan solo tidak hilang. Sebaliknya, posisi bottleneck berpindah dari coding ke penilaian. Menentukan apa yang dipertahankan dan dibuang, serta mengapa game belum terasa seru saat ini, justru memakan waktu paling lama.
Google Play
https://play.google.com/store/apps/details?id=com.kinderia.sumbi
Karena ini masih game buatan solo, masih banyak kekurangannya. Saya ingin mendengar pendapat apakah game ini kurang seru, atau apakah menu progresinya terlalu rumit. Jika ada pertanyaan tentang cara pengembangan atau pembagian peran tiap model, silakan tinggalkan komentar.
Belum ada komentar.