《鼓令·无名》开发日志 02

修改于10/204 浏览

《鼓令·无名》开发日志 02：同一份代码，跑出两个不同的战场

这周遇到一件事，我想先说它。

同一份代码、同一个随机种子、同一个关卡，跑十次——有六次是一个结果，四次是另一个。

一个战场，两个结局。而差别不来自任何设计，来自一张表被遍历的顺序。

【本期进展】

先说做完的：

· 战役骨架通了。3 章 × 10 个节点，第一章可以带着事件从头走到尾——战斗、事件、商店、营帐的位置都在。 · 卡池盘完了。我们按"每一张卡都需要哪种底层效果"把整套卡过了一遍，最后定在 106 张。 · 意图系统做完了。敌方单位每刻"想干什么"（进攻/推进/后撤/驻守）现在可以被看见——但严格限制在"我方视野内的敌人"，看不见的敌人你看不见它想干什么。 · 三个 Boss 的特殊机制补完了。1-10 的将旗光环与浮桥结构值、2-10 的三栅分治与山火、3-10 的三面幢旗。 · 500 个单位同屏，每刻结算 P50 = 33 毫秒。达标。

【一个问题：11 个"写了但没被用过"的地方】

这十几天最耗时间的不是写新东西，是查旧东西。

我列一类问题的名字：代码写了、函数在、参数填了——但它从来没有被用过。

比如有 20 个兵种，每个都有自己该有的视野距离。而"视野"这个字段从第一天就存进去了，却没有任何一行代码去读它——所有兵种实际上都在用同一个默认值。于是"轻骑能在 12 米外发起冲锋"这件事，从第一天到现在，从来没有发生过。

这类问题一共找到 11 个。它们有个共同特征：

不报错、不崩溃、不失败。只是让结果"少变一点"。

所以它们可以活很久——久到你以为那个机制已经工作了。

【而"顺序"这件事，比我想的更根本】

回到开头那个两个结局的问题。

原因是我用了一张以"对象"为键的表来记录本刻要结算的效果，而遍历这种表的顺序，在不同进程里是不一样的。

这件事本身没什么。问题在于：结算顺序是有意义的。

一个单位先被结算、还是后被结算，会改变它倒下时周围人看到的是"倒了一个"还是"倒了两个"——而那直接改变附近的士气统计。

所以我们拿到了两个不同的战场。

而这个坑，我们其实踩过一次——更早的时候，是另一张表、另一种键。当时我修的是"那一处"。而这次我明白了：顺序不稳定不是某个 bug，是这门语言的一个性质。所以修一处没用，它会在别处回来。

于是我把全仓所有"遍历顺序会影响结果"的地方都扫了一遍，一共 15 处，其中 2 处真的有语义，13 处本来安全——而"本来安全"的每一处都写了理由。

因为"这里无所谓"这句话，就是下一次出事的种子。

【一个我没想到的发现：它自己停下来了】

说回游戏本身。

我们给 3-10 的 Boss 做了"三幢连环"：三面旗各自撑起本幢的士气下限，玩家要拆旗才能推进。测下来，只拆一面或两面没有用，必须三面都拆——那是设计里"连环"两个字的字面意思。

而测试里出现了一个我没预料到的数字。

在某一组条件下，敌方的崩溃程度在第 23 刻冲到峰值 26.9%，然后回落到了 26.1%。

它自己停下来了。

而这个"自止"，是我们最早校准的那套士气规则的核心——恐慌不会无限传染，它会传染到某个程度然后自己退下去。这套规则我们前后调了十几轮，而这是第一次在真实关卡里看到它在工作。

测出来的那一刻，比任何一张概念图都让我觉得这个东西是对的。

【问题与风险】

Boss 难度整体偏软。两个 Boss 在"不出任何牌"的情况下就能赢。查下来根因是敌方初始士气——设计里它该随关卡序号上升（50 + 1.5 × 序号），而实现里所有关卡都用了同一个固定值。改掉之后，2-10 直接翻转，1-10 的余量减半。一行字的问题，拖了十几轮。
卡池只实现了约 40 / 106 张。剩下的 66 张要分批做，其中还有 12 张"秘策"（每战只能用一次，且是唯一允许影响全局的卡）。
性能撞到平台天花板。 500 单位的视野查询是 O(n²)，而现在用的引擎没有更底层的加速接口。33 毫秒是当前技术栈下能做到的水平。如果真机上观感不能接受，最后的办法是把最终关的编成从 500 降到 400。
商店和营帐还是空的。走一章会有"跳过"的感觉。
军械、身份、存档、引导——都还没开始。

【下期计划】