godot-monte-carlo-balancer

技能链

godot-resource-data-patterns → godot-economy-system →
  (godot-combat-system | godot-rpg-stats | godot-game-loop-waves) →
  godot-monte-carlo-balancer → godot-testing-patterns → godot-builder

铁律：从源码提取，零配置

模拟器中不得手动复制数字。启动时解析资源／源码，确保下一次运行能反映设计师的修改。

抽象模型（阶段 0 必须执行）

抽象	含义	缺失时
局次	有限次数的尝试	—
威胁	失败压力	删除
防御／能动性	玩家可采取的手段	删除
故障	注意力消耗	删除
资源	可消耗的流量	删除
局内经济	局次内支出	删除
元经济	商店／解锁／声望	删除
评级	星级／排名／时间／分数	删除

编写 BALANCE_PLAN.md。只模拟已映射的行。

渐进式披露

必须：在实施该阶段之前，先阅读链接的参考文档。

不要加载：

• example-lane-defense.md — 除非阶段 0 映射到车道防御／轮班 TD
• 06-genre-adaptation.md — 除非类型 ≠ 默认 PvE 胜率区间局次
• 07-godot-calibration.md — 仅在开始校准或阶段 0 未豁免物理／AI 时加载（豁免 = 完全公式化的纯数学游戏，并已记录在 BALANCE_PLAN.md 中）

阶段 0 — 审核 → references/00-game-audit.md

类型、胜利／失败、模式、目录、影响关系图、经济、风格 + 主要指标、提取计划。与设计师确认。

阶段 1 — 提取 → references/01-source-extraction.md

资源优先决策树；任何模拟前先执行 inspect。

阶段 2 — 模拟 → references/02-simulation-engine.md

行为型 PlayStyle × InputModel（鼠标／触屏／手柄），移动端使用 SessionModel，使用带种子的 SmallRng，通过 rayon 并行处理独立任务。

阶段 3 — 分析 → references/03-analysis-reporting.md

Wilson／bootstrap 置信区间判定；次要能动性检查；稳定的 JSON。

阶段 4 — 经济 → references/04-economy-retention.md

生涯、资源农场、利息曲线、奖励节奏检查点。

阶段 5 — 调优 → references/05-tuning-generation.md

按区间评分的暴力搜索；项目采用资源优先时，生成 .tres。

阶段 6 — 类型 → references/06-genre-adaptation.md

指标覆盖 + 领域技能链。

阶段 7 — 校准 → references/07-godot-calibration.md

全面矩阵签核前，将 3–5 个黄金单元与无头 Godot 进行比对（除非已豁免）。

捆绑资源

复制后的规范布局：

tools/
  balance_lab.ps1          # from launcher.ps1
  balance_lab.sh           # from launcher.sh
  balance_lab/
    Cargo.toml
    src/main.rs            # clap stubs — expand per Phase 0

scripts/balance-lab-template/

将 Cargo.toml + src/ 复制到 tools/balance_lab/。将启动器放在 tools/balance_lab.ps1 / tools/balance_lab.sh（与 crate 目录同级）。

scripts/compare_balance_snapshots.py

支持 CI 的快照差异比较工具。

references/json-schema.md

稳定的 --json 字段约定。

CLI 约定

balance-lab inspect
balance-lab simulate --level 3 --style average --runs 1000
balance-lab career --style casual --runs 200
balance-lab mode <key> --runs 500
balance-lab bruteforce --level 4 ...
balance-lab gen-level ...
balance-lab calibrate --cells golden.json
balance-lab --json <any command>
balance-lab --seed 42 <any command>

目标区间（默认；Phase 0 可覆盖）

区间按每个 style × input_model 单元格定义。默认输入模型为 mouse。

Style	Input	胜率目标	低于 →	高于 →
afk	mouse	5% – 55%	太难	太简单
casual	mouse	55% – 90%	太难	太简单
average	mouse	70% – 95%	太难	太简单
pro	mouse	90% – 100%	太难	—
afk	touch	5% – 55%	太难	太简单
casual	touch	55% – 90%	太难	太简单
average	touch	65% – 92%	太难	太简单
pro	touch	85% – 100%	太难	—

只有每个模拟的 style × input_model 单元格都落在其区间内，关卡才算 OK。难度必须来自关卡曲线，而不是单纯惩罚输入速度。

平台规则：如果游戏会在移动设备上发布，矩阵 MUST 包含 touch 输入模型。鼠标输入下 OK、但 touch 输入下太难的关卡，仍然算太难。

CI 判定规则（唯一事实来源）

模式	每个单元格的运行次数	OK 规则
搜索 / 开发中	100–300	95% 置信区间与区间有重叠；否则为太难 / 太简单 / 无法判定
签核 / DoD / 快照	≥1000	每个 style × 已发布输入模型的 95% 置信区间都完全包含于区间内

格斗 / 教育 / 放置类游戏通常会替换胜率指标——在 Phase 0 设置主要指标。

绝对不要做

数据与提取

• 绝不要硬编码游戏数值或跳过现有的 Resources / .tres——手动复制会逐渐失效，导致结论错误；在 Resource 项目中使用正则表达式会与数据层冲突。优先使用 Resource；正则表达式仅用于内联公式系数。在首次 simulate 前，先在 inspect 中标记每个 (default!)。
• 绝不要跳过嵌入式公式——提取系数；在 sim 中只重新实现一次。形状发生变化时，必须让正则表达式明确报错。

模拟保真度

• 绝不要只模拟最优玩法——仅 pro 通过的方案会发布出无法游玩的底线体验；AFK / casual 失败才是玩家会切身感受到的问题。
• 绝不要把人类建模为瞬时响应——零延迟 Agent 能通过真实玩家会错过的卡顿 / 故障窗口；难度会退化为纯粹的反应速度门槛。
• 绝不要将桌面端的反应 / 点击参数用于移动端——touch 的每秒点击次数更低、漏触概率更高，还会受到遮挡；按鼠标数据平衡会导致移动端游戏无法游玩。
• 绝不要假设移动端会话不会中断——模拟中断（通知、切换应用）和会话时长上限；需要连续专注 12 分钟的关卡不适合该平台。
• 绝不要让依赖精确操作的机制未经 touch 测试——任何需要精准 / 快速指向的机制，都必须在签核前用 touch 精度模型进行模拟。
• 绝不要跳过元游戏——省略商店 / 升级 / 模式 / 重玩，会导致“平衡”的会话背后存在失衡的成长体验。
• 绝不要使用无种子或通过 HashMap 生成哈希的种子路径——默认哈希器会按进程随机化，导致不同机器 / rayon 调度产生错误的 CI 差异；使用 seed_for + 稳定哈希；对确定性进行单元测试。
• 绝不要在 rayon 任务间共享 RunState/RNG——相互干扰会伪装成平衡噪声，并破坏可复现性。
• 绝不要根据未经校准的物理 / AI 模型宣称数学上的平衡——必须通过 Phase 7 或记录豁免；抽象 DPS ≠ Godot 碰撞。

平衡性评判

• 绝不要只看单一平均值——直方图、停机时间、按类型统计的失败情况、资源比例会掩盖五五开的运气局与技能断层。
• 绝不要只根据点估计下结论——CI 法则（搜索阶段重叠／签核 ⊆）；搜索阶段 ≥300，签核阶段 ≥1000。
• 绝不要在未检查资源流的情况下宣称可通关——同时检查压力和收入与消耗的关系（经典的资源匮乏却“可打赢”问题）。
• 绝不要将难度和平衡经济分开处理——通关时间会改变每分钟货币收益；调整难度后要重新运行职业生涯。
• 绝不要在未重新检查商店可达性的情况下过度削弱刷资源方式——漏洞修补后经常会导致成长阶梯无法继续。
• 绝不要只用从挂机玩家到职业玩家的 PvE 区间来平衡 PvP——要使用对局／MMR 指标。

调优与维护

• 绝不要孤立地调优单次会话——更改后要运行完整矩阵和职业生涯。
• 绝不要接受未经模拟验证的生成内容。
• 绝不要在以 Resource 为主的项目中生成 .gd 工厂——应生成 .tres／Resource 形式。
• 绝不要在游戏源代码更改后缓存 GameData。
• 绝不要让设计师手动编译——使用可自我重建的启动器；过期二进制文件会导致结论过时。
• 绝不要只向标准输出提供 Agent 信息——使用 --json 和 game_data_hash。

黄金路径（首次接入）

1. 阶段 0 → BALANCE_PLAN.md，并由设计师锁定区间／指标。
2. 阶段 1 提取 → inspect → 如果出现意外的 (default!)，就停止并修复提取（参见 example-lane-defense.md 中的问题示例）。
3. 阶段 2–3：在一个单元格上运行 300 次（搜索阶段重叠）→ 完整矩阵 → 在 1000 次时验证 SignOff ⊆。
4. 阶段 4 职业生涯 → 刷资源／商店标记 → 阶段 7 校准（除非已豁免）→ JSON 快照。

完成定义

1. 已验证 inspect；没有意外的 (default!)。
2. 种子确定性测试通过。
3. 阶段 7 通过（或记录阶段 0 的豁免）。
4. 完整矩阵（所有关卡 × 所有风格 × 所有已发布的输入模型，每个单元格运行 ≥1000 次）——每个单元格都满足 CI ⊆ 区间（签核法则）。
5. 模式 + 职业生涯：每分钟货币收益正常；没有占主导地位的刷资源方式；商店可达。
6. 兴趣曲线 + 奖励节奏检查点通过。
7. 已提交用于 CI 的回归 JSON 快照。

参考资料

渐进式披露：仅在研究特定 API 时打开官方文档链接； 将工作路由到相关领域时再加载相关技能——不要预先加载整套技能。

官方文档

• Resources — 提取 GameData 的首选来源（使用 .tres，而非正则表达式批处理）。
• JSON — 生成和解析快照／CI 平衡 JSON。
• FileAccess — 读取导出的平衡数据转储和黄金单元格。
• ResourceLoader — 为提取／校准加载设计师创建的 Resources。
• 命令行教程 — 使用无头 Godot 运行阶段 7 校准。
• 单元测试 — 针对种子和提取流程的确定性测试。
• OS — 实验室启动器的进程／环境钩子。
• ProjectSettings — CI 平衡任务的路径和功能标签。
• RandomNumberGenerator — Rust 实验室使用的带种子 RNG 模式。
• SceneTree — 用于黄金单元格校准的无头场景启动。
• Engine — 无头模拟的时间缩放／帧数。
• ConfigFile — 在代码之外可选地覆盖设计师设定的区间。

相关技能

前置条件

• godot-resource-data-patterns — 在提取正则表达式前，优先使用 Resource 构建 GameData。
• godot-testing-patterns — 用于第 7 阶段的无头运行器和黄金单元格。
• godot-builder — 用于校准的 CLI／无头项目脚手架。
• godot-project-foundations — 规范仓库布局，确保提取路径稳定。

互补技能

• godot-economy-system — 职业、资源消耗点和商店可达性输入。
• godot-combat-system — 矩阵模拟的伤害／生命值 Resources。
• godot-rpg-stats — 要提取和调整的曲线与修正项。
• godot-ability-system — 用于风格矩阵的冷却时间／消耗配置。
• godot-game-loop-waves — 作为模拟单元格的波次难度区间。
• godot-inventory-system — 职业模拟中的战利品／经济联动。

下游／使用方

• godot-genre-roguelike — 元进度胜率区间。
• godot-genre-tower-defense — 车道防御风格矩阵（参见示例参考）。
• godot-genre-idle-clicker — 职业／达成里程碑所需时间区间。
• godot-genre-fighting — AFK→职业级 PvE 之外的对战矩阵。

主技能

• godot-master — 平衡实验室的库路由器和镜像模块入口。