evaluating-gameplay-balance

使用此技能分析游戏是否奖励有技巧的玩法，并提出结构性改进建议。

引擎无关的约定：

• 为单调策略和探索型策略生成可比较的运行结果。
• 定义公共输入架构，以及策略可用的可见状态特征。
• 确保不同运行使用可比较的种子、刻度频率、最长时长、策略定义、搜索预算和聚合逻辑。
• 记录分数、耗时、结束状态，以及死亡、生成、计分、输入和使用行为的遥测数据。使用行为指实际玩法的构成：核心机制在动作和得分中所占的比例、占据了玩法空间的哪些区域，以及每种威胁触发和命中的频率。
• 如果游戏目标不只是存活，则在比较中加入忽略目标的策略：一种通过拖延来持续得分，另一种只求存活、不追求目标。拖延策略得分更高，意味着应检查其上限、代价以及对整局游戏的影响，但这本身并非缺陷。
• 计算 exploratory_ratio = exploratory.best.score / monotonous.max_score。
• 将此比率视为质量检测指标，而非优化目标。
• 除基线策略外，为每种策略声明执行配置和可见状态特征：oracle（允许使用隐藏信息；作为上限）、precise（使用可见状态，具备近乎完美的时机把控和注意力）或 human-limited（使用可见状态，并受 references/simulation-harness.md 中所述的人类限制）。使用 precise 策略计算该比率（基于搜索的运行器也包括在内，除非标记为 oracle）；它用于检测漏洞，而非衡量难度。
• 仅根据 human-limited 运行来设定难度、计时器、节奏和进度目标，并为每条结论标明依据的执行配置。若没有 human-limited 运行，则不得对难度或节奏作出判断，应报告为尚未测量。
• 声称某种策略占优或某种权衡平衡时，必须注明测试所用的执行配置。如果不同执行配置下的排名发生反转，这本身并非平衡缺陷——应报告为取决于技巧，但仍须将体验防护要求应用于每种执行配置下的最佳策略（若 human-limited 配置下的最优策略是原地不动或等待，则属于缺陷）。

非确定性测试框架：

以上约定假定存在带种子的前向模型。有些测试环境无法提供这种模型——例如在按墙上时钟计时的窗口内驱动真实浏览器、无法控制随机数生成器的引擎，或针对实时渲染运行策略比较。首选方案仍是使用种子；只有在确实无法做到时，才使用以下替代方案。跳过这些要求会让人基于噪声得出看似确定的结论：

• 每种策略至少运行 n ≥ 3 次，并报告最小值至最大值的区间，绝不能只报告点估计。长尾分布的一次运行无法证明任何策略的表现。
• 若要声称区间发生了变化，必须满足 n ≥ 5，且新区间与记录的先前区间没有重叠。只要样本与先前区间重叠，就不构成发现，无论解释该现象的机制看起来多么合理。
• 在项目规范中记录认可的区间及已知尾部情况，以便后续运行与历史数据比较，而不是反复重新发现相同的波动范围。如果已知某种策略在一定比例的运行中会接近某个看起来糟糕的数值（例如，“约 20 % 的待机运行会达到技巧型得分的 0.18，这是设计使然，因为场地可能自行收缩”），则应记录并确认该尾部情况，不要每次出现时都重新争论。
• 撤回结论是合理且预期会发生的结果。 如果基于小样本发布的结论未获更大样本支持，就应在原处撤回：若机制确实存在，则予以保留，并说明其影响幅度无法与噪声区分。已观察到的案例：某个区间变化在 n=4 时发布，并附有连贯的因果解释；到 n=6 时撤回，因为它与项目此前已记录两次的波动范围相同。 体验护栏：
• 即使指标有所提升，也要拒绝会降低游玩体验的改动。
• 只对游戏内的因果事件计分；不要因原始输入事实而给分。
• 游戏结束应与危险或世界状态崩溃相关。
• 不要添加只会帮助或妨碍测试 Agent 的隐藏行为。
• 避免仅调整数值、只修复单个分支，以及把增加随机性作为主要解决方案。
• 将亲自游玩记录——游戏会记录时的回放，以及其他情况下的运行摘要——视为校准受人类能力限制的配置的数据。回放是关于游玩时所依据规则的只读证据：规则变更后绝不要重新生成或迁移回放，也绝不要基于玩家尚未体验过的规则重新拟合策略。当报告与模拟结果冲突时，先检查测试框架是否存在缺陷，然后根据报告调整配置、重新运行并记录调整；不要仅凭机器人数据否定报告。分歧也可能朝相反方向出现：表现不如玩家的策略可能决策不佳，也可能受到过严的限制；决定调整哪一方之前，应比较报告与策略的进度和失败原因。请遵循 references/simulation-harness.md 中的 根据游玩报告进行校准。
• 不要使用行为由某个参数定义的策略来调整该参数（例如“计时器高于 80 % 时等待”）；这样测量值会随调参而变化。

工作流：

1. 找出现有的模拟测试框架。如果没有，就先依据测试框架规范设计一个，再评判平衡性。
2. 选择比较协议：
   • 如果支持设定随机种子，就使用相同的确定性种子运行可比较的单调策略和探索型策略。
   • 如果确实无法设定随机种子，就使用上述非确定性分组协议，并保持运行次数、运行时间窗口、策略定义和采样频率可比。
3. 验证报告是否包含运行配置以及死亡、生成、计分、输入和使用情况的遥测数据。
4. 如果遥测数据不完整，应报告缺失项并请求添加埋点或重新运行，而不是仅凭分数评判平衡性。
5. 分析游戏之前，先对非平凡策略进行合理性检查（见 references/simulation-harness.md 中的 模拟玩家合理性检查）。检查失败即表示测试框架存在缺陷：修正策略、重新运行，并报告该缺陷，而不是据此得出结论。这包括上限检查：当强策略的表现不优于受人类能力限制的策略时，应先排除指标已饱和以及游戏没有奖励精准操作这两种可能，再检查是否存在玩家会避免的失误，然后才能断定策略较弱。
6. 分析死亡、生成、计分、输入和使用模式。查看分数比率之前，先将使用情况与设计中声明的核心交互进行比较：比率良好并不代表玩家将时间花在核心机制上。
7. 找出规则或生成逻辑中的根本原因。
8. 至少提出三个候选修复方案，并说明预期影响、风险和复杂度。
9. 实施后，使用相同的策略、预算、汇总方式和比较协议重新测试。确定性运行应保留相同的随机种子；非确定性运行应保留相同的运行次数和采样设置。 项目检查器分诊，在报告包含 ratio.diagnostic 时：

• 在应用以下任何判定之前，先使用独立于最终分数比较的证据检查测试工具的可信度。只有当探索性搜索确实表现出了游戏水平时，这些判定才可信：其最佳分数随着搜索迭代而提升，而不是从一开始就停滞不前；或者其运行过程参与了单调策略从未触及的得分机会和机制。如果这两项信号都不存在，应将结果视为测试工具失效（搜索器未能找到有水平的玩法），而不是设计方面的证据：应转交人工或 LLM 审查，而非触发重新设计或结构性修复。如果报告缺少判断所需的搜索历史或参与度遥测数据，应说明这一缺口并请求添加检测，而不是应用判定。
• mono_dominant：单调策略的得分高于探索性玩法。检查输入和得分遥测数据，确认是否缺少权衡、可重复触发的得分机制、安全得分机制或原始输入奖励。如果当前 README 的不变量未能阻止闲置、仅按住按键或安全等待策略占据优势，这是一个设计问题：应据此报告，让调用方修改 README 并重新实现。否则优先采用代码层面的结构性修复（输入状态、目标、资源、冷却或风险计分）。
• tied：探索性玩法无法显著超越单调基线。除非遥测数据明确显示有一个不公平的单一危险因素同时阻碍了两种策略，否则这是一个设计问题。应将其报告为设计问题，让调用方修改 README 并重新实现；不要尝试对存在根本缺陷的机制进行代码层面的修复。
• marginal：探索性玩法领先，但优势不足。判断能否确定具体的代码层面原因（实现问题），还是计分／权衡结构本身存在缺失（设计问题）。对于实现问题，在调整原始生成数量／速度数值之前，优先考虑基于风险的计分、连击重置原因、计分幅度或更明确的得分机会。

放弃标准：如果解决根本原因需要更改核心体验或舍弃标签关系，或者已经用尽 3 次改进尝试，应报告该设计在框架约束内无法挽救，并建议生成失败报告，而不是强行再次重新设计。不要为了通过关卡而提出在同一 slug 下凭空设计一款新游戏的修复方案。

当此技能在筛选漏斗中运行时——候选项经过批量生成、排序和淘汰，而非修复——不适用失败报告流程：报告诊断结果，并让排序过程淘汰该作品。修复尝试和 3 次尝试上限仅适用于入选后的优胜者。

遥测数据经过汇总或较为稀疏时，先请求或添加范围最小、目标明确的探针，再进行编辑。实用的探针包括：死亡危险因素的 id／类型／持续时间以及玩家输入窗口、生成位置和安全距离、得分原因／目标 id／风险上下文、得分或死亡前后的输入频率、活动实体数量、每个唯一机会的得分、各来源的操作和得分、在游戏空间各区域停留的时间、每种威胁的开火和命中次数，以及场上不存在主要威胁的最长时段。

按需阅读以下参考资料：

• references/simulation-harness.md：设计确定性模拟器、输入策略、执行配置、健全性检查和遥测数据输出器。
• references/log-contract.md：与引擎无关的遥测架构。
• references/improvement-analysis.md：分析视角和报告模板。
• references/balance-patterns.md：结构性平衡模式。
• references/godot-implementation-notes.md：将常见平衡修复转化为 Godot/GDScript 实现。

配套技能

• 对于 Godot 项目，使用 scaffolding-godot-mini-games 设置项目，并使用 running-headless-godot 执行模拟器、测试、日志和导出检查。
• 此技能负责测量、校准和类人策略。何时询问，以及如何处理发现、游戏记录或玩家的提议，都由调用方决定；将游戏过程中非测量类的内容原样返回给调用方。
• 涉及规则的结构性修复属于设计变更，而非数值调优；未经重新审视设计，不要暗中重新调整数值。