game-balance

ゲームバランス — バランス分析ツール

前提条件

• プロジェクト内に docs/mvp-first-draft.md が必要です（最初に game-architect を実行してください）

---

フェーズ 0 — コンテキストの読み込み（サイレント、必須）

以下の順序を厳守して実行してください。

1. docs/mvp-first-draft.md を読み込む
   • 存在しない場合：⛔ Cannot proceed. docs/mvp-first-draft.md not found. Run the game-architect skill first to generate the MVP plan before running a balance analysis. を出力して停止します。
2. ユーザーのメッセージから対象範囲を判断する
   • 対象範囲が指定されていない場合、または「all」の場合：すべてのシステムを分析します（フェーズ 1～4）
   • 「economy」の場合：フェーズ 1 のみ実行します
   • 「difficulty」の場合：フェーズ 2 のみ実行します
   • 「progression」の場合：フェーズ 2 と 3 を実行します
   • 「rewards」の場合：フェーズ 1 と 4 を実行します
3. 対象範囲に応じてスキルを読み込む
   • economy または all → game-economy-design スキルを適用します
   • difficulty、progression、または all → game-design-fundamentals スキルを適用します
   • progression または all → skill-progression-trees スキルを適用します
4. docs/build-registry.md が存在する場合は読み込む
5. docs/quest-registry.md が存在する場合は読み込む（フェーズ 4 で報酬を相互参照するため）

docs/mvp-first-draft.md から以下を抽出します。

• ゲームのジャンルとコアループの説明
• 通貨の種類と経済パラメーター（供給源、消費先、数量）
• 難易度設定と想定するプレイヤーの進行
• 進行システムの詳細（スキルツリー、レベル制限、コスト表）
• 報酬表とスケジュール

フェーズ 1 — 経済の健全性チェック

対象範囲が「difficulty」または「progression」の場合、このフェーズ全体をスキップします。

game-economy-design の「経済健全性指標」表を適用します。各指標について、docs/mvp-first-draft.md から該当する値を見つけます（または「未定義」と記録します）。

指標	目標範囲	計画内の値	状態
1 日あたりの通貨獲得／消費比率	0.8–1.2	[値または「未定義」]	🟢/🟡/🔴
プレイヤーが保有する通貨の中央値	平均購入コストの 2～5 倍	[値または「未定義」]	🟢/🟡/🔴
プレミアム通貨の購入率	アクティブプレイヤーの 2～5%	[値または「未定義」]	🟢/🟡/🔴
初めて意味のある購入をするまでの時間	5～15 分	[値または「未定義」]	🟢/🟡/🔴

状態の凡例：

• 🟢 目標範囲内
• 🟡 範囲外だが改善可能 — 具体的な修正案を提示します
• 🔴 重大な不均衡、または完全に未定義 — 健全なローンチを妨げます

また、スキルで挙げられている以下のアンチパターンも確認します。

• ハイパーインフレーション — 対応する消費先がない無制限の通貨供給源 → 🔴 重大
• ペイ・トゥ・ウィン — ゲームプレイ上の直接的な強さをもたらすプレミアム通貨または IAP → 🔴 重大
• 通貨の混乱 — 明確な差別化がないまま通貨の種類が 3 種類を超える → 🟡 警告
• 停滞した経済 — 通貨が貯まる一方、魅力的な使い道がない → 🟡 警告
• 序盤の過剰な報酬 — 最初の 10 分間に過剰な報酬を与え、その後の報酬の価値を下げる → 🟡 警告
• 悪用可能なループ — 無限の価値を生み出すクラフトまたは取引経路 → 🔴 重大

問題として指摘した各項目について、該当するスキルの原則を引用します。例：[→ game-economy-design: すべての供給源には消費先が必要]

フェーズ 2 — 難易度とフローチャネルの確認

スコープが「economy」または「rewards」の場合、このフェーズ全体を省略してください。

game-design-fundamentals のフローチャネルのフレームワークを適用します（Csikszentmihalyi の原則：挑戦の難易度はスキルに応じて上昇する必要があります）。

mvp-first-draft.md に示された想定難易度曲線を、次の 4 つの進行フェーズに照らして分析します。

フェーズ	期待されるパターン	計画内での記載	評価
序盤	素早いアンロック、ゲームの仕組みのチュートリアル、高い成功率	[from plan]	🟢/🟡/🔴
中盤	意味のある選択肢、分岐する道筋、約 65% の成功率	[from plan]	🟢/🟡/🔴
終盤	熟練度を高めるための最適化、やりがいのある挑戦	[from plan]	🟢/🟡/🔴
エンドゲーム	ソーシャル／競争要素／無限のスケーリング	[from plan]	🟢/🟡/🔴

スキルで示されている次のアンチパターンを確認します。

• 難易度曲線が平坦 — 意味のある難易度の上昇がない → 🔴（プレイヤーはゲームを極めて離脱します）
• 失敗に対する過剰な罰則 — 厳しいペナルティにより、試行錯誤が妨げられる → 🟡
• チュートリアルが本編と分離 — チュートリアルがコアゲームプレイから切り離されているように感じられる → 🟡
• 単一のプレイヤータイプに偏重 — Bartle のタイプのうち 1 つだけに特化した設計 → 🟡
• 退屈の崖 — プレイヤーがゲームをあまりにも早く極めてしまう → 🔴

スキルの getDifficultyMultiplier の式：1 + (playerSuccessRate - targetSuccessRate) * 0.3 — 計画に適応型難易度が考慮されているかどうかを記載します。

問題として指摘した項目ごとに、スキルを引用します：[→ game-design-fundamentals: flow channel — challenge must scale with skill]

フェーズ 3 — 進行コスト曲線の確認

スコープが「economy」、「difficulty」、または「rewards」の場合、このフェーズ全体を省略してください。

skill-progression-trees のコストスケーリングの原則を適用します。

期待される式： cost = baseCost × tier^exponent（exponent は 1.5～2.0 が望ましい）。

計画の進行コストを分析します。

進行システム	計画内のコスト構造	期待される式の適用状況	問題点
[system 1 from plan]	[flat / linear / exponential]	🟢/🟡/🔴	[if flagged]
[system 2 from plan]	...	...	...

スキルで示されている次のアンチパターンを確認します。

• コスト曲線が平坦 — すべてのノード／レベルのコストが同じ → 🟡（収入が増えるにつれて、エンドゲームのノードが簡単に購入できてしまいます）
• リスペックの仕組みがない — プレイヤーが不適切な選択に永久に縛られる → 🟡
• すべてのノードが最初から見える — ツリー全体がすぐに表示され、発見の楽しみが損なわれる → 🟡
• クライアント側でのツリー状態管理 — クライアント側でアンロックを検証する記述が計画にある → 🔴 重大
• 効果のハードコード — データ設定ではなくコード内に効果を記述している → 🟡

問題として指摘した項目ごとに、スキルを引用します：[→ skill-progression-trees: cost = baseCost * tier^exponent]

フェーズ 4 — 報酬スケジュールの確認

スコープが「difficulty」または「progression」の場合、このフェーズ全体を省略してください。

game-design-fundamentals の報酬スケジュールの原則を適用します（変動比率は固定比率よりも望ましい — B.F. Skinner の原則）。

報酬の構造を分析します。

報酬の種類	計画内のスケジュール	変動型か	評価
クエスト報酬	[fixed / variable]	[yes/no]	🟢/🟡/🔴
デイリーログイン	[fixed / variable]	[yes/no]	🟢/🟡/🔴
戦利品のドロップ	[fixed / variable]	[yes/no]	🟢/🟡/🔴
実績報酬	[fixed / variable]	[yes/no]	🟢/🟡/🔴

docs/quest-registry.md が存在する場合、クエスト報酬額をフェーズ 1 の経済指標と照合します。

次のアンチパターンを確認します。

• 報酬のインフレ — 報酬をあまりに早く与えすぎると、今後の報酬がすべて価値の低いものに感じられる → 🟡
• 予測可能なスケジュール — 固定比率の報酬は、変動比率の報酬よりもエンゲージメントを維持する効果が大幅に低い → 🟡
• 使い道がない — 意味のある消費先がなく、報酬が蓄積する → フェーズ 1 の経済停滞に関連 → 🔴

問題として指摘した項目ごとに、スキルを引用します：[→ game-design-fundamentals: variable ratio reward schedules sustain engagement longer]

フェーズ 5 — バランスレポート

レポート全体を出力します。

# Balance Report — [game name from mvp-first-draft.md] — [current date]

## Executive Summary
🔴 Critical issues: [count]
🟡 Warnings: [count]
🟢 Healthy systems: [count]

[If 0 critical issues]: ✅ No blockers found — safe to proceed with current design.
[If critical issues exist]: ⛔ [count] critical issue(s) must be resolved before launch.

---

## Economy Health [only if analyzed]
[metrics table from Phase 1]
[anti-pattern findings]

## Difficulty Curve [only if analyzed]
[phase table from Phase 2]
[anti-pattern findings]

## Progression Costs [only if analyzed]
[table from Phase 3]
[anti-pattern findings]

## Reward Schedules [only if analyzed]
[table from Phase 4]
[anti-pattern findings]

---

## Recommended Actions

### 🔴 Critical (resolve before building)
1. [Issue description] — [specific fix] `[→ skill-name: principle]`
...

### 🟡 Warnings (address before launch)
1. [Issue description] — [specific fix] `[→ skill-name: principle]`
...

### 🟢 Notes (optional improvements)
1. [Suggestion] `[→ skill-name: principle]`
...

---

厳格な制約

1. 問題を指摘する際は、必ずスキルを引用してください。根拠のない意見は認められません。
2. 「未定義」を健全な状態として扱わないでください。未定義のパラメーターは、デフォルトで🔴です（設定しなければ起動できません）。
3. ペイ・トゥ・ウィンは例外なく、常に🔴 CRITICALです。
4. クライアント側のゲーム状態は常に🔴 CRITICALです。サーバー権威型は譲れない要件です。
5. 🔴および🟡の指摘には、すべて具体的な修正方法を示してください。推奨事項を示さずに指摘するだけではいけません。