| name | game-experience-core |
| description | ゲームの「面白さ」を再現可能な構造として言語化するスキル。 以下の場面で使用: (1)新規ゲーム設計時に体験コアを定義する (2)既存ゲームの面白さを構造的に分析する (3)「ゲームの面白さを言語化したい」「体験を設計したい」と言われた時。 判断・行動・学習ループを中心に、リソース設計と失敗設計を含む包括的な体験定義書を生成する。 |
Game Experience Core
ゲームの「面白さ」を感覚から再現可能な構造へ落とし込むためのフレームワーク。
ワークフロー概要
- 中核判断の特定 - プレイヤーが常に考える「唯一の問い」を決める
- 前提条件の検証 - 判断が成立するための3条件を確認
- ループ設計 - 判断→結果→学習のサイクルを定義
- リソース設計 - 判断を"本気"にするリソースを設計
- 失敗設計 - 良い失敗体験を設計
- 最終言語化 - 面白さを一文で表現
Step 1: 中核判断の特定
プレイヤーの思考を一つの問いに集約する。
フォーマット
プレイヤーは常に「◯◯すべきか？」を考えている
質問ガイド
- このゲームで最も頻繁に下す判断は何か？
- プレイヤーが悩む瞬間はどこか？
- その判断を面白くしているのは何か？
重要: 判断は必ず1つに絞る。2つ以上あると設計がブレる。
ジャンル別の例は references/examples.md を参照。
Step 2: 判断成立の前提条件
判断が意味を持つには以下3条件が必要:
| 条件 | 説明 | NGパターン |
|---|---|---|
| 情報が不完全 | 全ての情報が見えていない | 正解が一瞬で分かる |
| 選択にコストがある | 何かを犠牲にする | ノーリスクで選べる |
| 結果がすぐに分からない | 選択後に時間差がある | 即座に正解が判明 |
検証チェックリスト
- プレイヤーは推測や予測を必要とするか？
- 選択にトレードオフがあるか？
- 結果が判明するまでに緊張感があるか？
Step 3: 判断→結果→学習ループ
ゲームプレイを以下の構造で設計:
判断: （何を選ぶか）
↓
結果: （何が変わるか）
↓
学習: （次は何を工夫するか）
↓
[次の判断へ]
設計質問
- 結果は判断と明確に紐づいているか？
- プレイヤーは「次はこうしよう」と思えるか？
- ループは適切な速度で回るか？
重要: 「学習」が起きない設計は長続きしない。
Step 4: 緊張を生むリソース設計
判断を"本気"にするリソースを設計する。
代表的なリソース
| リソース | 効果 | 設計ポイント |
|---|---|---|
| HP/体力 | 失敗の代償を可視化 | 回復手段とバランス |
| 行動回数 | 優先順位付けを強制 | 1ターンで何ができるか |
| 時間 | 意思決定を圧迫 | リアルタイム vs ターン制 |
| 情報 | 未知への賭けを生む | 何を見せ、何を隠すか |
| 通貨/ポイント | 長期計画を促す | 獲得と消費のバランス |
重要: 無限リソース＝判断が形骸化
検証質問
- リソースが尽きる恐怖があるか？
- リソース管理自体に判断が生まれるか？
Step 5: 失敗の設計
良い失敗と悪い失敗を区別する。
悪い失敗（避けるべき）
- 理不尽で原因が分からない
- 時間だけが奪われる
- リカバリー不可能
良い失敗（設計すべき）
- 原因が理解できる
- 次の行動が見える
- 学習につながる
設計検証
- プレイヤーは「なぜ失敗したか」を説明できるか？
- 失敗後に「次はこうしよう」と思えるか？
- 失敗から新しい選択肢が見えるか？
Step 6: 面白さの最終言語化
全てのステップを踏まえて、面白さを一文で表現する。
フォーマット
このゲームは
「◯◯という制約の中で、
◯◯を選び続けることが楽しい」
完成チェック
- 中核判断が明確に含まれているか？
- 制約（リソース）が含まれているか？
- 動詞（行動）が含まれているか？
この文が書けないなら、体験コア定義は未完成。
出力
最終的に assets/template.md の形式で体験コア定義書を出力する。
関連スキル
game-idea-core(予定): ①アイデア段階の言語化game-system-core(予定): ③システム設計への落とし込み