6 Bulan, 3 Proyek Game, 0 yang Rilis

Saya sebenarnya ingin menulis post ini beberapa minggu lalu. Tapi sepertinya saya masih berharap, ketika akhirnya duduk untuk menulis, setidaknya satu dari tiga game yang sedang saya bangun sudah selesai.

Ternyata tidak ada.

Jadi ya, begini posisinya: 684 commit di tiga proyek dalam enam bulan, dan belum ada satu pun yang bisa kamu download, mainkan, atau kirim ke teman. Kalau kamu pernah belajar sesuatu yang benar-benar baru di luar pekerjaan utama — sesuatu yang sulit, dan bukan hal yang sudah kamu kuasai — mungkin kamu tahu persis rasanya.

Saya tetap menulis ini karena menurut saya cerita kenapa tidak ada yang rilis justru lebih berguna daripada pengumuman rapi tentang sesuatu yang sudah selesai.

Konteks Awalnya

Selama 18 tahun saya bekerja di advertising. Itu pekerjaan yang bagus, menantang, dan saya tahu cara melakukannya. Saya pernah mengirim campaign, membangun tim, menulis buku, dan berbicara di panggung. Di dunia itu, saya tahu seperti apa bentuk "selesai".

Lalu pada akhir 2025, saya memutuskan ingin belajar game development. Bukan game marketing. Bukan game strategy. Betul-betul membuat game — code, art, systems, dan rasa ketika karakter bergerak di layar.

Saya tidak punya pengalaman dengan game engine. Saya belum pernah rig model 3D. Saya tidak tahu apa arti state machine dalam konteks animasi. Saya sudah coding beberapa tahun, terutama web app dan produk AI, tapi game adalah disiplin yang sangat berbeda. (Tolong koreksi kalau saya salah di bagian mana pun — saya masih belajar.)

Hal pertama yang saya pelajari: merilis game itu sulit. Hal kedua: kamu tidak bisa menalar jalan menuju game loop yang bagus hanya dari dokumen.

Kamu harus melihatnya bergerak. Kamu harus memainkannya, atau setidaknya menjalankannya di runtime Godot dan melihat apakah karakter, kamera, kontrol, dan feedback benar-benar menciptakan rasa. Lalu kamu harus bersedia membangun, menghapus, memotong, dan membangun lagi sampai sesuatu yang menarik muncul.

Begini ceritanya.

---

Proyek 1: AI Pet Sanctuary (288 commit)

Desember 2025 – Februari 2026

Proyek pertama dimulai dari ide sederhana: bagaimana kalau kamu punya hewan peliharaan yang tinggal di komputer dan bisa berbicara denganmu menggunakan AI? Bukan chatbot dengan avatar hewan — tetapi pet sungguhan dengan perilaku, habitat, dan kepribadian.

Saya membangun aplikasi full-stack. React di frontend, FastAPI di backend, Supabase untuk database. Saya menggunakan Gemini untuk percakapan dan Cloudflare Stream untuk video.

Bagian yang ambisius adalah sistem animasinya. Saya ingin 18 tipe pet di enam kategori besar — anjing, kucing, burung, hewan kecil, ikan, reptil. Masing-masing harus bisa bergerak, berkedip, dan terasa hidup.

Saya mulai dengan animasi Rive. Itu tidak cocok untuk kasus ini. Jadi saya menggantinya dengan animasi CSS dan JavaScript. Lalu saya membangun pipeline memakai Google Veo 3.1 untuk menghasilkan konten animasi — AI video generation untuk gerakan pet. Itu bekerja, tetapi rapuh. API kadang gagal, pencahayaan tidak konsisten, skala berubah antar-generasi. Saya menghabiskan lebih banyak waktu melawan pipeline generation daripada mendesain pengalaman pet itu sendiri.

Saya juga membangun sistem habitat dengan lingkungan full-screen yang imersif — sebuah ruangan bernama "The Study" tempat pet tinggal. Care screens. Memory screens. Integrasi percakapan. Bahkan redesign lengkap "Quiet Luxury" di tengah jalan karena versi pertama terasa seperti prototype. (Memang prototype.)

Lalu saya pivot.

288 commit kemudian, saya memutuskan web app adalah platform yang salah dan mulai merencanakan versi native iOS. Sampai sekarang saya belum tahu apakah itu keputusan yang benar atau sekadar rasa bosan yang menyamar sebagai strategi. Sebagian dari saya percaya pet di ponsel terasa lebih personal daripada pet di browser. Sebagian lain berpikir saya hanya lelah dengan React.

Tapi kalau saya jujur, alasan sebenarnya kenapa game itu tidak pernah rilis lebih sederhana: game-nya membosankan. Saya membangun semua itu — habitat, sistem animasi, integrasi percakapan — dan ketika saatnya duduk serta berinteraksi dengan pet, saya kehilangan minat dalam dua menit. Tidak ada sesuatu yang cukup menarik untuk menahan perhatian saya. Saya bermain game sejak secondary school, jadi saya percaya reaksi pertama itu, meski saya belum selalu tahu cara memperbaikinya. Saya masih bermain Mobile Legends dengan keluarga dan biasanya naik sampai Mystic. Itu bukan game yang kamu mainkan untuk kenyamanan pasif — game itu menuntut skill dan perhatian. Pet sanctuary ini tidak menuntut keduanya.

Saya terus berkata pada diri sendiri bahwa masalahnya adalah platform. Web app tidak bisa memberi pengalaman imersif yang saya inginkan. Mungkin iOS berbeda. Tapi jauh di dalam, saya tahu masalahnya bukan React — masalahnya adalah desain. Tidak ada platform switch yang bisa membuat game loop yang tidak menarik tiba-tiba terasa seru.

Apa yang salah

Melihat kembali repo-nya, menurut saya pelajaran yang tepat bukan "288 commit tanpa release itu buruk." Kalau core loop tidak engaging, merilis lebih awal hanya berarti merilis sesuatu yang membosankan lebih awal.

Masalah sebenarnya adalah saya terus mengganti wadah sebelum membuktikan loop-nya. Proyek itu bergerak dari mekanik merge/order, ke pure companion, ke habitat imersif, lalu ke iOS. Setiap pivot punya alasan. Tapi pertanyaan yang tidak saya jawab dengan cukup jelas lebih sederhana: apakah saya ingin membuka ini setiap hari?

Saya bisa memvalidasi itu dengan satu pet, satu ruangan, satu percakapan, dan satu interaksi care/play. Sebaliknya, saya membangun 18 tipe pet di 6 kategori hewan dengan sistem habitat penuh sebelum punya jawaban runtime untuk pertanyaan paling penting: apakah pet ini menarik untuk didatangi lagi?

Animasi yang dihasilkan AI itu kuat tetapi rapuh. Ketika berhasil, hasilnya luar biasa. Ketika tidak, kamu debugging prompt dan kegagalan API, bukan produk. Kamu butuh pipeline fallback, dan saya tidak membangunnya cukup awal.

Yang saya pelajari

Tugas pertama bukan memotong scope. Tugas pertama adalah menemukan bagian yang menarik. Kadang itu berarti membangun lebih banyak. Kadang berarti menghapus yang baru saja dibangun. Kesalahannya bukan eksplorasi. Kesalahannya adalah eksplorasi terlalu lama tanpa playable proof yang memberi tahu apakah pengalaman intinya punya nyawa.

---

Proyek 2: The Fox That Became a Stepping Stone (35 commit)

17 April – 12 Mei 2026

Setelah pet sanctuary pivot ke iOS, saya memulai proyek baru di Godot 4.6. Kali ini saya ingin membangun game dari nol di game engine sungguhan, bukan web app yang berpura-pura menjadi game.

Konsep awalnya: Spirit Fox Kit Sanctuary Sim. Seekor rubah kecil tinggal di ruangan hangat, dan kamu merawatnya. Sederhana, hangat, terkontrol.

Saya menyiapkan proyek Godot. Saya mencoba mendesain karakter rubah dengan hidden tense silhouettes, animasi twitch yang lebih cepat, dan micro-signals untuk stillness.

Tapi kalimat itu membuat prototype terdengar jauh lebih terbaca daripada kenyataannya. Di layar, rubahnya tidak terbaca sebagai rubah. Ia terlihat seperti gumpalan kecil. Saya tidak bisa melihat bentuk yang bisa dipakai, apalagi menilai visual ruangan di sekitarnya.

Saya membangun draft room loop dengan coverage GUT test. Placeholder audio. Hover cues untuk interactables. Layout scene ruangan. Cold-start playtest harness supaya saya benar-benar bisa memainkannya.

Lalu saya memainkannya.

Kebenaran jujurnya lebih visual dan kurang filosofis: rubahnya gagal pada pembacaan pertama. Prototype ruangan punya path yang terverifikasi secara mekanis, dan repo bahkan mencatat abbreviated solo gate pass untuk build placeholder-art. Stillness, emergence beat, touch distinction, dan room problem cukup acceptable untuk tahap itu.

Tapi acceptable untuk authored beat kecil tidak sama dengan cukup kuat secara visual untuk membawa game penuh. Proyek ini bergantung pada rubah sebagai pusat pengalaman. Kalau saya tidak bisa melihat bentuk, postur, dan daya tariknya, sanctuary loop itu belum punya peluang.

Jadi pada 20 April — hanya tiga hari setelah mulai — saya menulis pivot spec penuh. Fox sanctuary sim berubah menjadi sesuatu yang benar-benar berbeda: landscape action-adventure dengan safehouse hangat dan wilayah berbahaya untuk dieksplorasi. Saya menghentikan sementara rencana fox-first dan mulai mendesain arah baru.

35 commit. Satu beat tervalidasi. Satu pivot. Tidak ada yang rilis.

Apa yang salah

Masalah sebenarnya adalah saya memperlakukan sinyal animasi seolah-olah bisa menutupi bentuk dasar yang tidak terbaca. Tidak bisa. Twitch tidak penting kalau tubuh di bawahnya tidak punya silhouette.

Pivot itu bukan bukti bahwa pekerjaan pertama sia-sia. Ia membuat pekerjaan pertama menjadi fondasi. Yang masih belum saya miliki adalah bukti bahwa arah Hearthkeeper yang lebih besar akan bekerja, atau bahwa saya bisa membuat karakter intinya cukup terbaca untuk dipedulikan.

Yang saya pelajari

Playtesting awal menunjukkan apa yang sebenarnya dibuktikan oleh sebuah prototype. Prototype ruangan membuktikan tone, pacing, dan relationship beat. Ia tidak membuktikan game penuh, dan justru langsung mengekspos masalah visual readability. Itu informasi yang berguna, tetapi menunjuk ke langkah berikutnya yang berbeda: selesaikan dulu pembacaan karakter dan bangun loop terkecil safehouse -> run -> return sebelum memoles rubah lagi.

Game 1 mengajari saya bahwa loop yang lengkap secara teknis tetap bisa membosankan. Game 2 mengajari saya bahwa konsep karakter yang terdokumentasi dan teruji tetap bisa gagal secara visual dalam hitungan detik. Dua kegagalan itu adalah bagian dari alasan Game 3 membuat progress yang lebih nyata: saya jauh lebih memperhatikan readability, motion, weapon feel, dan apakah playable slice bekerja di layar.

Pivot dari bukti berbeda dengan drifting. Rubah tidak terbaca di runtime, jadi mengubah arah tidak otomatis berarti kegagalan disiplin. Bagian yang perlu saya tingkatkan adalah feedback loop: bawa pertanyaan visual atau gameplay paling berisiko ke layar lebih cepat, lalu putuskan berdasarkan bukti, bukan tetap tinggal di concept mode.

---

Proyek 3: Ketika Pipeline Mulai Bekerja (361 commit)

21 April – 13 Mei 2026

Ini proyek yang masih saya kerjakan. Ini juga proyek di mana pembelajaran dari dua proyek pertama akhirnya mulai saling menguatkan.

Ini game mech tactics. Kamu mengontrol skuad mech dalam combat, dan setelah setiap battle, sebuah LLM menganalisis apa yang terjadi dan memberi debrief. Bayangkan post-match analysis, tetapi ditulis oleh AI yang punya akses ke seluruh game state.

Repo ini punya tiga track, tetapi sekarang mereka tidak lagi setara:

Track A — LLM Debrief System: Ini track validasi AI awal. Ia membantu saya menguji structured debriefs, tetapi bukan lagi jalur produk utama.

Track B — 2D Phone Prototype: Di sinilah saya akhirnya menemukan pipeline yang workable untuk pengalaman pemain 2D yang relatif imersif. Runtime Godot-nya punya lane-match combat loop, touch joystick, shop/modules, hero XP, ability cooldowns, motif VFX yang terbaca di ponsel, enemy punish zones, neutral relay objective, HUD feedback, dan flow iOS export/testing. Art pipeline juga mulai bekerja: Nano Banana 2 (Gemini 3.1 Flash Image) menghasilkan initial hero dan character images yang bisa dipakai, lalu workflow pixel cleanup berbasis MCP dan Aseprite mengubah kandidat yang dikurasi menjadi sprites bersih, animation frames, dan sheets siap-Godot. Ini belum game selesai, dan phone acceptance masih pending, tetapi sudah jauh lebih dekat ke "ini terasa seperti game" dibanding dua proyek pertama.

Track C — Campaign and 3D Path: Ini arah produk saat ini. Ia mempertahankan pelajaran berguna dari Track B, menambah campaign memory loop, dan menggeser production combat ke arah 3D/2.5D. Masalahnya jauh lebih sulit daripada pipeline 2D. Di 2D, saya bisa mengontrol readability dengan sprite sheets, tuning HUD, procedural VFX, dan phone captures. Di 3D, setiap keputusan menyentuh modeling, rigging, animasi, kamera, lighting, GLB export, weapon sockets, hit anchors, action timing, dan runtime performance.

Saya juga mengintegrasikan Blender untuk custom rigging work, membawa data mocap dari Rokoko untuk locomotion, dan membangun karakter hero mech dengan full rig, animation tree, dan weapon socket integration.

361 commit dalam tiga minggu. Pipeline 2D yang nyata. Eksperimen 3D yang jauh lebih sulit. Masih prototype.

Apa yang salah

Ini bagian yang harus saya akui: pipeline 2D mulai bekerja, tetapi pipeline 3D bisa menelan seluruh proyek kalau saya biarkan.

Untuk Track B, pekerjaan pipeline bukan progress palsu. Workflow Nano Banana 2 -> Aseprite, touch controls, HUD, ability motifs yang terbaca, module feedback, phone captures, dan export loop membuat produk semakin playable. Itu mengajari saya apa yang perlu dilihat dan dirasakan pemain dari momen ke momen.

Risikonya sekarang berbeda. Di Track C, 3D membutuhkan banyak pipeline sebelum terasa seperti apa pun: model import, rig quality, animation names, weapon attachment, muzzle position, hit center, camera angle, lighting, movement, jump timing, attack timing, VFX, dan runtime inspection. Itu bukan detail opsional. Kalau karakter tidak terbaca, seluruh scene gagal dalam hitungan detik.

Tapi playable encounter tetap harus memimpin. Kalau tidak, saya bisa menghabiskan berminggu-minggu memperbaiki weapon fit hero mech, jump compression, left-hand IK, dan mocap cleanup tanpa menjawab pertanyaan sederhana dari pemain: apakah ini fun untuk dikontrol?

Yang saya pelajari

Pekerjaan pipeline berguna hanya ketika terus melayani playable slice. Track B mengajari saya bahwa pipeline yang tepat bisa menciptakan pengalaman 2D yang lebih imersif. Track C mengajari saya bahwa 3D menaikkan biaya setiap perbaikan. Saya harus menjaga acceptance gate tetap konkret: bisakah pemain membaca hero mech, menggerakkannya, membidik, menembak, memahami hit, dan ingin melakukannya lagi?

Track butuh gate. Track A sudah melakukan tugasnya. Track B menghasilkan pelajaran reusable tentang 2D game feel dan presentation. Track C adalah bet saat ini. Masalahnya bukan saya mengeksplorasi beberapa path. Masalahnya adalah membuka kembali path-path itu tanpa runtime question yang jelas dan decision rule yang jelas.

3D game development adalah skill gap besar. Rigging, animasi, mocap data, asset budgets, weapon sockets, camera framing, dan readable motion adalah disiplin yang tidak pernah saya jalani secara profesional. Saya mempelajarinya sambil juga belajar Godot, game design, dan campaign architecture. Learning curve-nya bukan curam — rasanya vertikal. Menurut saya inilah bagian yang paling mengejutkan. Di web development, saya bisa membangun sesuatu yang fungsional dalam sehari. Di 3D game dev, saya bisa menghabiskan satu malam hanya untuk membuat lengan karakter menekuk dengan benar. (Kalimat seperti ini tidak akan saya pahami enam bulan lalu.)

---

Apa Kesamaan Tiga Proyek Ini

Kalau saya jujur pada diri sendiri — dan post ini hanya bekerja kalau saya jujur — polanya bukan "scope creep." Itu terlalu mudah, dan dalam kasus ini saya pikir salah.

Saya tidak berpikir game bekerja seperti business deck — setidaknya itu yang diajarkan tiga proyek ini. Kamu tidak tahu sebuah ide bekerja hanya karena premisnya terdengar bagus. Kamu tahu ketika bisa memainkannya, atau setidaknya melihatnya berjalan di engine dan merasakan apakah karakter, kamera, interaksi, dan feedback melakukan sesuatu.

1. Runtime adalah kebenaran

Pet sanctuary terdengar bagus sampai saya berinteraksi dengan pet dan bosan. Fox terdengar bagus sampai saya melihatnya di Godot dan tidak bisa membaca bentuknya. Track B mulai bekerja karena loop-nya masuk ke runtime yang mirip ponsel: touch controls, HUD, VFX, shop, XP, motif yang terbaca, dan capture feedback.

Itulah pola sebenarnya. Kebenaran yang berguna baru muncul ketika ide menjadi terlihat dan playable.

2. Eksplorasi perlu, tetapi butuh bukti

Saya tidak berpikir pelajaran yang benar adalah "berhenti menambah hal." Game development membutuhkan eksplorasi. Kamu membangun, mencoba, menghapus, memotong, membangun ulang, dan mencoba lagi karena sedang mencari bagian yang menarik.

Bagian yang membutuhkan disiplin bukan jumlah kerja. Disiplinnya ada di evidence loop. Setiap bagian pekerjaan seharusnya menjawab pertanyaan: apakah ini membuat game lebih terbaca, lebih engaging, lebih controllable, lebih layak dimainkan ulang?

3. Pipeline bagus ketika membuat game lebih playable

Workflow Nano Banana 2 -> MCP cleanup -> Aseprite bukan distraksi. Itu membantu saya memasukkan karakter 2D dan animasi yang lebih baik ke dalam game. Pekerjaan HUD dan VFX di Track B juga bukan progress palsu. Itu membuat runtime lebih jelas.

Risikonya muncul ketika pipeline berhenti menjawab pertanyaan yang menghadap pemain. Di Track C, tooling 3D memang perlu, tetapi harus terus kembali ke satu hal: bisakah pemain membaca hero mech, menggerakkannya, menembakkan senjata, memahami hit, dan ingin melakukannya lagi?

4. Gap-nya bukan coding skill. Gap-nya playable judgment.

Saya bisa membangun aplikasi full-stack dengan Supabase, FastAPI, dan React. Saya bisa rig model 3D, menulis GUT tests, dan membangun custom debugging tools. Yang masih saya pelajari adalah menilai apakah sesuatu benar-benar menarik sebagai game. Track B membawa saya lebih dekat di 2D. Track C menunjukkan betapa jauh lebih sulitnya ketika motion, camera, lighting, weapons, dan animation semuanya harus bekerja bersama.

Menurut saya ini pelajaran paling penting. Code adalah bagian yang saya kuasai. Bagian sulitnya adalah memutuskan game ini sebenarnya apa, membuatnya menarik, lalu punya disiplin untuk terus kembali ke bukti runtime sampai layak dirilis.

---

Yang Saya Pelajari Secara Keseluruhan

Kalau saya mencoba memeras enam bulan ini menjadi sesuatu yang berguna — untuk saya, atau untuk siapa pun yang sedang di posisi yang sama — ini hal yang saya pikir saya tahu sekarang, yang belum saya tahu pada Desember:

1. Versi pertama harus menjawab pertanyaan paling berisiko di runtime. Pet sanctuary saya membutuhkan satu interaksi pet yang membuat saya ingin kembali. Game fox saya membutuhkan silhouette yang terbaca di ruangan kosong sebelum saya memikirkan micro-signals. Game mech saya akhirnya lebih dekat lewat Track B karena saya bisa melihat dan merasakan loop-nya di layar.

2. Playtesting bukan opsional, dan runtime review juga dihitung. Saat saya melihat fox sebagai gumpalan tanpa bentuk, saya tahu proyek itu belum bekerja. Itu 30 menit paling berharga dari seluruh proyek. Saya seharusnya mencapai kebenaran visual itu lebih awal.

3. Belajar adalah outcome yang valid, meski bukan outcome yang kamu rencanakan. Saya mulai dengan tujuan membangun game. Saya tidak merilis game. Tapi saya belajar tentang Godot, LLM prompt engineering, Nano Banana 2 untuk character ideation, Aseprite animation cleanup, 2D phone readability, HUD dan VFX feedback, animation pipelines, 3D rigging, mocap data, game feel, camera systems, visual readability, dan perbedaan antara membangun tools dan membangun products. Itu bukan tidak ada artinya. Itu juga kenapa Game 3 lebih baik daripada Game 1 dan Game 2, walaupun masih belum rilis.

4. Saya masih perlu mendefinisikan finish line yang jujur. Sebagian dari saya ingin mendorong proyek ini sampai selesai supaya bisa berkata saya sudah merilis game. Sebagian lain berpikir pembelajarannya adalah produk dan saya harus menerima itu. Keduanya jawaban yang jujur. Menurut saya kebenarannya ada di tengah: rilis focused slice yang menghormati apa yang sudah saya pelajari, bukan mulai lagi dari nol.

Berikutnya Apa

Saya masih mengerjakan proyek mech tactics ini. Konsep LLM debrief menarik, dan menurut saya ada sesuatu yang benar-benar baru dalam ide AI-powered post-match analysis untuk tactics game.

Tapi saya mencoba mengubah pendekatan: runtime proof dulu, polish belakangan, rilis hanya setelah playable slice punya alasan untuk ada. Dua proyek pertama tidak sia-sia. Mereka mengubah apa yang saya lihat di Game 3: apakah karakter terbaca, apakah motion terasa bagus, apakah weapon feel tepat, dan apakah seseorang bisa memahami encounter tanpa saya menjelaskan arsitekturnya?

Kalau saya memulai game baru hari ini, saya tidak akan mulai dari architecture plan besar. Saya akan mulai dari runtime proof tercepat yang bisa menjawab pertanyaan yang benar-benar saya pedulikan. Untuk Game 3 sekarang, disiplin yang sama harus terjadi di dalam proyek: satu karakter, satu senjata, satu encounter, satu acceptance test yang jelas.

Saya belum tahu apakah saya akan mendorong salah satu proyek ini sampai selesai atau menerima bahwa pembelajarannya adalah produk. Mungkin saya salah soal timeline, tetapi saya pikir polanya lebih penting daripada satu proyek mana pun.

Pertanyaan untuk Kamu

Saya ingin bertanya dengan sungguh-sungguh, bukan retoris: apakah kamu pernah berada di sini? (Saya curiga lebih banyak builder pernah mengalami ini daripada yang biasanya kita akui.)

Apakah kamu pernah menghabiskan berbulan-bulan membangun sesuatu yang tidak pernah rilis? Apakah akhirnya kamu menyelesaikannya, atau kamu pergi? Dan kalau kamu pergi — apakah itu keputusan yang benar, atau masih kamu pikirkan?

Saya pernah merilis banyak hal dalam karier saya. Campaign, platform, produk. Tapi semua itu berada di domain tempat saya punya 18 tahun pengalaman. Game development masih baru, dan jarak antara "saya bisa membangun ini secara teknis" dan "ini game yang bagus" jauh lebih lebar daripada yang saya kira.

Kalau kamu pernah menyeberangi gap itu, saya ingin tahu apa yang membuatmu tidak pivot lagi. Silakan balas di LinkedIn atau hubungi saya langsung — saya benar-benar penasaran.

---

Sekian dulu dari saya. Saya ingin mendengar pendapatmu — terutama kalau kamu pernah melewati hal yang sama. Silakan hubungi saya di LinkedIn atau kirim pesan langsung.

Salam hangat,

Chandler