Membuat game butuh 3 bulan tanpa LLM, 3 hari jika bersama LLM
(marianogappa.github.io)- Seorang insinyur perangkat lunak dengan 15 tahun pengalaman membagikan pengalaman mengembangkan game kartu masa kecilnya dengan bahasa Go
- Saat mengembangkan “Truco” tanpa LLM (model bahasa besar), ia menyelesaikan semua masalah secara manual, termasuk desain UI dan deployment serverless, dan menghabiskan 3 bulan
- Saat membuat “Escoba”, ia memanfaatkan LLM untuk sangat memangkas konversi kode backend dan kecepatan implementasi, dan sebagian besar berhasil berjalan hanya dengan 1 prompt
- Di bagian akhir tulisan, ia memberikan panduan bertahap agar siapa pun bisa membuat game, lengkap dengan contoh Tic-Tac-Toe, backend Go, konversi WASM, dan integrasi React
- Namun, frontend React dan pengelolaan status game berbasis WASM tetap perlu di-debug dan diimplementasikan sendiri
Pengantar
- Seorang insinyur perangkat lunak berpengalaman 15 tahun menyadari bahwa ia belum pernah benar-benar membuat dan merilis game sendiri
- Ia memutuskan untuk mengembangkan salah satu game kartu yang dulu ia mainkan bersama teman-temannya di Argentina saat kecil dengan bahasa Go
Truco: 3 bulan tanpa LLM
- Pada 18 Juni 2024, ia mulai mengembangkan game kartu bernama Truco dengan backend Go. Untuk frontend, ia menulisnya dengan pengetahuan React yang sangat minim
- Implementasi UI menjadi tantangan terbesar, dan agar tidak perlu menyediakan server, ia menggunakan TinyGo untuk mentranspilasi ke WASM (WebAssembly) lalu mendistribusikan file statis ke GitHub Pages
- Karena saat itu belum ada LLM yang digunakan, ia harus mencari sendiri semua detail dan melalui banyak trial and error, hingga selesai dalam sekitar 3 bulan
- Tujuannya murni untuk menyelesaikan game, bukan untuk iklan atau monetisasi, dan bahkan setelah 1 tahun sejak rilis, game itu masih terus dimainkan
- Mainkan Truco: https://marianogappa.github.io/truco-argentino
- Backend (Golang): https://github.com/marianogappa/truco
- Frontend (React): https://github.com/marianogappa/truco-argentino
Escoba: 3 hari bersama LLM
- Setahun kemudian, saat mengunjungi Argentina untuk menemui keluarga, ia mengajarkan keponakannya game kartu terpopuler kedua bernama Escoba
- Kali ini ia memanfaatkan LLM (Claude), menyalin backend Truco, lalu menjelaskan aturan Escoba lewat prompt dan meminta refaktorisasi kode
- Hasilnya hampir sempurna hanya dengan prompt pertama, dan ia hanya perlu memperbaiki sedikit bug kecil serta menambahkan beberapa fitur secara manual
- Frontend tetap perlu diimplementasikan dan di-debug sendiri selama beberapa hari. Keterbatasan LLM, skill React, dan lingkungan yang tidak biasa karena status game dikelola di WASM semuanya menjadi tantangan
- Mainkan Escoba: https://marianogappa.github.io/escoba-de-15
- Backend (Golang): https://github.com/marianogappa/escoba
- Frontend (React): https://github.com/marianogappa/escoba-de-15
Bertahap: cara membuat game sendiri
- Ia memperkenalkan panduan praktik minimal dan contoh kode agar orang lain juga bisa mencoba mengembangkan game sendiri
- Ia menyediakan repositori contoh Tic-Tac-Toe, yang bisa di-fork untuk memulai
Pengembangan backend
- Backend berbasis giliran memungkinkan fungsi-fungsinya dirancang dengan jelas
- Untuk mempertahankan arsitektur serverless, struktur permainan antar-manusia sebaiknya dihindari jika tidak ada server komersial, karena itu adalah pilihan yang lebih realistis
Pengembangan frontend
- Frontend perlu melakukan tugas-tugas berikut
- Meminta pembuatan
GameStatebaru ke backend - Menampilkan status di UI
- Menyediakan antarmuka untuk memilih aksi yang valid
- Mengirim command ke backend saat aksi diterapkan
- Jika giliran bot, mengirim permintaan ke backend
- Meminta pembuatan
Konversi backend ke WASM
- Untuk membangun kode Go menjadi WASM, gunakan
GOARCH=wasm GOOS=js go build - Karena ukuran biner bisa menjadi masalah, ia menggunakan TinyGo untuk menguranginya
- Untuk mengekspor fungsi-fungsi yang akan dihubungkan ke frontend, ia menulis entry point terpisah di Go (misalnya
main_wasm.go) dan memisahkan proses saat build - Di fungsi utama, perlu memblokir dengan
select {}agar program tidak langsung berhenti
Integrasi data backend-frontend
- Struct bebas Go seperti
GameStatetidak bisa langsung di-serialize/deserialize di WASM - Karena itu, semua data perlu dipertukarkan dalam format JSON
- Dengan merujuk pada dokumentasi TinyGo, baik input maupun output dikirim melalui serialisasi JSON
Antarmuka frontend-backend
- Di frontend, fungsi-fungsi backend dipanggil secara langsung
GameStatehanya dikelola di dalam WASM dan frontend tidak bisa memutasinya; backend selalu menjadi source of truth- Setelah WASM dikompilasi ulang, file perlu diganti, dan ia juga memberikan contoh otomatisasi melalui Makefile
Lingkungan eksekusi WASM
- Untuk menjalankannya,
wasm_exec.jsharus disertakan di head, lalu instance dibuat dan dijalankan menggunakan skrip tersebut
Kesimpulan
- Membuat game adalah pengalaman yang menyenangkan, dan kombinasi Go, WASM, dan React adalah pendekatan yang bisa dicoba siapa saja
- Bantuan LLM sangat meningkatkan produktivitas, tetapi kemampuan frontend dan pengalaman debugging tetap penting
- Siapa pun bisa mencoba mengembangkan game sendiri dengan struktur seperti ini, jadi patut dicoba
4 komentar
Kalau kode yang dihasilkan di React memakai
document.getElementById, LLM apa yang dipakai ya....Hampir terasa seperti judul umpan klik yang memancing perhatian..
"Kalau membuat dari awal butuh 3 bulan, kalau membuat yang mirip lagi butuh 3 hari"
Penulis aslinya sepertinya orang yang biasanya tidak tahu dirinya sendiri melakukan apa.
Komentar Hacker News
Hal yang menurutku bagus dari postingan ini adalah bahwa ini menyoroti sesuatu yang sering diabaikan banyak developer. Dalam pengembangan game, coding itu sendiri jarang sekali menjadi bottleneck. Bahkan developer solo pun bisa membuat mekanik dengan cepat tanpa AI. Bagian yang benar-benar sulit adalah berbagai lapisan tak terlihat di atasnya, misalnya balancing game loop, tuning tingkat kesulitan, pembuatan aset yang terasa menyatu, dan polishing yang bisa menjaga minat pemain lebih dari 5 menit. Inilah juga alasan mengapa setelah hadirnya LLM, Steam tidak langsung dipenuhi game-game hebat. Teknologi ini memang menurunkan satu hambatan, tetapi hambatan yang lebih besar tetap ada. Hal yang sama juga terjadi saat Unity muncul pada 2010-an. Engine itu mendemokratisasi pengembangan game, tetapi yang meningkat drastis bukan jumlah game bagus, melainkan jumlah percobaan. LLM pada kode, dan model gambar pada art, memunculkan fenomena yang sama, tetapi tool-tool ini tidak bisa memberi tahu game mana yang benar-benar menyenangkan. Pertanyaan yang menurutku menarik adalah: apa yang terjadi kalau AI bukan hanya mengimplementasikan, tetapi juga melakukan playtest? Artinya, jika ia berkembang sampai tahap bisa menjalankan ribuan loop dan memberi tahu mekanik mana yang mampu mempertahankan pemain simulasi, maka perannya akan meluas dari sekadar productivity hack menjadi partner desain. Kita belum sampai ke tahap itu, tetapi tulisan ini terasa seperti data point awal menuju arah tersebut
Menanggapi pendapat yang penasaran seperti apa masa depan jika AI tidak hanya mengimplementasikan tetapi juga melakukan playtest dengan menjalankan ribuan loop untuk memahami bagaimana pemain bisa dibuat lebih tenggelam, saya jadi bertanya-tanya bagaimana AI bisa mensimulasikan pemain dan mengapa ia bisa menilai dengan tepat apa yang akan benar-benar membuat manusia terlibat
Saya ingin membantah contoh kebangkitan Unity pada 2010-an yang menyiratkan bahwa jumlah game yang benar-benar bagus tidak banyak. Sebenarnya, dibanding era XBLA, volume game yang kita miliki sekarang tidak mungkin ada tanpa tool seperti Unity, Godot, Gamemaker, Renpy, dan RPG Maker. Jadi, jelas ada lonjakan besar bukan hanya secara kualitas tetapi juga secara kuantitas
Litmus test untuk generative AI menurut saya adalah mampu membuat satu sprite sheet lengkap untuk game aksi pixel art 2D. Misalnya, targetnya hanya menghasilkan gerakan tank atau karakter utama dengan sempurna, tetapi sampai sekarang saya belum pernah melihat contoh yang berhasil
Saya rasa pengamatan bahwa "AI tidak bisa memberi tahu apakah game Anda benar-benar menyenangkan" adalah insight utamanya. AI tidak bisa mengalami game seperti manusia sungguhan mengalaminya, dan juga tidak bisa mengalami hal lain seperti manusia. Ia hanya bisa memprediksi sampai batas tertentu berdasarkan data evaluasi manusia terhadap game serupa. Artinya, AI tidak bisa menikmati game Anda. Hakikat ini akan mendefinisikan peran tenaga kerja di era AI ke depan. AI mungkin bisa menulis dokumen atau kode dengan cukup menyerupai manusia berdasarkan data masa lalu, tetapi ini membuktikan bahwa ada integrasi dan pengalaman bermakna yang hanya bisa dilakukan manusia. Ada titik nilai manusia yang tidak bisa tergantikan, hanya saja kita mungkin perlu memandang nilai itu dengan cara berbeda
Pola ini berlaku juga di bidang lain selain pengembangan game. Seperti yang banyak orang harapkan, coding berbasis agent memang punya potensi besar, tetapi untuk saat ini baru sangat unggul pada sebagian tugas saja (demo web app cepat, menghubungkan library kecil, dan semacamnya) dan masih belum memadai untuk software skala besar yang sesungguhnya. Baik cara model ini dilatih maupun keahlian kita dalam memakainya masih sama-sama kurang matang. Ini tidak mengejutkan. Bahkan git pun selama 5 tahun setelah kemunculannya hanya benar-benar diadopsi oleh perusahaan elit, lalu butuh 5 tahun lagi untuk menjadi arus utama. Pada akhirnya sekarang kita sudah sangat terbiasa, tetapi menurut saya LLM justru lebih sulit dipakai dengan benar daripada git. Andai tidak setiap produk, OSS, atau posting blog dibesar-besarkan dengan nada "sekarang semuanya selesai, semuanya sudah direvolusi", mungkin perkembangannya bisa lebih cepat. Kita masih berada dalam masa trial and error dan eksperimen, dan ini butuh waktu. Jangan menilai terlalu cepat. Kalau memang semuanya sudah selesai dipecahkan, setidaknya kita seharusnya sudah terkubur oleh software yang jauh lebih hebat, tetapi saat ini kita baru sebatas menjaga keseimbangan. Untuk teknologi baru yang baru muncul 1–2 tahun, ini sudah cukup mengesankan
Keunggulan 3 bulan yang dimiliki LLM berasal dari kode, penggunaan game sebelumnya sebagai template, dan yang terpenting, seluruh pengalaman serta kesalahan yang terkumpul saat melakukan hand-coding
Awalnya saya kira ini hanya judul sensasional, tetapi saya benar-benar terkejut di bagian "menyalin backend Truco dan meminta Claude merapikan kodenya setelah diberi penjelasan panjang tentang aturan Escoba". Saya jadi penasaran kalau refactor itu dilakukan manusia langsung akan memakan waktu berapa lama. Rasanya bisa lebih dari 3 hari, tapi mungkin juga tidak
Hal lain yang penting adalah ini merupakan game pertama dari peserta tersebut. Artinya, pada percobaan pertama kita harus menghadapi banyak variabel yang belum dikenal, tetapi jika memulai lagi setelah sekali mengalaminya dan membawa insight serta know-how yang sudah didapat, maka bahkan tanpa LLM pun game itu bisa dibuat jauh lebih cepat daripada 3 bulan
Saya sendiri pernah mengalami bahwa ketika proyek yang sama diulang dua atau tiga kali, sesuatu yang awalnya memakan waktu beberapa bulan bisa turun menjadi sekitar sepertiganya pada percobaan berikutnya
<i>ehem</i> Saya bahkan pernah mengembangkan game dalam waktu kurang dari 24 jam; ada contohnya di nordicgamejam.com. Saya hanya ingin bilang bahwa pada masa sebelum ada LLM, GenAI, bahkan Unity, pilihan terbaik saat itu adalah Microsoft XNA dan C#. Art-nya pun kebanyakan setara gambar tangan yang dibuat di Paint. Namun begitu, setiap tahun tetap lahir banyak game yang menyenangkan, dan beberapa bahkan dikenal publik seperti Baba is You dan Braid. Coding bukanlah bottleneck, dan secara pribadi saya yakin bottleneck yang sebenarnya adalah komunikasi antaranggota tim
Melihat alur komentar ini, rasanya banyak yang menulis tanpa pengalaman pengembangan game. Faktanya, proyek yang dipakai LLM di sini adalah tipe proyek yang sudah sangat banyak ada di training data. Misalnya, ini juga jenis proyek yang dibahas dalam mata kuliah pengantar pemrograman, dan di negara-negara Eropa Selatan memang ada sangat banyak permainan kartu yang mirip dengan yang dibahas blog ini. Waktu tahun pertama kuliah, saya sendiri pernah mengimplementasikan Moon Patrol dari nol dengan Python tanpa pengalaman apa pun, dan itu memakan waktu 2–3 bulan sambil begadang 3 malam seminggu. Membuat game kartu malah lebih mudah daripada itu. LLM jelas berguna dalam beberapa hal, tetapi contoh sederhana seperti ini tidak cocok untuk mengukur produktivitas atau kegunaan coding dengan LLM
Saya pernah mengerjakan hal seperti ini dengan LLM, sambil melihatnya selang-seling selama beberapa hari: stacky. Kalau dihitung, mungkin total kerja nyatanya sekitar dua hari. Awalnya saya menulis dari nol, lalu belakangan menanganinya seperti brownfield, dan saya tidak benar-benar berniat menyelesaikannya dengan serius. Namun saat saya terus menambahkan detail dan fitur, ide-idenya juga terus bertambah (super rotation, DAS, dan sebagainya). Sampai sekarang masih belum selesai, mungkin baru sekitar 10–20% dari keseluruhan game. Versi WebGL-nya juga berjalan. Tapi kalau saya terlalu serius membuat Tetris yang ultimate, saya merasa bisa kena tuntutan hukum, dan saya juga tidak punya biaya lisensinya, jadi saya berhenti. Pada akhirnya yang saya dapat adalah kepercayaan diri dan pengalaman. Baru-baru ini, setelah melihat tautan tentang fungsi parametrik di HN, saya juga mencoba membuat playground graphy dalam 1–2 jam. Lagi-lagi, detail itulah yang terus memakan waktu. Kalau Anda tahu dengan jelas apa yang Anda inginkan, pekerjaan seperti ini bersama LLM cukup menyenangkan
Saya sudah cukup lama mengembangkan game hobi di atas tingkat tertentu dan juga telah menyelesaikan beberapa game. Tapi melihat keseluruhan alur komentar ini, rasanya banyak yang tidak punya banyak pengalaman pengembangan game nyata. Saya tidak bisa setuju dengan klaim bahwa coding itu mudah dalam pengembangan game. Memikirkan ide segar atau variasi mekanik genre justru terasa lebih mudah, dan bagian kode untuk benar-benar mengimplementasikannya jauh lebih sulit. Misalnya, membayangkan multiplayer Vampire Survivor dengan tambahan kustomisasi battlemech itu mudah, tetapi mengimplementasikannya hanya dengan LLM hampir mustahil. Kasus kali ini sederhana karena aturannya adalah game kartu yang sudah sepenuhnya dikenal, jadi sesederhana game ular. Ini bukan serangan terhadap penulisnya, saya hanya ingin menekankan bahwa banyak orang menilai pengembangan tanpa pengalaman membuat game sungguhan
Saya tidak setuju bahwa coding adalah bagian sulit dalam pengembangan game. Tentu bisa sulit, tetapi yang benar-benar sulit adalah memunculkan ide yang baru dan menyenangkan. Jika ada ide bagus, pada akhirnya Anda bisa memecahnya menjadi potongan kecil dan mengimplementasikannya lewat iterasi. Hambatan sejatinya adalah saat harus memutuskan apa yang akan dibuat dari keadaan kosong. Jalan-jalan, mencoba segala macam hal, itu adalah masalah yang sudah berulang ribuan tahun dalam seni. Sebaliknya, coding pada akhirnya adalah pekerjaan rekayasa. Saya juga belakangan belajar pengembangan game sambil belajar matematika, dan mempelajari matematika vektor atau quaternion justru terasa jauh lebih mudah daripada memutuskan "game apa yang ingin saya buat?"
Pada dasarnya saya setuju, tetapi bagi saya justru jauh lebih sulit memikirkan ide baru atau mencoba hal kreatif. Saya bisa mengoding hampir mekanik game apa pun, tetapi bagian menulis/kreativitas benar-benar berat. Kalau ada orang yang merasa bagian itu mudah, dia benar-benar beruntung. Itu bukan sesuatu yang alami bagi semua orang
Jika yang ingin dibuat adalah game sepenuhnya client-side, saya penasaran mengapa ditulis seolah-olah perlu "backend", dan mengapa hanya backend yang dipisahkan dengan penggunaan teknologi berbeda, bukan seluruh app
Saya merasa di industri software, area tempat ide bisa diwujudkan dengan mudah dan cepat hampir sudah hilang. Kompetisinya sudah terlalu sengit; bahkan saat menyasar pasar kecil pun kita bersaing langsung dengan VC global dan AI global. Dulu setidaknya masih bisa menemukan niche yang tidak diminati perusahaan besar. Sekarang, entah itu pasar VC besar maupun niche, semuanya tetap harus bersaing dengan seluruh dunia. Pada akhirnya yang tersisa hanya pasar kecil yang memerlukan teknologi sangat kompleks, atau area dengan profit rendah, kemungkinan gagal tinggi, dan lifecycle pendek (kebanyakan game ada di kategori ini). Untuk yang pertama, pemasaran yang dibutuhkan sampai harus mendatangi satu per satu dan menjelaskan produknya. Dari pengalaman saya di industri game, bahkan sebelum masuk tahap pengembangan pun, contoh sukses besar itu artinya hanya "mendapat sejuta view lalu mati total 6 bulan kemudian". Karena hampir tidak ada pendapatan berulang, memulai saja sudah sangat melemahkan motivasi. Membuat game seperti Minecraft hampir seperti menang lotre. Tapi industri game setidaknya masih lebih meritokratis dibanding sektor software lain. Kualitas dan kesenangan memang ada hubungannya dengan apakah sesuatu akan diadopsi. Industri lain terasa seperti labirin yang dipenuhi regulasi, monopoli karena efek jaringan, atau kontrol pemerintah. Saya bahkan berharap sejak awal pemerintah bisa bilang, "bidang ini sudah dikuasai perusahaan itu, jadi jangan bikin startup di sini, cari yang lain saja," supaya orang tidak membuang satu tahun percuma
Saya penasaran kapan orang akan sadar bahwa proyek greenfield (benar-benar baru) adalah skenario terburuk untuk benchmarking kemampuan agent coding
Saya suka LLM karena membantu saya memperlakukan kode dengan cara yang lebih dekat dengan bagaimana saya mengabstraksikan program di kepala. Saat membaca kode, saya memahaminya hampir seperti AST, mengubah fungsi dan pemanggilan menjadi node abstrak input dan hasil. Berkat LLM, pekerjaan membalik proses itu menjadi kode jadi sangat mudah. Saya tidak perlu lagi memburu contoh kode yang cocok dengan ide saya atau mengorek ingatan; cukup minta LLM menulis boilerplate seperti inisialisasi WiFi. Hasilnya, saya bisa merakit program seperti menyusun balok Lego. Sebelum ada LLM pun pendekatan ini mungkin dilakukan, tetapi butuh usaha jauh lebih besar. Karena itu sekarang saya bisa mengembangkan sesuatu dengan mudah sambil berpindah-pindah antarbahasa. Saya memang tidak belajar banyak tentang struktur internal bahasa atau sintaksnya, tetapi justru itu intinya. Bahasa dan sintaks hanyalah detail sekunder yang tidak berhubungan dengan alur logika program. Pada akhirnya, seperti evolusi dari bahasa mesin ke assembly, lalu ke C dan bahasa yang makin tingkat tinggi, kita akan semakin mendekati bukan sekadar coding, melainkan 'programming' itu sendiri. Tidak ada yang tahu bentuk akhirnya seperti apa, tetapi jelas bahwa seiring waktu kita akan makin banyak menghabiskan waktu untuk 'programming' daripada untuk 'menulis'