implementing-gameplay-invariants

实现玩法不变量

目的

将设计意图转化为具体的实现约束。此技能介于游戏设计与引擎特定编码之间：它会将“乱按应该不如按时机操作”这类表述，转化为可在任何引擎中应用的不变量、实现模式和验证检查。

即使不使用 designing-mini-games，只要游戏规格中包含风险与奖励方面的描述，却未说明代码将如何落实，也应使用此技能。

如果游戏尚无设计规格，请从 designing-mini-games 开始（其中涵盖单按键和多输入简报）。

适用场景

• 根据设计规格或 README 实现游戏机制。
• 在进行平衡性测试前，根据设计规格检查代码。
• 检查器或模拟显示 mono_dominant、tied 或重复输入占优，而你已明确需要通过哪项代码级不变量来落实设计承诺。
• 设计中提到挂机弱势、仅长按弱势、乱按弱势、安全等待、冷却、连招、计分脉冲、护盾、充能或无敌状态。
• 实现依赖特定引擎，但故障模式属于规则层面，而非 API 层面。

不适用场景

• 纯渲染、资源、UI、音频、构建或引擎 API 工作。
• 规则层面不变量已落实后的数值调整。
• 在核心规则和计分事件尚未明确前进行开放式游戏设计。
• 根据遥测选择平衡性修复策略。如果已出现故障，需要诊断原因或选择平衡模式，请从 evaluating-gameplay-balance 开始；之后再使用此技能，为选定的修复方案添加新的代码级不变量。

必需输入

• 设计规格或 README。
• 必须弱于熟练操作的输入策略：挂机、仅长按、乱按、始终向左／向右、交替连按、安全等待或其他类似策略。
• 预期的熟练操作模式。
• 计分事件、游戏结束条件，以及任何安全／能力状态。
• 项目检查器使用的确定性验证种子或已知初始随机序列。
• 可选的遥测数据或检查器输出。

流程

1. 提取代码中必须成立的每项设计承诺：

   • “空闲状态很弱”
   • “只按住很弱”
   • “疯狂连按很弱”
   • “得分取决于时机”
   • “护盾安全但代价高”
   • “精准操作可在着陆 / 脉冲 / 反射时获得奖励”

2. 将每项承诺改写为不变量：

   • 使用可测试的表述：“两次点击间隔不足 12 帧时，不能得分”，而不是“疯狂连按不好”。
   • 明确适用范围：每次输入、每个目标、每个危险、每次着陆、每段连击、每秒或每单位资源。
   • 明确后果：不得分、进入冷却、暴露、资源消耗、连击重置、瞄准落空或明显的位置代价。
   • 当计分对象可以跨帧或跨输入持续存在时，明确规定其生命周期：生成 / 开始、有效计分窗口、已计分 / 已消耗状态、过期 / 移除，以及新的生命周期是否能再次得分。
   • 对于重复脉冲、反射、范围伤害、护盾或释放计分，尽可能要求验证日志记录每次机会的唯一标识（targetId、pulseId 或等效标识），以便发现重复计分。

3. 在编码前，根据机制是否能从规格中推断，运行针对策略的预检查：

   • 对每种不良策略，注明它应当失败、在安全的情况下超时，还是以封顶分数存活。
   • 如果某种不良策略可以无限期存活，不变量必须限制其得分或使其得不到分；不能以死亡作为弱点。
   • 如果随机出现的首批危险、间隙、生成物或路线会影响存活，请预览项目的确定性验证种子，并确认前 5-10 个结果符合不变量的假设。

4. 如有需要，从 references/invariant-patterns.md 中选择一种实现模式。

5. 检查计分漏洞：

   • 不得按输入直接计分。
   • 不得重复使用同一个脉冲，在没有新危险 / 机会时反复得分。
   • 除非生存本身是主要的精通信号，否则玩家处于安全 / 低技巧状态时不得因生存得分。
   • 不得存在永久安全状态且得分不封顶的情况。
   • 不得存在已计分却长期保留、仍有资格再次得分的对象，除非其生命周期会明确重置。
   • 修复连按问题时，不得只验证总分；如果机制可能对同一对象重复计分，还要比较每个独特机会或目标的得分。

6. 添加或审查实现：

   • 特定引擎的代码应放在引擎技能或项目代码中。
   • 本技能规定必须满足的条件，而不规定具体的渲染方式或 API 调用。

7. 验证：

   • 运行可用的单调策略以及探索型 / 熟练型策略。
   • 在完整的全局比例检查前，优先进行针对不变量的探测：NoInput 得分 / 死亡、HoldOnly 得分 / 死亡、SpamPress 计分事件、实体数量、资源消耗，以及每次机会的得分上限。
   • 对脉冲 / 反射 / 范围伤害修复，记录已接受 / 拒绝的输入、脉冲年龄或冷却状态、目标 / 机会 ID、是否已计分、得分变化，以及活动实体数量上限。
   • 尽可能在编辑前定义探测的通过 / 失败界限，例如：SpamPress 对每个独特目标的得分低于脚本化的熟练循环，HoldOnly 得分限制在指定速率以下，或活动实体数量上限低于固定值。
   • 确认已知的不良策略得分低于熟练玩法。
   • 如果没有模拟器，请编写简短易懂的验证清单，并注明这一缺口。

不变量模板

在规格说明、PR 备注或代码审查中使用此简洁格式：

- Design promise: <prose from spec>
- Implementation invariant: <testable rule>
- Pattern: <pattern ID from references/invariant-patterns.md, e.g. cooldown, per-target-cap, resource-drain>
- Readout: <the persistent on-screen indicator that lets the player act on this rule — or why this rule changes no player decision>
- Precheck: <whether the bad policy dies, survives safely, or must be score-capped>
- Validation: <policy, telemetry, or seeded scenario that should fail if the invariant is broken>

Readout 不是对规则的说明，而是规则的一部分。会改变玩家操作方式却没有显示出来的不变量，与不公平游戏无异——参见下文的“隐形规则”。

常见失败模式

• 纯文本弱点：README 说连续乱按不好，但代码却让每次点击都有机会得分。
• 可重复使用的计分脉冲：着陆、护盾、范围攻击或反射脉冲可能因重复输入而多次得分。
• 安全得分：最安全的状态也能得分或保留倍率。
• 隐藏的测试器补丁：代码对糟糕策略进行特殊处理，而不是创建明确可见的游戏规则。
• 仅修改数值：调整生成频率或分数值，却没有强制执行缺失的不变量。
• 实体无上限：计分对象或危险物体存活时间过长，导致验证缓慢，并造成刷分循环。
• 特定种子下的意外情况：验证种子生成了违反设计假设的早期危险或缺口，问题直到完整运行一遍 GA 后才被发现。
• 不变量冲突：设计要求彼此排斥的不变量（例如“闲置必须死亡”和“生存是唯一的计分方式”）。如果解决冲突需要更改核心体验或舍弃标签关联，请报告该设计无法挽救，并建议提交失败报告。
• 不可见规则：不变量实现正确，通过了所有数值断言，却从未显示在屏幕上。这是最难发现的一类问题，实证来看也是最常见的问题之一——在一个经过测量的项目中，已发布并修复的 9 个 Bug 中有 4 个都是同一类缺陷（控件、过载触发条件和清除条件在模拟中都完全正确，但玩家看不到）。数值断言从原理上无法检测这类问题：模拟本身是正确的。只有要求提供读数并配上截图，才能发现。

验证

满足以下条件时，变更才有效：

• 每项设计承诺至少对应一个实现层面的不变量。
• 每种单调策略都有可见的代价或得分上限。
• 任何能无限存活的单调策略都有得分上限或得分受限规则。
• 每个会改变玩家决策的不变量都有持久显示的读数，而且该读数会在情况恶化之前填充，而不是等到情况已经恶化才发出一次警告。 随着拥挤程度逐渐接近上限的量表能教会玩家采取行动；过载时才触发的警报只是在描述失败。规则和读数应在同一项变更中添加，并为其截图。
• 如果随机生成的初始危险或缺口会决定能否存活，则应检查带种子的早期游戏随机序列。
• 熟练操作有明确的因果途径，可带来更高分数或更长时间的有效存活。
• 可以通过策略比较、遥测数据或具体的手动检查清单来测试实现。

如果无法验证，请报告该不变量虽已明确规定，但尚未验证。

参考资料

• references/invariant-patterns.md — 关于连续乱按、仅按住、闲置、安全等待、脉冲计分、连击和资源状态的可复用模式。