你的游戏每周都在变好，这正是你该担心的时候。The Swarm 团队眼看着一个有潜力的原型在几个月里变得更丰富、更连贯，最后却发现，更好的版本大约需要两倍的人手和两倍的时间。他们在开发约六个月后取消了它。这就是一款好游戏大到做不完的过程。
快速信息
来源：Evolve Games 团队的复盘 Learning from Failure: Post Mortem of an Unborn，2016年11月9日发表于 Game Developer。本文关于该项目的事实均出自这篇复盘。
定性：这是范围的故事，不是质量的故事。复盘说，游戏变好的同时超出了原定范围。
复盘里的时间线：约三个月前期制作、最初计划一年、约三到四个月的设计改动、开发约六个月后取消。
第二重打击：团队分裂。复盘讲到，年轻团队没有专人招聘、靠个人积蓄与兼职维持，成员离开后，团队选择重组并开启新项目。
本文不声称的内容：不写团队人数、引擎、类型、平台、销量或资金数字，也不用复盘相对时间线之外的具体开始日期。
最后核实：2026年10月30日。
变好的游戏，不再装得下原来的团队
按团队自己的说法，The Swarm 先做了约三个月前期制作，做出值得全力投入的东西，最初计划开发一年。团队自称是正在找位置的小独立团队，大多靠试错学习。麻烦不是一次糟糕决定，而是原型通过后不久、从设计一侧来的：围绕几个主要机制反复迭代。每次改动都感觉正常，游戏在开发中本来就会变，而且多数改动都是团队确信的改动，整体面貌似乎也需要它们，游戏才能成为想要的样子。
这个过程持续了三到四个月。单个小改动都不显眼，时间拉长后累积起来，团队离最初概念已经很远。这正是关键：改动一次来一个，问题很难早发现；而结果确实更好，按复盘的说法，更丰富、更连贯、深刻、有新意、核心也扎实，所以没有哪个时刻让人觉得游戏坏了。复盘说得很明确：失败不是游戏变了，而是游戏变好的同时，范围也在无人察觉中变了，直到超出边界。更好的版本大约需要两倍的人手和两倍的开发时间，而这两样都没有。
第二重失败让第一重变得致命
范围问题已经让人头疼时，第二重打击来了。复盘提到，从零拉起独立工作室很难，但这里有两点关键：没有专人负责招聘，找人和面试会花时间、拖慢开发；年轻团队常常缺乏资金支持，靠个人积蓄或兼职付账单，投入于是只能靠热情维持，而这不总够用。成员因经济或个人原因离开后，开发倒退，本已复杂的项目看起来像不可能完成的任务。在一次危机会议上，剩下的团队决定组建新团队、从新项目重新开始。
在重组工作之后，团队写道，他们对取消 The Swarm 毫不后悔。他们带着新团队与新项目回到正轨，虽然时间上晚了，但带走了他们称为无价的教训。复盘最锋利的一句值得记住：当你意识到项目行不通时，取消它总好过继续往一个你已经知道不会如愿的僵尸项目里投入时间与精力。这不是主张一遇困难就放弃：The Swarm 团队不是在第一次困难时放弃的，而是在设计漂移数月、所需人手与时间大约翻倍、团队本身也分裂之后才停下。取消，是不让漂移再吞掉一支新团队的决定。
能复用的部分
下面的步骤不是 Evolve Games 团队做过的事，复盘里的建议只是起点。它们是改写给你自己项目的，全部只停留在你自己的项目里：没有一条要求你去动线上游戏、别人的团队或你控制不了的项目。这里的范围蔓延不是贪心，也不是懒惰，而是一连串好决定没有累计账本。办法不是停止改进游戏，而是在留住每个改进之前，先让它付出看得见的代价。
周一早上照着做
把你自己项目的核心设计原则写在一页纸上，并在原型里反复验证，直到它们站得住。连不到任何一条原则的改动，不配占位置。
给你自己的项目记一笔持续的范围账。每次加系统或功能，都写下它增加的工作量，再和你实际拥有的人手与时间对照。
把小改动放在一起复查，不要一个一个看。在你自己的项目里每月列出自上次复查以来的全部设计改动，问一句：这还是当初计划的游戏吗？
在批准改动前设一道范围关。如果改动让你自己的项目需要远超现有的人手或月份，就砍掉、缩小，或拿别的东西来换。
在风平浪静时就给你自己的团队准备后备方案。写明如果有人离开，谁来接手每个关键岗位，让离职只是挫折，而不是重启的理由。
提前给你自己的项目定一条取消线。写下在什么条件下你会停下、缩小或重启，这样你是在头脑清醒时决定，而不是在漂移数月之后。