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