6 Buwan, 3 Game Projects, 0 na Na-ship

Balak ko sanang isulat ang post na ito ilang linggo na ang nakalipas. Pero sa tingin ko umaasa pa ako na pag-upo ko para magsulat, kahit isa sa tatlong game na ginagawa ko ay tapos na.

Wala.

So eto tayo: 684 commits sa tatlong proyekto sa loob ng anim na buwan, at wala pa ring puwedeng i-download, laruin, o ipadala sa kaibigan. Kung minsan ka nang natutong gumawa ng bagong bagay habang may full-time job — bagay na talagang mahirap, at hindi mo pa expertise — malamang alam mo ang pakiramdam.

Isinusulat ko pa rin ito dahil sa tingin ko mas kapaki-pakinabang ang kuwento kung bakit walang na-ship kaysa sa polished announcement ng isang bagay na tapos na.

Ang Simula

Sa loob ng 18 taon, nagtrabaho ako sa advertising. Magandang trabaho ito, challenging, at alam ko kung paano ito gawin. Nakapag-ship ako ng campaigns, nakapagbuo ng teams, nakapagsulat ng books, at nakapagsalita sa stage. Sa mundong iyon, alam ko ang itsura ng "done."

Noong late 2025, nagdesisyon akong matuto ng game development. Hindi game marketing. Hindi game strategy. Talagang paggawa ng games — code, art, systems, at ang pakiramdam ng karakter na gumagalaw sa screen.

Wala akong experience sa game engines. Hindi pa ako nag-rig ng 3D model. Hindi ko alam noon kung ano ang state machine sa context ng animation. Ilang taon na akong nagko-code, mostly web apps at AI products, pero ibang disiplina ang games. (Please correct me kung mali ako sa alinman dito — natututo pa ako.)

Unang natutunan ko: mahirap mag-ship ng game. Pangalawa: hindi mo kayang i-rason ang sarili mo papunta sa magandang game loop mula lang sa document.

Kailangan mong makita itong gumagalaw. Kailangan mong laruin, o kahit mapatakbo man lang sa Godot runtime at panoorin kung ang character, camera, controls, at feedback ay talagang may nararamdaman. Tapos kailangan mong maging handang gumawa, mag-delete, mag-cut, at gumawa ulit hanggang may lumabas na interesting.

Ito ang nangyari.

---

Project 1: The AI Pet Sanctuary (288 commits)

Disyembre 2025 – Pebrero 2026

Nagsimula ang unang proyekto sa simpleng idea: paano kung may pet kang nakatira sa computer mo at nakakausap ka gamit ang AI? Hindi chatbot na may pet avatar — kundi actual pet na may behaviors, habitat, at personality.

Gumawa ako ng full-stack web application. React sa frontend, FastAPI sa backend, Supabase para sa database. Ginamit ko ang Gemini para sa conversations at Cloudflare Stream para sa video.

Ang ambitious na bahagi ay ang animation system. Gusto ko ng 18 pet types sa anim na broad categories — dogs, cats, birds, small animals, fish, reptiles. Bawat isa kailangang gumalaw, kumurap, at maramdaman na buhay.

Nagsimula ako sa Rive animations. Hindi sila gumana para sa use case na ito. Kaya pinalitan ko ng CSS at JavaScript pet animations. Pagkatapos gumawa ako ng pipeline gamit ang Google Veo 3.1 para mag-generate ng animation content — AI video generation para sa pet movements. Gumagana siya, pero brittle. Minsan nagfa-fail ang API, hindi consistent ang lighting, nagbabago ang scale sa bawat generation. Mas marami akong oras na ginugol sa paglaban sa generation pipeline kaysa sa pag-design ng actual pet experience.

Gumawa rin ako ng habitat system na may full-screen immersive environments — isang room na tinawag na "The Study" kung saan nakatira ang pet. Care screens. Memory screens. Conversation integration. Isang buong "Quiet Luxury" redesign sa gitna dahil mukhang prototype ang unang version. (Dahil prototype nga.)

Tapos nag-pivot ako.

288 commits in, napagdesisyunan kong mali ang web app bilang platform at nagsimulang magplano ng native iOS version. Hanggang ngayon hindi ko alam kung tama iyon o boredom lang na nagbihis bilang strategy. Isang bahagi ko naniniwalang mas intimate ang pet sa phone kaysa pet sa browser. Isang bahagi ko naman iniisip na nagsawa lang ako sa React.

Pero kung honest ako, mas simple ang totoong dahilan kung bakit hindi ko ito na-ship: boring siya. Ginawa ko ang lahat ng ito — habitats, animation system, conversation integration — at nang oras na para umupo at makipag-interact sa pet, nawalan ako ng interest sa loob ng dalawang minuto. Walang sapat na compelling para hawakan ang attention ko. Naglalaro ako mula secondary school, kaya pinagkakatiwalaan ko ang unang reaction na iyon, kahit hindi ko pa laging alam kung paano ayusin. Naglalaro pa rin ako ng Mobile Legends kasama ang pamilya ko at kadalasan umaakyat hanggang Mystic. Hindi iyon game na nilalaro mo para sa passive comfort — kailangan nito ng skill at attention. Wala sa dalawa ang hinihingi ng pet sanctuary na ito.

Paulit-ulit kong sinasabi sa sarili ko na platform ang problema. Hindi kayang ibigay ng web app ang immersive experience na gusto ko. Baka iba kapag iOS. Pero sa loob-loob ko alam kong hindi React ang issue — design ang issue. Walang platform switch na gagawing exciting ang uninteresting game loop.

Ano ang mali

Pagtingin ko sa repo, hindi ko iniisip na ang tamang lesson ay "masama ang 288 commits na walang release." Kung hindi engaging ang core loop, ang earlier shipping ay mas maagang pag-ship lang ng boring na bagay.

Ang totoong problema: palit ako nang palit ng container bago ko napatunayan ang loop. Mula merge/order mechanics, naging pure companion, naging immersive habitats, naging iOS. May dahilan ang bawat pivot. Pero hindi ko malinaw na nasagot ang mas simpleng tanong: gugustuhin ko bang buksan ito araw-araw?

Puwede ko sanang i-validate iyon gamit ang isang pet, isang room, isang conversation, at isang care/play interaction. Sa halip, gumawa ako ng 18 pet types sa 6 animal categories at buong habitat system bago ako nagkaroon ng runtime answer sa pinakamahalagang tanong: interesting ba itong pet na balikan?

Malakas ang AI-generated animation, pero fragile. Kapag gumana, incredible. Kapag hindi, prompts at API failures ang dine-debug mo imbes na product. Kailangan ng fallback pipeline, at hindi ko iyon ginawa nang maaga.

Ang natutunan ko

Ang unang trabaho ay hindi mag-cut ng scope. Ang unang trabaho ay hanapin ang interesting part. Minsan ibig sabihin nito, mas marami kang gagawin. Minsan ibig sabihin nito, buburahin mo ang kakagawa mo lang. Hindi exploration ang mali. Ang mali ay sobrang tagal na exploration nang walang playable proof na nagsasabi kung may buhay ang core experience.

---

Project 2: The Fox That Became a Stepping Stone (35 commits)

Abril 17 – Mayo 12, 2026

Pagkatapos mag-pivot ng pet sanctuary sa iOS, nagsimula ako ng bagong proyekto sa Godot 4.6. Gusto kong gumawa ng game from scratch sa totoong game engine, hindi web app na nagpapanggap na game.

Ang initial concept: Spirit Fox Kit Sanctuary Sim. Maliit na fox na nakatira sa cozy room, at inaalagaan mo siya. Simple, warm, contained.

Nag-set up ako ng Godot project. Sinubukan kong i-design ang fox character na may hidden tense silhouettes, mas mabilis na twitch animations, at micro-signals para sa stillness.

Pero mas legible pakinggan ang sentence na iyon kaysa sa actual prototype. Sa screen, hindi nababasa bilang fox ang fox. Para siyang maliit na globe ng mass. Hindi ko makita ang usable shape, lalo na ang ibang visuals sa paligid.

Gumawa ako ng draft room loop na may GUT test coverage. Placeholder audio. Hover cues para sa interactables. Room scene layout. Cold-start playtest harness para talagang malaro ko siya.

Tapos nilaro ko.

Ang honest truth ay mas visual at mas kaunting philosophical: bagsak ang fox sa first read. May mechanically verified path ang room prototype, at naka-record pa sa repo ang abbreviated solo gate pass para sa placeholder-art build. Acceptable sa stage na iyon ang stillness, emergence beat, touch distinction, at room problem.

Pero hindi pareho ang acceptable para sa maliit na authored beat at visually strong enough para buhatin ang full game. Nakasalalay ang project sa fox na nagdadala ng experience. Kung hindi ko makita ang shape, posture, at appeal niya, wala pang chance ang sanctuary loop.

Kaya noong Abril 20 — tatlong araw lang matapos magsimula — sumulat ako ng full pivot spec. Ang fox sanctuary sim ay naging ibang-iba: landscape action-adventure na may warm safehouse at hostile territory na i-eexplore. Ipinause ko ang fox-first plans at nagsimulang mag-design ng bagong direction.

35 commits. Isang validated beat. Isang pivot. Walang na-ship.

Ano ang mali

Ang totoong problema ay tinrato ko ang animation signals na parang kaya nilang kompensahin ang unreadable base shape. Hindi kaya. Walang saysay ang twitch kung ang body sa ilalim nito ay walang silhouette.

Hindi proof ang pivot na nasayang ang unang trabaho. Ginawa nitong foundation ang unang trabaho. Ang wala pa rin ako ay evidence na gagana ang mas malaking Hearthkeeper direction, o na kaya kong gawing readable enough ang core character para may pakialam ang player.

Ang natutunan ko

Maagang playtesting ang nagpapakita kung ano talaga ang pinapatunayan ng prototype. Pinatunayan ng room prototype ang tone, pacing, at relationship beat. Hindi nito pinatunayan ang buong game, at agad nitong inilantad ang visual readability problem. Useful information iyon, pero ibang next step ang tinuturo: ayusin ang character read at buuin ang pinakamaliit na safehouse -> run -> return loop bago muling i-polish ang fox.

Tinuruan ako ng Game 1 na kahit technically complete ang loop, puwede pa rin itong maging boring. Tinuruan ako ng Game 2 na kahit documented at tested ang character concept, puwede pa rin itong bumagsak visually sa loob ng ilang segundo. Kaya mas may real progress ang Game 3: mas binabantayan ko na ang readability, motion, weapon feel, at kung gumagana ba ang playable slice sa screen.

Iba ang pivoting from evidence sa drifting. Hindi nabasa ang fox sa runtime, kaya ang change of direction ay hindi automatic na failure of discipline. Ang kailangan kong pagbutihin ay ang feedback loop: dalhin sa screen nang mas mabilis ang pinakamapanganib na visual o gameplay question, pagkatapos magdesisyon gamit ang evidence imbes na manatili sa concept mode.

---

Project 3: Noong Nagsimulang Gumana ang Pipeline (361 commits)

Abril 21 – Mayo 13, 2026

Ito ang project na ginagawa ko pa rin. Ito rin ang project kung saan nagsimulang mag-compound ang natutunan ko sa unang dalawa.

Isa itong mech tactics game. Kinokontrol mo ang squad ng mechs sa combat, at pagkatapos ng bawat battle, ina-analyze ng LLM ang nangyari at nagbibigay ng debrief. Parang post-match analysis, pero isinulat ng AI na may access sa buong game state.

May tatlong tracks ang repo, pero hindi na sila equal:

Track A — The LLM Debrief System: Ito ang early AI validation track. Nakatulong ito para i-test ang structured debriefs, pero hindi na ito ang main product path.

Track B — The 2D Phone Prototype: Dito ko unang nahanap ang workable pipeline para sa relatively immersive na 2D player experience. May actual Godot runtime na lane-match combat loop, touch joystick, shop/modules, hero XP, ability cooldowns, phone-readable VFX motifs, enemy punish zones, neutral relay objective, HUD feedback, at iOS export/testing flow. Nagsimula ring gumana ang art pipeline: Nano Banana 2 (Gemini 3.1 Flash Image) generated usable initial hero and character images, tapos ang MCP-based pixel cleanup workflow at Aseprite ang nag-convert ng curated candidates into cleaned sprites, animation frames, at Godot-ready sheets. Hindi pa ito finished game, at pending pa ang phone acceptance, pero mas malapit na siya sa "parang game na ito" kaysa sa unang dalawang projects.

Track C — The Campaign and 3D Path: Ito ang current product direction. Kinukuha nito ang useful Track B lessons, dinadagdagan ng campaign memory loop, at inililipat ang production combat papunta sa 3D/2.5D. Mas mahirap ito kaysa 2D pipeline. Sa 2D, kaya kong kontrolin ang readability gamit ang sprite sheets, HUD tuning, procedural VFX, at phone captures. Sa 3D, bawat decision ay dumadaplis sa modeling, rigging, animation, camera, lighting, GLB export, weapon sockets, hit anchors, action timing, at runtime performance.

Nag-integrate din ako ng Blender para sa custom rigging work, gumamit ng Rokoko mocap data para sa locomotion, at gumawa ng hero mech character na may full rig, animation tree, at weapon socket integration.

361 commits sa tatlong linggo. Totoong 2D pipeline. Mas mahirap na 3D experiment. Prototype territory pa rin.

Ano ang mali

Ito ang kailangan kong aminin: nagsisimula nang gumana ang 2D pipeline, pero kayang lunukin ng 3D pipeline ang buong project kung hahayaan ko.

Para sa Track B, hindi fake progress ang pipeline work. Ang Nano Banana 2 -> Aseprite workflow, touch controls, HUD, readable ability motifs, module feedback, phone captures, at export loop ay nagpapalapit sa product sa pagiging playable. Itinuro nito sa akin kung ano ang kailangang makita at maramdaman ng player moment to moment.

Iba na ang risk ngayon. Sa Track C, kailangan ng 3D ng maraming pipeline bago ito maramdaman bilang kahit ano: model import, rig quality, animation names, weapon attachment, muzzle position, hit center, camera angle, lighting, movement, jump timing, attack timing, VFX, at runtime inspection. Hindi optional details ang mga iyon. Kapag hindi readable ang character, bagsak ang buong scene sa loob ng ilang segundo.

Pero playable encounter pa rin ang dapat mauna. Kung hindi, puwede akong gumugol ng weeks sa pagpapaganda ng weapon fit, jump compression, left-hand IK, at mocap cleanup ng hero mech nang hindi sinasagot ang simpleng player question: masaya ba itong kontrolin?

Ang natutunan ko

Useful lang ang pipeline work kapag patuloy nitong sinisilbihan ang playable slice. Tinuruan ako ng Track B na ang tamang pipeline ay puwedeng lumikha ng mas immersive na 2D experience. Tinuturuan ako ng Track C na pinapataas ng 3D ang cost ng bawat improvement. Kailangan kong panatilihing concrete ang acceptance gate: nababasa ba ng player ang hero mech, nagagalaw ba niya ito, nakaka-aim, nakakaputok, naiintindihan ang hit, at gusto bang ulitin?

Kailangan ng gates ang tracks. Ginawa na ng Track A ang trabaho nito. Nag-produce ang Track B ng reusable 2D game feel at presentation lessons. Track C ang current bet. Hindi problema na nag-explore ako ng multiple paths. Problema ang pagbubukas ulit ng mga ito nang walang malinaw na runtime question at decision rule.

Malaking skill gap ang 3D game development. Rigging, animation, mocap data, asset budgets, weapon sockets, camera framing, at readable motion ay disciplines na wala akong professional experience. Natutunan ko sila habang natututo rin ng Godot, game design, at campaign architecture. Hindi steep ang learning curve — vertical siya. Sa tingin ko ito ang pinakanagulat ako. Sa web development, kaya kong gumawa ng functional na bagay sa isang araw. Sa 3D game dev, gumugol ako ng buong gabi para lang maayos ang bend ng braso ng character. (Ito ang uri ng sentence na hindi ko maiintindihan six months ago.)

---

Ano ang Pare-pareho sa Tatlong Projects

Kung honest ako sa sarili ko — at gagana lang ang post na ito kung honest ako — hindi "scope creep" ang pattern. Masyadong madali iyon, at sa kasong ito sa tingin ko mali.

Hindi ko iniisip na gumagana ang games tulad ng business decks — at least iyon ang tinuro ng tatlong projects na ito. Hindi mo alam kung gagana ang idea dahil maganda ang premise. Malalaman mo kapag nalalaro mo na, o kahit nakikita mo na ito sa engine at nararamdaman kung may ginagawa ba ang character, camera, interaction, at feedback.

1. Ang runtime ang truth

Maganda pakinggan ang pet sanctuary hanggang sa makipag-interact ako sa pet at naboring. Maganda pakinggan ang fox hanggang nakita ko ito sa Godot at hindi ko mabasa ang shape. Nagsimulang gumana ang Track B dahil nakapasok ang loop sa phone-like runtime: touch controls, HUD, VFX, shop, XP, readable motifs, at capture feedback.

Iyon ang totoong pattern. Dumating lang ang useful truth nang naging visible at playable ang idea.

2. Kailangan ang exploration, pero kailangan nito ng evidence

Hindi ko iniisip na ang tamang lesson ay "huwag nang magdagdag ng bagay." Kailangan ng game development ang exploration. Gumagawa ka, sumusubok, nagde-delete, nagcu-cut, gumagawa ulit, at sumusubok ulit dahil hinahanap mo ang interesting part.

Ang kailangang disiplinahin ay hindi ang dami ng trabaho. Ang kailangang disiplinahin ay evidence loop. Bawat piraso ng trabaho dapat sumagot ng tanong: ginagawa ba nitong mas readable, mas engaging, mas controllable, mas worth replaying ang game?

3. Maganda ang pipelines kapag pinapaganda nila ang playability

Hindi distraction ang Nano Banana 2 -> MCP cleanup -> Aseprite workflow. Nakatulong ito para makapasok ang mas magandang 2D characters at animation sa game. Hindi rin fake progress ang HUD at VFX work sa Track B. Ginawa nitong mas malinaw ang runtime.

Ang risk ay kapag tumigil ang pipeline sa pagsagot ng player-facing question. Sa Track C, kailangan ang 3D tooling, pero dapat laging bumalik sa isang bagay: nababasa ba ng player ang hero mech, nagagalaw, nakakabaril, naiintindihan ang hit, at gustong ulitin?

4. Hindi coding skill ang gap. Playable judgment.

Kaya kong gumawa ng full-stack application gamit ang Supabase, FastAPI, at React. Kaya kong mag-rig ng 3D model, magsulat ng GUT tests, at gumawa ng custom debugging tools. Ang pinag-aaralan ko pa ay kung paano husgahan kung interesting talaga ang isang bagay bilang game. Inilapit ako ng Track B sa 2D. Ipinapakita ng Track C kung gaano kahirap kapag motion, camera, lighting, weapons, at animation ay kailangang gumana together.

Sa tingin ko ito ang pinakamahalagang natutunan ko. Code ang part na magaling ako. Ang mahirap ay magdesisyon kung ano talaga ang game, gawin itong interesting, at magkaroon ng disiplina na bumalik nang bumalik sa runtime evidence hanggang worth shipping na siya.

---

Ang Natutunan Ko Overall

Kung susubukan kong gawing useful ang anim na buwang ito — para sa akin, o para sa sinumang nasa parehong position — ito ang alam ko ngayon na hindi ko alam noong December:

1. Dapat sagutin ng first version ang riskiest question sa runtime. Kailangan ng pet sanctuary ko ng isang pet interaction na magpapabalik sa akin. Kailangan ng fox game ko ng readable silhouette sa blank room bago ako mag-alala sa micro-signals. Mas lumapit ang mech game ko sa Track B dahil nakikita at nararamdaman ko ang loop sa screen.

2. Hindi optional ang playtesting, at counted ang runtime review. Nang makita ko ang fox bilang shapeless mass, alam kong hindi pa gumagana ang project. Iyon ang pinakamahalagang 30 minutes ng buong project. Dapat narating ko ang visual truth na iyon nang mas maaga.

3. Valid outcome ang learning, kahit hindi iyon ang pinlano mo. Gusto kong gumawa ng games. Wala akong na-ship na games. Pero natuto ako ng Godot, LLM prompt engineering, Nano Banana 2 for character ideation, Aseprite animation cleanup, 2D phone readability, HUD and VFX feedback, animation pipelines, 3D rigging, mocap data, game feel, camera systems, visual readability, at ang difference between building tools and building products. Hindi iyon wala. Kaya rin mas maganda ang Game 3 kaysa Game 1 at Game 2, kahit hindi pa rin siya shipped.

4. Kailangan ko pa ring mag-define ng honest finish line. May bahagi sa akin na gustong itulak ang project hanggang completion para masabi kong nag-ship ako ng game. May bahagi rin na iniisip na learning ang product at dapat tanggapin ko iyon. Parehong honest answers. Sa tingin ko nasa gitna ang truth: mag-ship ng focused slice na nirerespeto ang natutunan ko, imbes na mag-restart from zero ulit.

Ano ang Susunod

Ginagawa ko pa rin ang mech tactics project. Interesting ang LLM debrief concept, at sa tingin ko may genuinely novel sa idea ng AI-powered post-match analysis para sa tactics game.

Pero sinusubukan kong baguhin ang approach: runtime proof muna, polish later, ship lang kapag may dahilan nang umiral ang playable slice. Hindi nasayang ang unang dalawang projects. Binago nila ang tinitingnan ko sa Game 3: readable ba ang character, maganda ba ang motion feel, tama ba ang weapon feel, at kaya bang maintindihan ng isang tao ang encounter nang hindi ko ine-explain ang architecture?

Kung magsisimula ako ng bagong game ngayon, hindi ako magsisimula sa malaking architecture plan. Magsisimula ako sa pinakamabilis na runtime proof na sasagot sa tanong na talagang mahalaga sa akin. Para sa Game 3 ngayon, kailangan mangyari ang parehong disiplina sa loob ng project: isang character, isang weapon, isang encounter, isang clear acceptance test.

Hindi ko pa alam kung itutulak ko ang isa sa mga ito hanggang completion o tatanggapin kong learning ang product. Baka mali ako sa timeline, pero sa tingin ko mas mahalaga ang pattern kaysa sa anumang single project.

Tanong Para Sa Iyo

Gusto kong itanong ito nang totoo, hindi rhetorical: naranasan mo na ba ito? (Hula ko mas maraming builders ang dumaan dito kaysa sa inaamin natin.)

Naglaan ka na ba ng buwan-buwan sa paggawa ng bagay na hindi na-ship? Natapos mo ba sa huli, o lumayo ka? At kung lumayo ka — tama ba ang decision, o naiisip mo pa rin?

May na-ship na ako sa career ko. Campaigns, platforms, products. Pero nasa domain iyon kung saan may 18 years akong experience. Bago sa akin ang game development, at mas malapad ang gap sa pagitan ng "kaya ko itong buuin technically" at "magandang game ito" kaysa inaasahan ko.

Kung natawid mo na ang gap na iyon, gusto kong marinig kung ano ang pumigil sa iyo na mag-pivot away. Feel free to reply on LinkedIn o mag-message nang diretso — genuinely curious ako.

---

Iyon muna mula sa akin. Gusto kong marinig ang thoughts mo — lalo na kung pinagdaanan mo rin ito. Pwede kang mag-reach out sa LinkedIn o magpadala ng note directly.

Maraming salamat,

Chandler