增加功能和删除功能同样重要

上一篇：怎样让战斗从堆数值变成有机制

当《Kibble Street TD》的战斗、数值和机制逐渐稳定下来，最容易出现的错觉是：接下来只要继续增加功能，游戏就会越来越完整。

对人和 AI 的协作来说，这种诱惑尤其强。一个新想法可以很快变成页面结构、规则清单和实现任务，甚至在很短时间内跑起来。开发速度提高以后，真正稀缺的反而不再是“能不能做”，而是判断它是否应该进入当前版本。

第一个准备提交的版本需要的不是最长功能表，而是一条边界清楚、能够完整验证的主线。这次整理涉及四种不同决定：给 FORMATION 建好底座但暂停扩充；增加八个一次性初始道具；给可玩关卡设定明确上限；复用战斗设置完成暂停；最后，把一套已经做出来的活动抽取功能整套删除。

它们看起来方向相反，实际都在回答同一个问题：这个功能是否让当前版本更集中、更可靠？

FORMATION：先把门建好，不急着填满房间

FORMATION 是一个很典型的“未来一定有价值，但现在不能假装完成”的功能。《Kibble Street TD》的战斗阵容由坦克、近战、远程和攻城四种职责组成。页面已经能够展示当前阵容，底层也能按职责读取当前单位、查找候选单位、保存选择并通知其他系统刷新。

但当前每个职责只有一个正式单位，因此页面不会提供一个看似可点、实际没有内容的替代选择。候选位只展示空状态，不显示虚构属性，也不能保存。未来新增单位时，它还必须同时满足职责匹配、身份唯一，以及猫狗双方待机、移动、攻击、死亡、胜利和眩晕六种动画齐全等条件。

这意味着我们完成的是“接入新单位的合同”，不是先画几个头像把页面填满。底座现在就能暴露数据和资源缺口；候选单位的设计与制作则留给后续迭代。暂停不是放弃，而是把未完成准确地停在边界上。

小功能也要有明确的生命周期

与 FORMATION 相反，八个初始道具适合直接进入当前版本。五个用于战斗中的临场操作，三个用于开战前准备。玩家第一次选择阵营时，每种道具获得一个，可以在早期关卡亲自试过它们的效果。

这次增加刻意保持得很小：初始 KIBBLE 和 CANS 仍然都是零；道具只在首次阵营选择的事务中发放，不做每日补领，不再为它单独增加签到或新手奖励页面。如果保存失败，阵营和道具库存一起回到选择前的状态，不会留下“阵营已经选了，道具却没拿到”的半成品存档。

它解决的是体验入口，而不是建立新的奖励循环。玩家获得一次试用机会，游戏则不需要为这八个物品再背负一套长期运营规则。

发布上限也是一种功能

范围控制不能只写在计划里，还要成为游戏实际执行的规则。《Kibble Street TD》当前把可玩关卡上限设为 100：首页到达上限后不再允许进入下一关；战斗入口拒绝超出范围或跳关；结算也不能提交范围外的通关结果；第 100 关胜利后不再出现 NEXT，只保留居中的 HOME。

如果只隐藏一个按钮，旧存档、异常路由或测试入口仍可能把玩家送进边界之外。把同一个上限放在展示、启动和结算三处检查，才算真正定义了“这个版本到哪里结束”。

这不是宣称后续内容不存在，而是把已承诺验证的范围与继续迭代的空间分开。版本边界越明确，测试结果越可信，也越容易判断新内容应该进入当前提交，还是留到下一次更新。

暂停不需要新系统，但必须停完整

暂停看起来只是一个按钮，实际涉及两条时间线。《Kibble Street TD》没有再造一个独立暂停页面，而是复用战斗设置：打开时暂停战斗模拟，同时冻结角色动画和特效，并锁住战斗输入。

关闭设置时，只有原本正在进行的战斗才恢复；重新开始和返回首页都不会先把战斗偷偷跑起来。重新开始会记录本局放弃并重新载入当前关卡，返回首页则先保存已经消耗的战斗道具，再退出战场。

这里的取舍不是少做一个页面，而是复用已有入口，把必须处理的状态补齐。功能数量没有增加太多，但玩家得到的是可预测的暂停、继续、重开和退出行为。

已经做出来的功能，也可以整套删除

最难的决定来自一套活动抽取页。它曾经拥有环形奖励列表、单次与十次抽取、每日免费次数、广告次数、付费消耗、连乘奖励和抽取动画。换句话说，它不是停留在草图上的想法，而是一条已经覆盖页面、规则、资源和存档的支线。

重新把它放回第一个提交版本的目标中评估，这套功能会建立一条与“战斗—结算—升级—继续挑战”并行的资源循环，还会带来每日状态、广告触发、概率说明和额外验收。它能运行，并不等于它在当前版本里承担了不可替代的作用。

最终的处理不是把首页入口藏起来，而是同步移除路由、活动页面、抽取规则、奖励配置、存档字段、广告点位、统计事件、图片资源和专项检查。这样做的成本比保留一段无人进入的代码更高，却让版本不再背负一套无法完整解释和验证的系统。

删除功能最怕留下“幽灵”：入口没了，旧存档还在；页面删了，预加载仍然寻找资源；广告点位不再使用，统计却继续等待事件。真正的删除也需要验收标准，而且往往比新增一个按钮更考验对依赖关系的理解。

四种决定，比“做或不做”更实用

这轮整理之后，我们没有再用一个简单的待办列表管理功能，而是把决定分成四类：能够用很小边界解决当前问题的，直接完成；未来确定需要、当前内容不足的，只建立可靠底座；属于版本范围的，设置明确上限；与主线竞争注意力且没有当前必要性的，整套删除。

判断时会反复追问几件事：它改变了玩家哪一步体验？它是否形成新的资源或状态循环？失败以后能不能恢复？需要同时验证多少入口？如果现在删除，主线是否仍然完整？如果答案只是“看起来更丰富”，通常还不足以让它进入第一个提交版本。

人和 AI 分别负责什么

AI 很适合加速两端的工作。增加功能时，它可以展开状态、异常路径和验证清单；删除功能时，它可以扫描路由、配置、存档、资源、广告和统计之间的引用，避免只删掉最显眼的一层。对于 FORMATION 这类底座，它也能把未来接入必须满足的条件写成当前就会失败的检查。

但 AI 不能替项目决定什么值得保留。人负责定义当前版本的目标，判断一条支线是否稀释核心体验，也负责承认沉没成本：已经做了很多，不是继续保留的理由。AI 可以证明“删干净了”，却不能单独证明“删掉它以后产品更好”。

如果你想开始

把正在做的功能列出来，不要只标“完成”和“未完成”。给每项分别标成：当前必须完成、只做扩展底座、设置发布边界、整套移除。然后为后两类也写验收条件——边界之外从哪里被拦住，删除以后哪些入口和数据必须归零。

再挑一个你最舍不得删的功能，暂时不看已经投入的时间，只问它是否强化了当前版本最重要的循环。这个问题通常比“还能不能再加一点”更接近产品决策。