Duo Forge 如何在 Coinsweeper 中构建并平衡 70 多个相互作用的强化道具

游戏

Coinsweeper 是一款roguelite游戏，将经典扫雷与风险管理、卡组构筑和赌博机制结合在一起。利用带数字的钻石推断地雷的位置，但目标并不只是清空棋盘——你每翻开一张安全牌，你的金币收益都会成倍增长。决定何时收手兑现、锁定收益，还是冒险一搏争取巨额回报——一旦踩到地雷，你将失去该回合中赢得的一切。

挑战

Coinsweeper上线时包含 70 多种强化道具，涵盖四个功能类别。每个新机制都会与每一个已有机制建立新的关联。在持续发布的同时维持整个系统的一致性，这一挑战很快就超出了逐项调参所能解决的范围。

正如 Duo Forge 所说，“在整个系统范围内保持一致，同时还要交付一款让人感觉打磨到位的游戏，这类规模问题会悄无声息地终结项目。”

Duo Forge 由 Kamil 和 Julian 两兄弟组成，他们常驻德国，从事专业软件开发工作。Coinsweeper 是他们的首款商业发行作品，于 2026 年 4 月上线，获得了大量好评。仅在头两个月，玩家就已经投入了相当可观的游戏时长，其中一位测试者已经累计游玩超过 172 小时。

它的成功在很大程度上归功于团队构建了一个足够庞大的强化系统，让每一局都感觉不同，同时又足够健壮，使两个人就能维护它。为此，他们需要找到在迭代和调试上节省时间的方法，以便把更多精力投入到设计和玩法测试中。

第 1 部分

设计框架，而不是 70 个单独的功能

一个小团队如何防止 70 多个机制变得难以维护？

面对无限的强化道具交互组合，Duo Forge 清楚，如果他们一次只做一个强化道具，Coinsweeper 的机制系统迟早会爆发冲突和错误。

为了提前应对这一点，他们在做出第一个机制之前，就先定义了元层面的类别和交互规则。这四个类别——揭示类机制（Fortune Teller、Lucky Peak）、风险/回报修正类（High Roller、Golden Touch）、经济增益类（Lucky Charm、Coin Magnet），以及保护类机制（Shield、Armor Plating）——为添加新的强化道具并对照系统对其进行评估提供了框架。

这意味着，添加一个新的强化道具可以变成一个分类问题，而不是一次全系统范围的兼容性审计。符合既定类别的机制，应遵循与其他类别预先设定的交互规则。如果它无法清晰地归入某一类别，那么早在它成为维护负担之前，就会被标记为一个设计信号。

“我们很早就对所有内容进行了分类，并制定了各类别之间如何交互的规则。这给了我们一个框架，而不是只能逐个修补问题。”

他们使用 Bezi 帮助在每一个新强化功能构建出来之前，根据现有产品架构对其进行评估。Bezi 能够深入查看项目，包括实际数据文件和代码库，使其能够快速验证并构建符合类别结构的新功能。这大幅缩短了从想法到实现所需的时间，让团队能够快速构建强化功能，同时不会在未来增加更多缺陷修复工作。第 2 节

调试隐藏的系统交互

如何高效地找出仅在多个系统重叠时才出现的问题？

不过，Bug 终究无法避免。在 Coinsweeper 中，最棘手的 Bug 隐藏在强化道具组合与交互链里：Duo Forge 需要应对机制之间的执行顺序冲突——这些机制单独运行时一切正常，但在边界条件下一同作用时，行为就变得出人意料。

发现并诊断这些问题尤其困难，因为这需要同时把握多个相互关联系统的完整上下文。对于大型团队来说，这代价高昂；而对于一支想要按时发布作品的两人团队来说，这几乎不可能做到。

Crystal x Quick Reveal 这一组合交互正是如此。

Crystal 是一种永久性的史诗级强化道具，首次点击时可安全揭示 3x3 网格区域，并自动拆除该区域内的地雷。Quick Reveal 是一种消耗性道具，可手动揭示 5 张随机卡牌，并拆除其命中的任何地雷。理论上，它们的功能完全不同，但在实际运行中，它们共用底层的拆雷逻辑。

这造成了一个冲突：如果玩家在使用 Crystal 之前先激活了 Quick Reveal，Crystal 就会完全失效。3x3 安全区域根本不会触发。

问题在于，这两个强化道具在单独运行时以及所有其他交互中都表现完美。这是一个情境性、涌现式的 bug，无法在试玩测试中被可靠发现，而且会对玩家造成极大干扰。他们刚花了 160,000 枚金币购买一个史诗级强化道具，它却悄无声息地失效了。没有反馈，没有提示，只有一个在最糟糕的时刻失效的能力。

它直到 Bezi 在完善 Crystal 的实现时发现并标记了这一冲突才被找到。由于 Bezi 同时掌握所有系统的完整上下文，它识别出两个强化道具都会写入同一个 defuse 状态，而激活顺序导致 Crystal 没有任何有效内容可供操作。

“追查为什么两个强化道具会失效，或者弄清某个特定棋盘状态为何表现异常，通常意味着要在代码里翻找好几个小时。Bezi 掌握着所有系统的完整上下文以及期望达到的状态，因此它能立刻识别并精确定位问题所在。”

修复方法很直接：让 Crystal 的逻辑不再依赖 Quick Reveal 留下的任何状态，这样 Crystal 在激活时总是重新评估棋盘，而不是继承一个已损坏的状态。问题解决后，两个强化道具都能无缝运作。玩家可以把 Quick Reveal 接续到 Crystal 上，而不会损失任何功能。

一个可能对玩家体验造成难以估量的损害、并耗费难以计数的小时才能解决的 bug，在午饭前就被找到并修复了。

这只有在系统级上下文的支持下才可行。游戏中每增加一条交互链，可能的冲突状态数量就会成倍增长。如果没有一个能同时承载并基于所有这些上下文采取行动的工具，你做的就不是系统性调试，而是在靠运气。

“如果没有 Bezi，开发时间很可能要多出 6 个月以上。说实话，那段时间会花在找 bug、实现工作以及追踪系统之间的交互上。就是那些不出彩的活儿。Bezi 把这一切压缩了，于是我们能花时间去做出真正的游戏设计决策。”

第 3 节

测试的是组合，而不是组件

当几十种机制可以同时出现时，你究竟在平衡什么？

在 roguelite 游戏中，玩家会在一局游戏过程中不断积累强化道具。平衡的单位并不是单个机制，而是该机制在活态组合中所起的作用；协同链条、经济循环、会在多个回合中不断累积的信息优势，以及只有当三四个特定机制同时激活时才会涌现的互动。

孤立地测试每个强化道具，只能告诉你这个组件是否运转正常，却无法告诉你整个系统玩起来是什么感觉。

“在平衡性真正打磨到位之前，我们花了很长时间。说实话，Bezi 在这方面带来了颠覆性改变。它帮助我们找出需要测试哪些强化道具之间的互动，并比我们手动操作快得多地将其打磨顺畅。对于一支两人团队来说，能有这样的支持意义重大。没有它，我们真的不可能迭代得这么快。”

Duo Forge 表示，最重要的平衡性工作发生在组合层面。在一局游戏的中期尤其如此，未经校准的组合可能会悄然破坏玩家的节奏。由于没有任何单一强化道具能单独造成这种影响，如果不测试每个部分如何与其他所有部分互动，就不可能评估平衡性。

其中的挑战在于，在迭代新机制时要把所有可能的组合都记在脑中，同时又不拖慢开发进度。正是在这里，他们发现 Bezi 带来了颠覆性改变。

Bezi 能够深入掌握游戏架构的上下文以及项目外信息，这意味着它可以快速迭代某个机制，使其既与游戏中已有的内容相契合，也符合开发方向。当实现速度很快并且服务于更宏大的愿景时，交互设计判断就成了制约因素——本来就该如此。

第 4 节

平衡感知强度，而不仅仅是期望值

为什么有些强化道具感觉上比实际更强？

事实证明，依据期望值来调整强化道具是必要的，但还远远不够。团队惊讶地发现，某个机制在统计数据上的表现与玩家对它的实际感受之间始终存在差距。那些能给玩家带来更多自主权或结果更清晰的机制，比统计上更优、却在后台悄然发挥作用的机制更受玩家青睐。

“我们最大的收获是：玩家不是理性的计算器。一件事给人的感觉与它在数学上实际起到的作用完全脱节。对自主权的主观感知，与实际的自主权同样重要。”

这并不是一句轻描淡写的观察，而是有着具体的设计含义。防御机制、经济增益机制和揭示机制不仅在运作方式上有所不同，在传达信息的方式上也各不相同。一个强化道具的感知价值，部分取决于其效果触发时的易读程度。

Duo Forge 明白，这些失衡无法在电子表格里解决。它们因人而异，只能通过与人合作来解决。于是他们招募了 10 位朋友协助试玩，并利用每一轮反馈，基于真实的玩家心理来调整强化道具与互动机制。

这一过程揭示了 Jackpot 强化道具的一个出人意料的情况。它看起来非常简单：奖励金币每轮都会累积到一个奖池中，在存活五轮后，奖池就会派发奖励。从纸面上看，它像是一种不起眼、被动的奖励，玩家不会对它产生依恋。

无法预料的是，当 Jackpot 与其他强化道具组合时，它所带来的清晰而切实的影响，竟让测试玩家立刻被它吸引。在这些情况下，它对玩家的价值呈非线性增长，并带来了大额派发。结果，玩家因为 Jackpot 在实践中带来的明显效果——远高于预期价值——而蜂拥选择它。它成了协同流派构筑的首选，玩家忽略了其他选项。

通过试玩者的反馈和观察，Duo Forge 发现了一个紧迫的需求。他们需要对 Jackpot 进行若干调整，使其提供相似的价值，同时不蚕食其他协同强化道具。而且他们需要快速完成这些调整。

“我们没有孤立地调整 Jackpot，而是使用 Bezi 的 Plan Mode 梳理出所有可能直接或间接与 Jackpot 交互或对其产生影响的强化道具。这让我们获得了无法手工整理出的依赖关系总览。更重要的是，它让我们能够快速迭代，同时避免更新一处却悄悄破坏另外三处的典型陷阱。”

由于 Duo 能够更快地迭代，且下游中断更少，他们得以在下一次试玩测试之前重做该机制，从而确保玩家有充足时间测试其连锁影响，并在发布前确认手感合适。

最终状态是一个平衡点；Jackpot 成了一个有意义且令人兴奋的选择，而又没有主宰每一种协同构筑。玩家感受到了高额回报带来的满足感，感知强度得以保留，但期望值被降低到与其他强化道具相匹配。

意外之喜可以在试玩测试中被发现，并在下周进行迭代和重新测试——而不是在数周的实现工作之后。更快的迭代和实现将重点转向了测试，而测试本就该是重点。技术要点

1. 先建类别，再做功能。

在实现单个能力提升之前，先定义各种机制类型之间如何相互作用。这样每个新增内容就变成一个分类问题，而不是一次完整的兼容性审查。

2. 平衡组合，而非组件。

在机制可以叠加的系统中，平衡的单位是交互，而不是孤立的机制。测试需要反映系统在真实运行条件下共同表现出的行为。

3. 调试链路，而非节点。

相互连接的系统中的涌现性缺陷很少源自单一机制。追踪完整的交互序列，而不是孤立地检查每个能力提升，才能真正暴露出原因。

4. 在衡量数值强度的同时，也衡量玩家感知到的能动性。

数学上的平衡与实际感受到的强度经常出现分歧。一个强化道具在实践中的有效性，部分取决于其效果的可观察程度。两者都需要主动测试，而在没有真实玩家在场的情况下，只有其中一项会出现在期望值数据中。

游戏

Coinsweeper 是一款 roguelite 游戏，它将经典 Minesweeper 与风险管理、牌组构建和赌博机制结合在一起。用带数字的菱形推断地雷位置，但你不只是清空棋盘——每翻开一张安全牌，你的金币赢额都会呈指数级增长。决定何时兑现并锁定收益，还是冒险一搏以求巨额回报——一旦踩到地雷，你就会失去该回合已赢得的全部东西。

挑战

Coinsweeper 发布时包含 70 多个强化道具，横跨四个功能类别。每个新机制都会与每一个现有机制产生新的关系。在持续发布的同时维持整个系统的一致性，这一挑战很快就超出了单个调优所能解决的范围。

正如 Duo Forge 所说，“在仍然要发布一款感觉精致完善的游戏的同时，维持整个系统的一致性，正是那种会悄无声息地终结项目的范围问题。”