ゲーム要件定義スキル
ゲームの漠然としたアイデアを、設計・実装可能な要件定義書に変換する。
ワークフロー概要
6つのステップで要件を定義する：
- •プレイサイクル定義 - 1回のプレイで何を繰り返すか
- •勝敗条件の明文化 - 勝利・敗北・継続不能の条件
- •プレイヤー操作の洗い出し - できることを動詞で列挙
- •ゲーム要素定義 - システム化できる「モノ」
- •変数・数値の仮置き - 調整可能な形に落とす
- •想定プレイフロー - 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: 対話的にヒアリング
各ステップでユーザーに質問し、情報を収集：
code
プレイサイクル → 勝敗条件 → 操作 → 要素 → 数値 → フロー
Step 3: 要件定義書を出力
収集した情報をMarkdownファイルとして出力。
ファイル名例: docs/requirements/{game-name}-requirements.md
重要な原則
- •プレイサイクルは30秒〜1分で回るのが理想
- •勝敗条件が曖昧だと設計が破綻する
- •操作はUIではなく「行為そのもの」に集中
- •数値は正解でなくていい、存在することが重要
- •想定フローで破綻に気づくことが多い
出力フォーマット
markdown
# {ゲーム名} 要件定義書
## 1. プレイサイクル
① 状況提示: ...
② プレイヤーの選択: ...
③ 結果反映: ...
④ フィードバック: ...
## 2. 勝敗条件
- 勝利条件: ...
- 敗北条件: ...
- 継続不能条件: ...
## 3. プレイヤー操作
- 選ぶ
- 使う
- ...
## 4. ゲーム要素
### プレイヤー
- 状態: ...
- 変化: ...
### {その他要素}
...
## 5. 数値設計
| 変数 | 範囲 | 初期値 |
|-----|------|-------|
| HP | 10〜30 | 20 |
| ... | ... | ... |
## 6. 想定プレイフロー
### 1ターン目
- 状況: ...
- 行動: ...
- 結果: ...