ゲーム要件定義スキル

ゲームの漠然としたアイデアを、設計・実装可能な要件定義書に変換する。

ワークフロー概要

6つのステップで要件を定義する：

1. プレイサイクル定義 - 1回のプレイで何を繰り返すか
2. 勝敗条件の明文化 - 勝利・敗北・継続不能の条件
3. プレイヤー操作の洗い出し - できることを動詞で列挙
4. ゲーム要素定義 - システム化できる「モノ」
5. 変数・数値の仮置き - 調整可能な形に落とす
6. 想定プレイフロー - 1プレイ分のシミュレーション

詳細ワークフロー: workflow.md

クイックスタート

Step 1: ジャンル選択

ユーザーのゲームアイデアに近いジャンルを特定し、該当テンプレートを参照：

| ジャンル | テンプレート | |---------|-------------| | 汎用（ジャンル不明） | generic.md | | デッキ構築 | deck-builder.md | | ローグライク | roguelike.md | | RPG | rpg.md | | パズル | puzzle.md | | アクション | action.md | | タワーディフェンス | tower-defense.md | | SRPG | srpg.md |

Step 2: 対話的にヒアリング

各ステップでユーザーに質問し、情報を収集：

プレイサイクル → 勝敗条件 → 操作 → 要素 → 数値 → フロー

Step 3: 要件定義書を出力

収集した情報をMarkdownファイルとして出力。 ファイル名例: docs/requirements/{game-name}-requirements.md

重要な原則

• プレイサイクルは30秒〜1分で回るのが理想
• 勝敗条件が曖昧だと設計が破綻する
• 操作はUIではなく「行為そのもの」に集中
• 数値は正解でなくていい、存在することが重要
• 想定フローで破綻に気づくことが多い

出力フォーマット

# {ゲーム名} 要件定義書

## 1. プレイサイクル
① 状況提示: ...
② プレイヤーの選択: ...
③ 結果反映: ...
④ フィードバック: ...

## 2. 勝敗条件
- 勝利条件: ...
- 敗北条件: ...
- 継続不能条件: ...

## 3. プレイヤー操作
- 選ぶ
- 使う
- ...

## 4. ゲーム要素
### プレイヤー
- 状態: ...
- 変化: ...

### {その他要素}
...

## 5. 数値設計
| 変数 | 範囲 | 初期値 |
|-----|------|-------|
| HP | 10〜30 | 20 |
| ... | ... | ... |

## 6. 想定プレイフロー
### 1ターン目
- 状況: ...
- 行動: ...
- 結果: ...