为什么九成的游戏做不完

先看那条永远后退的线

下面这个模拟器里，每个功能都有三笔账。默认只勾了核心玩法，你往上加功能试试。

建议试法：先勾「10 个关卡」和「存档系统」，看日期。然后再勾「Boss 战」「技能树」「多结局」。最后勾上「联机合作」。

项目不是被「做什么」杀死的

没有人一开始就打算做一个三年做不完的游戏。它是这样发生的：

第 1 周   做了个角色能跑能跳。挺好玩的！
第 3 周   做了三个关卡。要是有个 Boss 就更好了。
第 6 周   Boss 做完了。玩家死了要重来太麻烦，加个存档吧。
第 9 周   存档做完了。既然有存档，那加个技能树很自然吧？
第 14 周  技能树做完了，但现在关卡太简单了，得重做。
第 20 周  关卡重做中。突然想到：要是能和朋友一起玩……
第 30 周  联机做了一半，发现要重构所有的游戏逻辑。
第 40 周  已经三个月没碰这个项目了。
第 52 周  「我下次要做个小一点的。」

看这条线里的每一步。每一个决定单独看都很合理 —— 加 Boss 让游戏更完整，加存档解决了真实的痛点，加技能树增加了深度。

问题不在任何单个决定，在于它们的累积，而累积的速度比你感觉的快得多。

动力曲线：真正的敌人

上面算的都是工作量。但个人项目真正的杀手不是工作量，是动力 —— 而动力有一条非常固定的形状：

动力
 ↑
 │████                                          第 1–2 周：兴奋期
 │████▇▇                                        什么都新鲜，进展飞快
 │████▇▇▆▆
 │████▇▇▆▆▅▅                                    第 3–8 周：平稳期
 │████▇▇▆▆▅▅▄▄▄▄▄▄                              还行，有产出
 │████▇▇▆▆▅▅▄▄▄▄▄▄▃▃▃
 │████▇▇▆▆▅▅▄▄▄▄▄▄▃▃▃▂▂▂▂▂▂▂▂                   第 9 周之后：沙漠期
 │████▇▇▆▆▅▅▄▄▄▄▄▄▃▃▃▂▂▂▂▂▂▂▂▁▁▁▁▁▁▁▁▁▁▁       ← 大多数项目死在这里
 └──────────────────────────────────────────→ 时间

怎么活过沙漠期

三条实在的建议：

1. 把范围压到能在沙漠期到来之前做完。这是唯一的根本解 —— 也是为什么第 3 章建议 8–12 周。你不是在跟工作量赛跑，是在跟自己的动力曲线赛跑。
2. 给自己安排外部的兑现。沙漠期缺的是反馈。给别人玩、发一段短视频、参加一个 jam、定一个公开的发布日期 —— 外部的一点点回应，能补上内部枯竭的动力。
3. 把新点子写下来，然后继续。准备一个文件叫「下一个游戏」。新点子出现时郑重地写进去。这个动作能骗过大脑：你没有放弃那个点子，你只是排期了。

90% 陷阱

软件工程的老笑话，在游戏上尤其准：

前 90% 的工作占掉 90% 的时间。
剩下 10% 的工作占掉另外 90% 的时间。

「感觉快做完了」的那个时刻，通常离真正做完还有和之前一样长的路。因为剩下的那些事，是你一直在推迟的、不好玩的、但又不能不做的东西：

怎么砍：一套具体的方法

说了这么多「要砍」，具体怎么砍？下面这套判据是可以直接用的。

第一步：把所有功能列出来，分成三档

关键在于诚实。测试方法：把这条功能删掉，你的一句话玩法（第 3 章）还成立吗？

• 还成立 → 它不是「必须」
• 不成立 → 它是「必须」

用这个判据过一遍，你会发现「必须」通常只有三到五条。其他的全是你以为自己需要的。

第二步：对每个「应该」问一个问题

如果玩家只玩 15 分钟，他会注意到这个功能不存在吗？

不会 → 砍。

这个问题特别能识破那些「专业感」需求：

• 按键重绑：15 分钟的游戏里，绝大多数人不会去改键 → 砍（但要选一套通用的默认键位）
• 多语言：先发一个语言 → 砍
• 成就系统 → 砍
• 存档：如果一局 15 分钟 → 砍
• 设置菜单：只留音量和第 13 章那个震动开关 → 大幅砍

第三步：识别「伪装成小功能」的大功能

有些功能听起来很小，但会污染整个代码库。它们的特征是需要所有其他系统都为它做适配：

时间估算：为什么你总是估少

还有一个更基础的问题：人估算时间的方式是系统性偏低的，而且这个偏差不会因为经验增加而消失。

原因是规划谬误：估算时，人想象的是「一切顺利的情况」。而一切顺利的情况从不发生。

一个反向的用法

知道了自己的系数之后，可以反过来用它来定范围：

我想在 3 个月内做完                    → 约 24 个有效工作日
我的估算系数是 2.5×                    → 只能装下「我估计 10 天」的东西
那么：我的功能清单总估算不能超过 10 天

现在回去砍到 10 天为止。

这个算法很粗暴，但它把「范围控制」从一个意志力问题，变成了一个算术问题。而算术问题比意志力问题好解决得多。

「完成的定义」

回到一页纸的第 5 栏。这一栏现在该兑现了。

你需要一个写在纸上的、具体的、二值的完成条件。不是「等我觉得好了」—— 那一天永远不会来，因为你会一直看到能改进的地方。

【完成的定义】示例

这个游戏在满足以下全部条件时，就发布：

  □ 5 个关卡，每个都能从头玩到尾不卡死
  □ 第 1 关是无字教学，测试过的人 5 个里有 4 个能自己通过
  □ 有标题画面、通关画面，能重新开始
  □ 有音量滑块和屏幕震动开关
  □ 至少 5 个没玩过的人完整通关过，且记录了他们卡住的地方
  □ 已知的会导致卡死 / 崩溃的 bug 全部修完
  □ 视觉 bug 和「不够好看」的地方：不修

不满足以下任何一条，也发布：
  ✗ 美术不满意
  ✗ 想加的第 6 关
  ✗ 那个我一直想优化的手感细节

一个反面的安慰

最后说点别的。

这一章的调子很像在训话，但我想说清楚一件事：做不完不是道德问题。

做废的项目也有价值 —— 你学到的东西是真的。很多人的第三个游戏之所以能做完，正是因为前两个做废了。

真正要避免的不是「做废一个项目」，是一直在同一个地方做废：每次都在第 8 周弃坑，每次都学到同样的东西，每次都没有经历过「发布」这个环节。

本章小结

• 每个功能有三笔账：账面工作量、两两纠缠（按 n² 增长）、风险缓冲。人只会估第一笔。
• 项目不是被「做什么」杀死的，是被「顺便也做一下这个吧」杀死的。
• 真正的敌人是动力曲线，第 8–12 周的沙漠期是最大的死亡点。
• 活过沙漠期：压缩范围到能在它到来前做完、安排外部兑现、把新点子写进「下一个游戏」文件。
• 90% 陷阱：对策是第 1 周就搭一个「能发布的空壳」，让项目在任何时刻都是可发布的。
• 砍的三步：必须/应该/想要分档 → 问「玩 15 分钟会注意到吗」→ 识别伪装成小功能的基础设施。
• 基础设施（存档、暂停、撤销、联机、录像、手柄）要么第一周决定，要么永远不做。
• 写下二值的完成定义，包括「不满足以下条件也发布」那几条。