Game Experience Core

ゲームの「面白さ」を感覚から再現可能な構造へ落とし込むためのフレームワーク。

ワークフロー概要

1. 中核判断の特定 - プレイヤーが常に考える「唯一の問い」を決める
2. 前提条件の検証 - 判断が成立するための3条件を確認
3. ループ設計 - 判断→結果→学習のサイクルを定義
4. リソース設計 - 判断を"本気"にするリソースを設計
5. 失敗設計 - 良い失敗体験を設計
6. 最終言語化 - 面白さを一文で表現

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 (予定): ③システム設計への落とし込み