Back to Details

balance-check

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Phase 1: Identify Balance Domain

阶段1：确定平衡性领域

Determine the balance domain from 
$ARGUMENTS[0]
:
  • Combat → weapon/ability DPS, time-to-kill, damage type interactions
  • Economy → resource faucets/sinks, acquisition rates, item pricing
  • Progression → XP/power curves, dead zones, power spikes
  • Loot → rarity distribution, pity timers, inventory pressure
  • File path given → load that file directly and infer domain from content
If no argument, ask the user which system to check.
从
$ARGUMENTS[0]
中确定平衡性领域：
  • 战斗 → 武器/技能DPS、击杀时间、伤害类型交互
  • 经济 → 资源产出/消耗、获取速率、物品定价
  • 成长 → 经验值/能力曲线、停滞期、能力突增点
  • 战利品 → 稀有度分布、保底机制、背包压力
  • 给定文件路径 → 直接加载该文件并从内容推断领域
如果没有参数，请询问用户要检查哪个系统。

Phase 2: Read Data Files

阶段2：读取数据文件

Read relevant files from 
assets/data/
and 
design/balance/
for the identified domain. Note every file read — they will appear in the Data Sources section of the report.
从
assets/data/
和
design/balance/
读取与已确定领域相关的文件。 记录所有读取的文件——它们将出现在报告的“数据源”部分。

Phase 3: Read Design Document

阶段3：读取设计文档

Read the GDD for the system from 
design/gdd/
to understand intended design targets, tuning knobs, and expected value ranges. This is the baseline for "correct" behaviour.
从
design/gdd/
读取该系统的GDD，以了解预期的设计目标、 可调参数和预期值范围。这是判断“正确”行为的基准。

Phase 4: Perform Analysis

阶段4：执行分析

Run domain-specific checks:
Combat balance:
  • Calculate DPS for all weapons/abilities at each power tier
  • Check time-to-kill at each tier
  • Identify any options that dominate all others (strictly better)
  • Check if defensive options can create unkillable states
  • Verify damage type/resistance interactions are balanced
Economy balance:
  • Map all resource faucets and sinks with flow rates
  • Project resource accumulation over time
  • Check for infinite resource loops
  • Verify gold sinks scale with gold generation
  • Check if any items are never worth purchasing
Progression balance:
  • Plot the XP curve and power curve
  • Check for dead zones (no meaningful progression for too long)
  • Check for power spikes (sudden jumps in capability)
  • Verify content gates align with expected player power
  • Check if skip/grind strategies break intended pacing
Loot balance:
  • Calculate expected time to acquire each rarity tier
  • Check pity timer math
  • Verify no loot is strictly useless at any stage
  • Check inventory pressure vs acquisition rate
运行特定领域的检查：
战斗平衡性：
  • 计算所有武器/技能在每个能力等级下的DPS
  • 检查每个等级的击杀时间
  • 识别任何全面占优的选项（严格意义上更强）
  • 检查防御选项是否会导致无法被击杀的状态
  • 验证伤害类型/抗性交互是否平衡
经济平衡性：
  • 绘制所有资源产出和消耗的流量图
  • 预测资源随时间的积累情况
  • 检查是否存在无限资源循环
  • 验证金币消耗是否与金币产出成比例
  • 检查是否存在永远不值得购买的物品
成长平衡性：
  • 绘制经验值曲线和能力曲线
  • 检查停滞期（过长时间无有意义的成长）
  • 检查能力突增点（能力突然大幅提升）
  • 验证内容解锁门槛与预期玩家能力匹配
  • 检查跳过/刷怪策略是否破坏了预期节奏
战利品平衡性：
  • 计算获取每个稀有度等级物品的预期时间
  • 检查保底机制的计算逻辑
  • 验证任何阶段都没有完全无用的战利品
  • 检查背包压力与获取速率的关系

Phase 5: Output the Analysis

阶段5：输出分析结果

undefined
undefined

Balance Check: [System Name]

平衡性检查：[系统名称]

Data Sources Analyzed

已分析的数据源

  • [List of files read]
  • [读取的文件列表]

Health Summary: [HEALTHY / CONCERNS / CRITICAL ISSUES]

健康状况总结：[健康 / 存在隐患 / 严重问题]

Outliers Detected

检测到的异常值

Item/ValueExpected RangeActualIssue
物品/数值预期范围实际值问题

Degenerate Strategies Found

发现的退化策略

  • [Strategy description and why it is problematic]
  • [策略描述及问题原因]

Progression Analysis

成长曲线分析

[Graph description or table showing progression curve health]
[图表描述或表格，展示成长曲线的健康状况]

Recommendations

建议方案

PriorityIssueSuggested FixImpact
优先级问题建议修复方式影响

Values That Need Attention

需要关注的数值

[Specific values with suggested adjustments and rationale]

---
[具体数值，附带建议调整方案及理由]

---

Phase 6: Fix & Verify Cycle

阶段6：修复与验证循环

After presenting the report, ask:
"Would you like to fix any of these balance issues now?"
If yes:
  • Ask which issue to address first (refer to the Recommendations table by priority row)
  • Guide the user to update the relevant data file in 
    assets/data/
    or formula in 
    design/balance/
  • After each fix, offer to re-run the relevant balance checks to verify no new outliers were introduced
  • If the fix changes a tuning knob defined in a GDD or referenced by an ADR, remind the user:
    "This value is defined in a design document. Run 
    /propagate-design-change [path]
    on the affected GDD to find downstream impacts before committing."
If no:
  • Summarize open issues and suggest saving the report to 
    design/balance/balance-check-[system]-[date].md
    for later
End with:
"Re-run 
/balance-check
after fixes to verify."
在展示报告后，询问：
"是否需要立即修复这些平衡性问题？"
如果用户选择是：
  • 询问首先处理哪个问题（参考建议表格中的优先级行）
  • 引导用户更新
    assets/data/
    中的相关数据文件或
    design/balance/
    中的公式
  • 每次修复后，主动提出重新运行相关平衡性检查，验证是否引入新的异常值
  • 如果修改的是GDD中定义的可调参数或ADR引用的参数，提醒用户：
    "该数值在设计文档中有定义。提交修改前，请运行
    /propagate-design-change [path]
    命令，检查受影响的GDD的下游影响。"
如果用户选择否：
  • 总结未解决的问题，并建议将报告保存到
    design/balance/balance-check-[system]-[date].md
    以便后续处理
最后结束时说：
"修复完成后，请重新运行
/balance-check
进行验证。"