Skip to content
··閱讀時間6分鐘

6 個月,3 個遊戲 project,0 個推出

我一邊做 full-time job,一邊花咗 6 個月試住成為 game developer。 我做咗三個 project,寫咗 684 個 commits,最後真正推出嘅 game 係 0 個。 呢篇係講發生咗咩、我學到咩,以及點解最後乜都未推出。

我本來想幾個星期前就寫呢篇 post。但我諗自己其實仲喺度希望,等我真正坐低寫嗰陣,三個 game project 入面至少有一個已經完成。

結果一個都未完成。

所以而家嘅情況係:六個月,三個 project,684 個 commits,但冇任何嘢可以俾你 download、玩,或者 send 俾朋友。如果你曾經喺 full-time job 之外學一樣全新、真正困難、而且自己本來唔擅長嘅嘢,你大概會明白呢種感覺。

我仍然想寫出嚟,因為我覺得「點解乜都冇推出」呢個故事,可能比一篇 polished launch announcement 更有用。

一開始嘅背景

我做咗 18 年 advertising。呢份工作好、有挑戰性,而且我知道點做。我推出過 campaigns,建立過 teams,寫過書,亦都上過 stage。喺嗰個世界,我知道「done」係咩樣。

然後喺 2025 年尾,我決定想學遊戲開發。唔係 game marketing。唔係 game strategy。而係真係做 game:code、art、systems,以及角色喺 screen 上面郁嗰種手感。

我冇 game engine 經驗。未 rig 過 3D model。唔知道 animation context 入面 state machine 代表咩。我已經 code 咗幾年,主要係 web apps 同 AI products,但遊戲係完全唔同嘅 discipline。(如果我呢度有講錯,請直接糾正我——我仲喺學。)

第一件學到嘅事係:推出一個 game 好難。 第二件係:你唔可以靠 document 推理出一個好 game loop。

你要見到佢郁。你要玩到佢,或者至少將佢放入 Godot runtime,睇角色、鏡頭、操作、feedback 係咪真係產生到某種感覺。然後你要願意做、刪、cut、再做,直到有啲有趣嘅嘢出現。

以下係成件事。


Project 1: The AI Pet Sanctuary(288 commits)

2025 年 12 月 – 2026 年 2 月

第一個 project 由一個簡單 idea 開始:如果你有一隻住喺電腦入面、可以用 AI 同你傾偈嘅 pet,會點?唔係一個有 pet avatar 嘅 chatbot,而係一隻有 behaviors、habitat、personality 嘅真正 pet。

我做咗一個 full-stack web application。Frontend 用 React,backend 用 FastAPI,database 用 Supabase。Conversations 用 Gemini,video 用 Cloudflare Stream。

最 ambitious 嘅部分係 animation system。我想要 18 種 pet types,分成六大類:dogs、cats、birds、small animals、fish、reptiles。每一種都要識郁、識眨眼、感覺似係活生生。

我一開始用 Rive animations。佢哋唔適合呢個 use case。於是我改用 CSS 同 JavaScript pet animations。之後我用 Google Veo 3.1 建立 pipeline 去 generate animation content,即係用 AI video generation 做 pet movements。佢係 work 嘅,但好 brittle。API 會 fail,lighting 唔 consistent,generation 之間 scale 會 shift。我花咗更多時間同 generation pipeline 打交,而唔係 design 真正嘅 pet experience。

我亦都做咗 habitat system,有 full-screen immersive environments。pet 住喺一個叫 "The Study" 嘅房。Care screens。Memory screens。Conversation integration。中途仲做咗一次完整嘅 "Quiet Luxury" redesign,因為第一版睇落似 prototype。(因為佢真係 prototype。)

然後我 pivot 咗。

288 commits 之後,我決定 web app 係錯嘅 platform,開始 plan native iOS version。 到而家我都唔肯定呢個係正確 call,定係 boredom 扮成 strategy。我有一部分相信,喺 phone 上嘅 pet 會比 browser 入面嘅 pet 更 intimate。另一部分又覺得,我可能只係厭咗 React。

但如果老實講,我冇推出佢嘅真正原因更簡單:佢好悶。 我做咗所有嘢——habitats、animation system、conversation integration——但當我真係坐低同 pet interact,我兩分鐘內就冇興趣。冇任何嘢足夠 compelling 去留住我嘅 attention。我由 secondary school 開始玩 games,所以我信呢個 first reaction,雖然我唔係永遠都知道點修。到而家我仲會同屋企人玩 Mobile Legends,通常爬到 Mystic。嗰個唔係為咗 passive comfort 而玩嘅 game——佢要求 skill 同 attention。呢個 pet sanctuary 兩樣都冇要求。

我不停同自己講,問題係 platform。Web app 唔能夠 deliver 我想要嘅 immersive experience。可能 iOS 會唔同。但內心深處我知道,問題唔係 React,而係 design。換 platform 唔會令一個 uninteresting game loop 突然變得 exciting。

邊度出咗問題

回頭睇 repo,我唔覺得正確 lesson 係「288 commits 冇 release 好差」。如果 core loop 唔吸引,早啲推出只係早啲推出一個悶嘅嘢。

真正問題係,我喺證明 loop 之前,不停換 container。Project 由 merge/order mechanics,去 pure companion,去 immersive habitats,再去 iOS。每次 pivot 都有原因。但我冇清楚回答一個更簡單問題:我會唔會想每日打開佢?

我本來可以用一隻 pet、一間 room、一段 conversation、一個 care/play interaction 去 validate。相反,我喺得到最重要 runtime 答案之前,就做咗 18 種 pet types、6 個 animal categories、同完整 habitat system。呢隻 pet 係咪有趣到令人想返嚟?

AI-generated animation 好 powerful,但亦好 brittle。 佢 work 嘅時候好 amazing。唔 work 嘅時候,你 debug 嘅係 prompts 同 API failures,而唔係 product。你需要 fallback pipeline,而我冇足夠早做。

我學到咩

第一件事唔係 cut scope。第一件事係搵到有趣嘅部分。 有時代表要做更多。有時代表要刪走啱啱做完嘅嘢。錯唔係 exploration。錯係冇 playable proof 去話俾我知 core experience 有冇生命力,但我仍然 explore 太耐。


Project 2: 變成 stepping stone 嘅 fox(35 commits)

2026 年 4 月 17 日 – 5 月 12 日

pet sanctuary pivot 去 iOS 之後,我喺 Godot 4.6 開咗新 project。今次我想喺真正 game engine 入面由零開始做 game,而唔係一個扮 game 嘅 web app。

Initial concept 係 Spirit Fox Kit Sanctuary Sim。一隻小 fox 住喺 cozy room,你照顧佢。Simple、warm、contained。

我 setup 咗 Godot project。我試住 design 一個 fox character,有 hidden tense silhouettes、更快嘅 twitch animations、同 stillness 嘅 micro-signals。

但呢句講法令 prototype 聽落比實際更 legible。喺 screen 上,隻 fox 根本讀唔成 fox。佢似一團細細嘅 mass。我睇唔到 usable shape,更加唔好講判斷佢周圍個 room 嘅其他 visuals。

我做咗 draft room loop,有 GUT test coverage。Placeholder audio。Interactables 嘅 hover cues。Room scene layout。一個 cold-start playtest harness,令我真係可以玩佢。

然後我玩咗。

老實講,問題更 visual,唔係咁 philosophical:隻 fox 喺 first read 就 fail 咗。Room prototype 有 mechanically verified path,repo 甚至記錄咗 placeholder-art build 嘅 abbreviated solo gate pass。Stillness、emergence beat、touch distinction、room problem 喺嗰個 stage 係 acceptable。

但對一個細小 authored beat 嚟講 acceptable,唔等於 visually strong enough 去支撐成個 game。呢個 project 依賴隻 fox 去 carry experience。如果我睇唔到佢嘅 shape、posture、appeal,sanctuary loop 就仲未有 chance。

所以 4 月 20 日,即係開始後三日,我寫咗 full pivot spec。fox sanctuary sim 變成完全唔同嘅嘢:一個 landscape action-adventure,有 warm safehouse,同可以 explore 嘅 hostile territory。我 pause 咗 fox-first plans,開始 design 新 direction。

35 commits。一個 validated beat。一個 pivot。冇嘢推出。

邊度出咗問題

真正問題係,我當 animation signals 可以補償 unreadable base shape。佢哋唔可以。如果下面個 body 冇 silhouette,一個 twitch 冇乜意思。

Pivot 唔係證明第一批 work 浪費咗。佢令第一批 work 變成 foundation。我仍然冇嘅係 evidence:更大嘅 Hearthkeeper direction 會 work,或者我可以令 core character readable 到令人 care。

我學到咩

早期 playtesting 會揭示 prototype 真正證明緊咩。 Room prototype 證明咗 tone、pacing、relationship beat。佢冇證明成個 game,反而即刻 expose 咗 visual readability problem。呢個係 useful information,但佢指向另一個 next step:先解決 character read,build 最細嘅 safehouse -> run -> return loop,再返去 polish 隻 fox。

Game 1 教我,一個 technically complete 嘅 loop 都可以好悶。Game 2 教我,一個 documented、tested 嘅 character concept 都可以喺幾秒內 visually fail。呢兩個 failure 係 Game 3 有更多 real progress 嘅原因之一:我更加注意 readability、motion、weapon feel,以及 playable slice 喺 screen 上係咪 work。

由 evidence 出發嘅 pivot,唔等於 drifting。 隻 fox 喺 runtime 讀唔到,所以改 direction 唔 automatically 係 discipline failure。我要改善嘅係 feedback loop:更快將最 risky 嘅 visual 或 gameplay question 放上 screen,然後用 evidence 決定,而唔係停留喺 concept mode。


Project 3: Pipeline 開始跑得起嘅 project(361 commits)

2026 年 4 月 21 日 – 5 月 13 日

呢個係我仲喺做嘅 project。亦都係第一、第二個 project 嘅 learning 開始 compound 嘅地方。

佢係一個 mech tactics game。你控制一隊 mechs 進入 combat,每場 battle 之後,一個 LLM 會 analyze 發生咗咩,然後俾你 debrief。可以想像成 post-match analysis,不過係由一個可以 access 全部 game state 嘅 AI 寫。

Repo 有三個 tracks,但而家佢哋唔再 equal:

Track A — The LLM Debrief System: 呢個係早期 AI validation track。佢幫我 test structured debriefs,但已經唔係 main product path。

Track B — The 2D Phone Prototype: 呢度係我第一次搵到一條 work 得到嘅 pipeline,做到相對 immersive 嘅 2D player experience。實際 Godot runtime 有 lane-match combat loop、touch joystick、shop/modules、hero XP、ability cooldowns、手機上讀得到嘅 VFX motifs、enemy punish zones、neutral relay objective、HUD feedback、iOS export/testing flow。Art pipeline 亦開始 work:Nano Banana 2 (Gemini 3.1 Flash Image) generate 咗 usable initial hero 同 character images,然後 MCP-based pixel cleanup workflow 同 Aseprite 將 curated candidates 變成 cleaned sprites、animation frames、Godot-ready sheets。佢未係完成版 game,phone acceptance 都仲 pending,但比起頭兩個 project,已經更接近「呢個有 game feel」。

Track C — The Campaign and 3D Path: 呢個係 current product direction。佢保留 Track B 嘅有用 lessons,加 campaign memory loop,並將 production combat 推向 3D/2.5D。呢個問題比 2D pipeline 難好多。喺 2D,我可以用 sprite sheets、HUD tuning、procedural VFX、phone captures 控制可讀性。喺 3D,每個 decision 都會 touch 到 modeling、rigging、animation、camera、lighting、GLB export、weapon sockets、hit anchors、action timing、runtime performance。

我亦 integrate 咗 Blender 做 custom rigging work,引入 Rokoko mocap data 做 locomotion,並 build 咗一個有 full rig、animation tree、weapon socket integration 嘅 hero mech character。

三個星期 361 commits。一條真正 2D pipeline。一個更難嘅 3D experiment。仍然係 prototype 階段。

邊度出咗問題

呢個係我要承認嘅事:2D pipeline 開始 work,但如果我俾 3D pipeline 任佢發展,佢可以吞咗成個 project。

對 Track B 嚟講,pipeline work 唔係假進度。Nano Banana 2 -> Aseprite workflow、touch controls、HUD、讀得到嘅 ability motifs、module feedback、phone captures、export loop 都令 product 更 playable。呢啲 work 教我 player 每一刻需要睇到同 feel 到咩。

而家嘅 risk 唔同。Track C 入面,3D 喺 feel 到似一樣嘢之前,需要好多 pipeline:model import、rig quality、animation names、weapon attachment、muzzle position、hit center、camera angle、lighting、movement、jump timing、attack timing、VFX、runtime inspection。呢啲唔係可有可無嘅 details。如果角色讀唔到,成個 scene 幾秒內就 fail。

但 playable encounter 仍然要行先。否則我可以用幾個星期改善 hero mech 嘅 weapon fit、jump compression、left-hand IK、mocap cleanup,但都冇回答 player 最簡單嘅問題:控制佢好唔好玩?

我學到咩

Pipeline work 只有喺繼續服務 playable slice 時先有用。 Track B 教我,正確 pipeline 可以 create 更 immersive 嘅 2D experience。Track C 教我,3D 會提高每一次 improvement 嘅 cost。我需要令 acceptance gate 保持具體:player 讀唔讀到 hero mech?郁唔郁到佢?aim、fire、理解 hit,然後想唔想再做一次?

Track 需要 gate。 Track A 完成咗佢嘅任務。Track B 留低咗 reusable 2D game feel 同 presentation lessons。Track C 係 current bet。問題唔係我 explore 咗 multiple paths。問題係冇清楚嘅 runtime question 同判斷準則,就重新打開佢哋。

3D game development 係一個巨大 skill gap。 Rigging、animation、mocap data、asset budgets、weapon sockets、camera framing、readable motion 都係我冇 professional experience 嘅 disciplines。我一邊學佢哋,一邊學 Godot、game design、campaign architecture。Learning curve 唔係 steep,係 vertical。我諗呢個係最令我意外嘅部分。Web development 入面,我一日可以 build 到 functional 嘅嘢。3D game dev 入面,我可以用成個晚上只係想令 character 隻手 bend 得啱。(六個月前,我唔會明白呢句講緊咩。)


三個 project 有咩共通點

如果我對自己 honest——而呢篇 post 只有喺我 honest 時先 work——pattern 唔係「scope creep」。呢個講法太 easy,而且喺呢個 case 我覺得係錯。

我唔覺得遊戲好似 business decks 咁 work,至少呢三個 project 係咁教我。你唔會因為 premise 聽落好,就知道 idea 會 work。你要玩到佢,或者至少見到佢喺 engine 入面 run,然後 feel 到角色、鏡頭、interaction、feedback 係咪有做緊嘢。

1. Runtime 先係真相

pet sanctuary 聽落好,直到我同 pet interact 然後覺得悶。fox 聽落好,直到我喺 Godot 見到佢,發現讀唔到形狀。Track B 開始 work,係因為 loop 入咗 phone-like runtime:touch controls、HUD、VFX、shop、XP、readable motifs、capture feedback。

呢個先係 real pattern。有用嘅 truth 只有喺 idea 變成 visible 同 playable 之後先到。

2. Exploration 有必要,但需要 evidence

我唔覺得正確 lesson 係「唔好再加嘢」。Game development 需要 exploration。你做、試、刪、cut、再做、再試,因為你喺度搵有趣嘅部分。

需要 discipline 嘅唔係工作量,而係 evidence loop。每一件 work 都應該回答一個問題:呢樣嘢有冇令 game 更讀得清、更吸引、更易控制、更值得再玩?

3. Pipeline 令 game 更可玩時先係好 pipeline

Nano Banana 2 -> MCP cleanup -> Aseprite workflow 唔係 distraction。佢幫我將更好嘅 2D characters 同 animation 放入 game。Track B 嘅 HUD 同 VFX work 都唔係假進度。佢令 runtime 更清楚。

Risk 係當 pipeline 停止回答 player-facing question。Track C 需要 3D tooling,但佢一定要返去一件事:player 讀唔讀到 hero mech、郁唔郁到佢、fire weapon、理解 hit,然後想唔想再做一次?

4. Gap 唔係 coding skill,而係判斷遊戲係咪好玩、可玩嘅能力。

我可以用 Supabase、FastAPI、React build full-stack application。我可以 rig 3D model、寫 GUT tests、build custom debugging tools。我仍然喺學嘅係,點樣 judge 一樣嘢作為 game 係咪真係 interesting。Track B 令我喺 2D 更接近。Track C 俾我睇到,當 motion、camera、lighting、weapons、animation 全部要一齊 work,件事會難幾多。

我覺得呢個係最重要嘅 learning。Code 係我擅長嘅部分。難嘅係 decide 呢個 game 真正係咩,令佢有趣,然後有 discipline 不斷返去 runtime evidence,直到佢值得推出。


整體我學到咩

如果我要將六個月 distill 成有用嘅嘢——俾自己,或者俾任何處於同一位置嘅人——呢啲係我覺得而家知道、但 12 月時未知道嘅事:

  1. 第一個 version 應該喺 runtime 回答最高風險嘅 question。 我嘅 pet sanctuary 需要一個令我想返嚟嘅 pet interaction。fox game 需要喺 blank room 入面有讀得到嘅 silhouette,先好擔心 micro-signals。mech game 透過 Track B 更接近,因為我可以喺 screen 上見到同 feel 到個 loop。

  2. Playtesting 唔係可選項,runtime review 都 count。 我見到 fox 似一團冇形狀嘅 mass 嗰刻,就知道 project 仲未 work。嗰 30 分鐘係成個 project 最有價值嘅時間。我應該更早到達呢個 visual truth。

  3. Learning 係有效 outcome,就算唔係你原本 plan 嘅 outcome。 我本來想 build games。我冇推出 games。但我學咗 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,以及 building tools 同 building products 嘅分別。呢個唔係 nothing。呢個亦係點解 Game 3 比 Game 1 同 Game 2 更好,即使佢仍然未推出。

  4. 我仍然需要 define 一個 honest finish line。 我有一部分想將呢個 project 推到 completion,咁我就可以話自己推出咗一個 game。另一部分覺得 learning 就係 product,我應該接受。兩個答案都 honest。我覺得 truth 喺中間:推出一個 focused slice,尊重我學到嘅嘢,而唔係再由 zero restart。

下一步

我仍然喺做 mech tactics project。LLM debrief concept 好 interesting,而我覺得 AI-powered post-match analysis for a tactics game 呢個 idea 入面有 genuinely novel 嘅嘢。

但我嘗試改 approach:先做 runtime proof,polish later,只喺 playable slice 有 reason to exist 之後先推出。頭兩個 project 冇浪費。佢哋改變咗我喺 Game 3 睇嘅嘢:character 讀唔讀到,motion feel 好唔好,weapon feel 啱唔啱,一個人可唔可以唔聽我解釋 architecture 都理解 encounter。

如果今日開始一個新 game,我唔會由大 architecture plan 開始。我會由最快可以回答我真正在意問題嘅 runtime proof 開始。對 Game 3 而家嚟講,同一種 discipline 要喺 project 入面發生:one character、one weapon、one encounter、one clear acceptance test。

我仲未知道自己會唔會將其中一個 project 推到 completion,或者接受 learning 就係 product。我可能對 timeline 估錯,但我覺得 pattern 比任何 single project 更重要。

問你一個問題

我係真心想問,唔係 rhetorical:你有冇嚟過呢度?(我懷疑比我哋平時承認更多 builders 都試過。)

你有冇花幾個月 build 一樣最後冇推出嘅嘢?你最後完成咗佢,定係離開咗?如果你離開咗,嗰個係正確決定嗎?定係你到而家仲會諗起?

我喺 career 入面推出過好多嘢。Campaigns、platforms、products。但嗰啲都係我有 18 年 experience 嘅 domain。Game development 對我係新嘅,而「我 technically 可以 build 到」同「呢個係一個好 game」之間嘅 gap,比我預期大好多。

如果你曾經跨過呢個 gap,我好想知道係咩令你冇再 pivot away。可以喺 LinkedIn reply,或者直接 send note 俾我——我真係好 curious。


今次就寫到呢度。我好想聽你嘅諗法——尤其係如果你都經歷過類似嘅事。你可以喺 LinkedIn 聯絡我,或者直接 send message。

祝好,

Chandler

繼續閱讀