6个月，3个游戏项目，0个上线

我本来几周前就想写这篇文章。但我想，自己可能还在期待，等我真正坐下来写的时候，三个正在做的游戏里至少有一个已经完成了。

结果一个都没有。

所以现在的情况是：六个月，三个项目，684个 commits，但没有任何东西可以让你下载、试玩，或者发给朋友。如果你曾经在全职工作之外学习一件全新的、真正困难的、自己并不擅长的事，你大概会非常理解这种感觉。

我还是决定写下来，因为我觉得“为什么什么都没有上线”这个故事，比一个已经完成项目的漂亮发布公告更有用。

开始时的背景

我在 advertising 行业工作了18年。这是一份好工作，也很有挑战性，而且我知道怎么做。我上线过 campaigns，搭过团队，写过书，也站上过舞台。在那个世界里，我知道“done”是什么样子。

然后在2025年底，我决定学习游戏开发。不是 game marketing，不是 game strategy，而是真的做游戏：代码、美术、系统，以及角色在屏幕上移动时的手感。

我没有游戏引擎经验。我从来没有给3D模型做过 rigging。我也不知道 animation 语境里的 state machine 是什么。我这几年一直在写代码，主要是 web apps 和 AI products，但游戏是完全不同的学科。（如果这里有任何地方我说错了，请纠正我——我还在学。）

我学到的第一件事是：发布一个游戏很难。 第二件事是：你不能只靠文档推理出一个好游戏循环。

你必须看到它动起来。你必须玩它，或者至少把它放进 Godot runtime 里，看角色、镜头、操作和反馈是否真的产生了某种感觉。然后你还要愿意构建、删除、削减、重建，一直到有趣的东西出现。

下面是发生的事情。

---

Project 1: The AI Pet Sanctuary（288 commits）

2025年12月 – 2026年2月

第一个项目从一个简单想法开始：如果你有一只住在电脑里的 pet，可以用 AI 和你说话，会怎样？不是带宠物 avatar 的 chatbot，而是一只有 behavior、habitat 和 personality 的真正 pet。

我做了一个 full-stack web application。Frontend 用 React，backend 用 FastAPI，database 用 Supabase。我用 Gemini 做 conversations，用 Cloudflare Stream 做 video。

最有野心的部分是 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 来生成 animation content，也就是用 AI video generation 生成 pet movements。它能工作，但很 brittle。API 会 fail，lighting 不一致，scale 会在 generation 之间漂移。我花在和 generation pipeline 斗争上的时间，比设计真正的 pet experience 还多。

我还做了 habitat system，有 full-screen immersive environments。pet 住在一个叫 "The Study" 的房间里。Care screens。Memory screens。Conversation integration。中途还做了一次完整的 "Quiet Luxury" redesign，因为第一版看起来像 prototype。（因为它就是。）

然后我 pivot 了。

288 commits 之后，我决定 web app 是错误的平台，开始计划 native iOS version。 到现在我也不知道这是正确判断，还是 boredom 伪装成 strategy。我的一部分相信，手机上的 pet 比 browser 里的 pet 更 intimate。另一部分觉得，我可能只是厌倦了 React。

但如果诚实一点，我没有发布它的真正原因更简单：它很无聊。 我做了这么多东西——habitats、animation system、conversation integration——但当我真正坐下来和 pet 互动时，两分钟内就失去了兴趣。没有任何东西足够 compelling，可以留住我的注意力。我从 secondary school 就开始玩游戏，所以我信任这种第一反应，虽然我并不总是知道怎么修。现在我还会和家人一起玩 Mobile Legends，而且通常会爬到 Mystic。那不是一个靠被动舒适感维持的游戏——它要求 skill 和 attention。而这个 pet sanctuary 两者都不要求。

我一直告诉自己，问题是平台。Web app 给不了我想要的 immersive experience。也许 iOS 会不同。但内心深处我知道，问题不是 React，而是 design。换平台不会让一个无趣的 game loop 突然变得有趣。

哪里出了问题

回头看 repo，我不认为正确的 lesson 是“288 commits 没有 release 很糟糕”。如果核心循环不吸引人，提前发布只是更早发布一个无聊的东西。

真正的问题是，我在证明 loop 之前一直更换 container。项目从 merge/order mechanics，到 pure companion，到 immersive habitats，再到 iOS。每次 pivot 都有理由。但我没有足够清楚地回答一个更简单的问题：我会想每天打开它吗？

我本可以用一只 pet、一个 room、一次 conversation、一个 care/play interaction 来验证这个问题。相反，在得到最重要问题的运行时答案之前，我已经做了18种 pet types、6个 animal categories 和完整 habitat system。这个 pet 是否有趣到让人想回来？

AI-generated animation 很强大，但也很 brittle。 当它工作时，非常惊艳。当它不工作时，你 debug 的不是 product，而是 prompts 和 API failures。你需要一条 fallback pipeline，而我没有足够早地做出来。

我学到了什么

第一件事不是砍 scope。第一件事是找到有趣的部分。 有时这意味着多做一点。有时意味着删掉刚刚做出来的东西。错误不是探索。错误是在没有可玩的证据时探索太久，而这个证据本应告诉我 core experience 是否有生命力。

---

Project 2: 变成垫脚石的狐狸（35 commits）

2026年4月17日 – 5月12日

pet sanctuary pivot 到 iOS 之后，我在 Godot 4.6 里开始了一个新项目。这一次，我想在真正的 game engine 里从零做一个 game，而不是让 web app 假装自己是 game。

最初的 concept 是 Spirit Fox Kit Sanctuary Sim。一只小狐狸住在温暖的房间里，你照顾它。简单、温暖、克制。

我 set up 了 Godot project。我试着设计一个 fox character，有 hidden tense silhouettes、更快的 twitch animations，以及 stillness 的 micro-signals。

但这句话让 prototype 听起来比实际更 legible。屏幕上，那只狐狸根本读不成狐狸。它像一小团 mass。我看不出 usable shape，更别说判断周围房间的其他 visual 了。

我做了一个 draft room loop，有 GUT test coverage。Placeholder audio。Interactables 的 hover cues。Room scene layout。还有 cold-start playtest harness，这样我可以真的玩它。

然后我玩了。

诚实地说，这个问题更 visual，而不是哲学性的：狐狸在 first read 就失败了。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，不等于视觉上足够强，可以支撑整个游戏。这个项目依赖狐狸来承载体验。如果我看不到它的 shape、posture 和 appeal，那么 sanctuary loop 还没有机会。

所以在4月20日，也就是开始后的第三天，我写了一份完整的 pivot spec。fox sanctuary sim 变成了完全不同的东西：一个 landscape action-adventure，有温暖的 safehouse，也有可探索的 hostile territory。我暂停了 fox-first plans，开始设计新的方向。

35 commits。一个 validated beat。一次 pivot。没有上线。

哪里出了问题

真正的问题是，我把 animation signals 当成了可以弥补 unreadable base shape 的东西。它们不能。如果底下的 body 没有 silhouette，一个 twitch 并不重要。

Pivot 并不证明第一批工作被浪费了。它把第一批工作变成了 foundation。我仍然缺少的是 evidence：更大的 Hearthkeeper direction 是否能工作，或者我能否把它的 core character 做到 readable 到让人关心。

我学到了什么

早期 playtesting 会揭示 prototype 到底在证明什么。 Room prototype 证明了 tone、pacing 和一个 relationship beat。它没有证明整个 game，而且立刻暴露了 visual readability problem。这是有用的信息，但它指向不同的下一步：先解决 character read，建立最小的 safehouse -> run -> return loop，再去 polish 那只狐狸。

Game 1 教会我，一个 technically complete 的 loop 仍然可能很无聊。Game 2 教会我，一个已经 documented、tested 的 character concept 仍然可能在几秒钟内 visual fail。这两个失败也是 Game 3 能取得更多 real progress 的原因：我更关注 readability、motion、weapon feel，以及 playable slice 是否在屏幕上成立。

基于 evidence 的 pivot 不等于 drifting。 狐狸在 runtime 里读不出来，所以改变方向并不自动意味着缺乏 discipline。我要改进的是 feedback loop：更快把最 risky 的 visual 或 gameplay question 放到屏幕上，然后用 evidence 决定，而不是一直停留在 concept mode。

---

Project 3: Pipeline 开始跑起来的那个项目（361 commits）

2026年4月21日 – 5月13日

这是我还在做的项目。它也是前两个项目的学习终于开始 compound 的地方。

这是一个 mech tactics game。你控制一队 mechs 进入 combat，每场 battle 之后，一个 LLM 会分析发生了什么，并给你一份 debrief。可以把它想成 post-match analysis，只不过是由一个能 access 全部 game state 的 AI 写的。

这个 repo 有三个 tracks，但它们现在不再同等重要：

Track A — The LLM Debrief System: 这是早期 AI validation track。它帮助我 test structured debriefs，但已经不是 main product path。

Track B — The 2D Phone Prototype: 这是我第一次找到一条可行的 pipeline，能支撑相对有沉浸感的 2D 玩家体验。实际 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 也开始工作：Nano Banana 2 (Gemini 3.1 Flash Image) 生成了可用的初始 hero 和 character images，然后 MCP-based pixel cleanup workflow 和 Aseprite 把 curated candidates 变成 cleaned sprites、animation frames 和 Godot-ready sheets。它还不是完成的游戏，phone acceptance 也还 pending，但它比前两个项目更接近“这感觉像一个游戏”。

Track C — The Campaign and 3D Path: 这是当前 product direction。它保留 Track B 的有效经验，增加 campaign memory loop，并把 production combat 推向 3D/2.5D。这比 2D pipeline 难得多。在 2D 里，我可以用 sprite sheets、HUD tuning、procedural VFX 和 phone captures 控制可读性。在 3D 里，每个决策都会触碰 modeling、rigging、animation、camera、lighting、GLB export、weapon sockets、hit anchors、action timing 和 runtime performance。

我也接入 Blender 做 custom rigging work，引入 Rokoko mocap data 做 locomotion，并构建了一个有 full rig、animation tree 和 weapon socket integration 的 hero mech character。

三周361 commits。一条真实的 2D pipeline。一个难得多的 3D experiment。仍然在原型阶段。

哪里出了问题

这里是我必须承认的事：2D pipeline 开始工作了，但如果我放任它，3D pipeline 可以吞掉整个项目。

对 Track B 来说，pipeline work 不是假进展。Nano Banana 2 -> Aseprite workflow、touch controls、HUD、可读的 ability motifs、module feedback、phone captures 和 export loop 都让 product 更可玩。那项工作教会我，玩家在每一个瞬间需要看到和感受到什么。

现在的风险不一样了。在 Track C 里，3D 在感觉像任何东西之前，都需要很多 pipeline：model import、rig quality、animation names、weapon attachment、muzzle position、hit center、camera angle、lighting、movement、jump timing、attack timing、VFX 和 runtime inspection。这些不是可有可无的细节。如果角色读不出来，整个 scene 会在几秒钟内失败。

但可玩的 encounter 仍然必须走在前面。否则我可以花几周时间改 hero mech 的 weapon fit、jump compression、left-hand IK 和 mocap cleanup，却没有回答玩家最简单的问题：控制它好玩吗？

我学到了什么

Pipeline work 只有在持续服务可玩的 slice 时才有用。 Track B 教会我，正确的 pipeline 可以创造更有沉浸感的 2D experience。Track C 正在教我，3D 会提高每一次改进的成本。我必须让 acceptance gate 保持具体：玩家能读出 hero mech 吗，能移动它吗，能 aim、fire、理解 hit，并且想再来一次吗？

Track 需要 gate。 Track A 完成了它的任务。Track B 产出了可复用的 2D game feel 和 presentation lessons。Track C 是当前的 bet。问题不是我探索了多条 path。问题是在没有清楚的运行时问题和判断规则时重新打开它们。

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 里，我一天就能做出 functional 的东西。在 3D game dev 里，我花了一个晚上试图让 character 的胳膊弯得对。（六个月前我不会理解这种句子。）

---

这三个项目有什么共同点

如果我对自己诚实——而这篇文章只有在我诚实时才成立——pattern 不是“scope creep”。这太容易了，而且在这个 case 里我觉得是错的。

我不认为游戏像 business decks 那样工作，至少这三个项目是这样教我的。一个 idea 是否可行，不是因为前提听起来好。你要能玩它，或者至少看到它在 engine 里运行，并感受到角色、镜头、interaction 和 feedback 是否真的做了什么。

1. Runtime 才是真相

pet sanctuary 听起来不错，直到我和 pet 互动并感到无聊。狐狸听起来不错，直到我在 Godot 里看到它，发现读不出形状。Track B 开始工作，是因为 loop 进入了类似手机的 runtime：touch controls、HUD、VFX、shop、XP、readable motifs 和 capture feedback。

这才是真正的 pattern。有用的真相只有在 idea 变得可见、可玩之后才出现。

2. 探索是必要的，但它需要 evidence

我不认为正确的 lesson 是“不要再加东西了”。Game development 需要 exploration。你构建、尝试、删除、削减、重建、再尝试，因为你在寻找有趣的部分。

需要 discipline 的不是工作量，而是 evidence loop。每一项工作都应该回答一个问题：这是否让游戏更可读、更吸引人、更可控、更值得再玩？

3. Pipeline 在让 game 更可玩时才是好的

Nano Banana 2 -> MCP cleanup -> Aseprite workflow 不是 distraction。它帮助我把更好的 2D characters 和 animation 放进 game。Track B 的 HUD 和 VFX work 也不是假进展。它让 runtime 更清楚。

风险是当 pipeline 停止回答 player-facing question。Track C 需要 3D tooling，但它必须不断回到一件事：player 能读出 hero mech、移动它、发射 weapon、理解 hit，并想再来一次吗？

4. Gap 不是 coding skill，而是判断游戏是否可玩的能力。

我可以用 Supabase、FastAPI 和 React 构建 full-stack application。我可以 rig 3D model、写 GUT tests、构建 custom debugging tools。我还在学的是，如何判断一个东西作为 game 是否真的 interesting。Track B 让我在 2D 里更靠近答案。Track C 则让我看到，当 motion、camera、lighting、weapons 和 animation 必须一起工作时，这件事会难多少。

我觉得这是最重要的学习。Code 是我擅长的部分。难的是决定 game 到底是什么，把它变得有趣，然后有 discipline 不断回到 runtime evidence，直到它值得发布。

---

我整体学到了什么

如果把六个月浓缩成一些有用的东西——对我自己，或者对任何处在类似位置的人——我现在觉得自己知道了这些在12月还不知道的事：

1. 第一个 version 应该在 runtime 里回答风险最高的问题。 我的 pet sanctuary 需要一个让我想回来的 pet interaction。我的 fox game 需要先在 blank room 里有可读的 silhouette，再去担心 micro-signals。我的 mech game 通过 Track B 更接近答案，因为我能在屏幕上看到和感受到 loop。

2. Playtesting 不是可选项，runtime review 也算。 当我看到 fox 像一团没有形状的块时，我就知道项目还没工作。那是整个项目里最有价值的30分钟。我应该更早到达这个视觉真相。

3. 学习是有效的结果，即使它不是你原本计划的结果。 我本来想 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 的区别。这不是一无所获。这也是为什么 Game 3 比 Game 1 和 Game 2 更好，哪怕它还没发布。

4. 我还需要定义一个诚实的 finish line。 我的一部分想把这个 project 推到 completion，这样我可以说自己发布了一个 game。另一部分觉得 learning 就是 product，我应该接受它。两个答案都诚实。我觉得真相在中间：发布一个尊重这些学习的 focused slice，而不是再次从零开始。

接下来

我还在做 mech tactics project。LLM debrief concept 很有趣，而且我觉得 AI-powered post-match analysis for a tactics game 这个想法里有真正新颖的东西。

但我正在努力改变 approach：先做 runtime proof，再做 polish，只有当 playable slice 有存在理由之后才发布。前两个项目没有浪费。它们改变了我在 Game 3 里看的东西：character 是否 readable，motion feel 是否好，weapon feel 是否对，一个人是否能在不听我解释 architecture 的情况下理解 encounter。

如果今天开始一个新 game，我不会从一个大的 architecture plan 开始。我会从最快的 runtime proof 开始，用它回答我真正关心的问题。对 Game 3 来说，同样的 discipline 现在必须发生在 project 内部：一个 character、一个 weapon、一个 encounter、一个清楚的 acceptance test。

我还不知道自己会不会把其中一个 project 推到 completion，或者接受 learning 就是 product。关于 timeline，我可能是错的，但我觉得 pattern 比任何单个项目更重要。

给你的一个问题

我是真心想问，不是修辞：你来过这里吗？（我怀疑比我们通常承认的更多 builders 都来过。）

你是否花了几个月做一个从未发布的东西？你最后完成了吗，还是离开了？如果你离开了，那是正确的选择吗，还是你现在还会想起它？

我在职业生涯里发布过很多东西。Campaigns、platforms、products。但那些都是在我有18年 experience 的 domain 里。Game development 对我来说是新的，而“我技术上可以做出来”和“这是一个好 game”之间的 gap，比我想象中大得多。

如果你已经跨过这个 gap，我很想知道是什么让你没有再次 pivot away。欢迎在 LinkedIn 回复，或者直接给我发 note——我真的很好奇。

---

今天就到这里。我很想听听你的想法，尤其是如果你也经历过类似的事情。可以在 LinkedIn 上联系我，或者直接给我发消息。

祝好，

Chandler