game-design-review

AlterLab GameForge -- ゲームデザインドキュメントのレビュー ワークフロー

ゲームデザインドキュメントは、あなたの志と実行能力を結びつける、生きた契約です。悪いGDDとは、書式が整っていないものではありません。チームが何週間も誤った方向に自信を持って進み、誰も気づかないままになるようなドキュメントです。Hollow Knightのデザインドキュメントが機能したのは、Team Cherryが内容を簡潔に保ち、反証可能にし、3つの柱に徹底的に集中させたからです。ほとんどのGDDが失敗するのは、ゲームを説明しても、それを制約しないからです。何でもありなら、何もうまくいきません。

これはチェックリストによるレビューではありません。チェックリストで確認できるのは、各セクションの有無です。このレビューで確認するのは、各セクションの質です。つまり、内部整合性があり、心理学的な根拠に基づき、スコープが現実的で、実装の判断を導くのに十分具体的かどうかです。Disco Elysiumでシステムと物語の統合が実現したのは偶然ではありません。デザインドキュメントで、すべてのスキルチェックがすべての会話分岐にどう結びつくかを正確に指定したからです。このレビューで求めるのは、そのレベルの具体性です。

目的と実施のきっかけ

以下のような場合に、このワークフローを使ってください。

• デザイナーが「GDDをレビューして」や「デザインドキュメントにフィードバックをください」と言ったとき
• 実装を始める前に、修正コストが低いうちに問題を見つけるとき
• 大幅なデザイン変更の後に、内部整合性を再検証するとき
• プレイテストで問題が明らかになり、根本原因がデザインにあると思われるとき
• ゲームがどのようなものなのかについて、チームメンバーの意見が分かれているとき

このワークフローで解決する問題：

• デザイン上の柱に役立っていないメカニクス（孤立した機能）
• 目標とする美学と実際のメカニクスの矛盾（MDAの不整合）
• 現実を無視したスコープの見積もり（計画に見せかけた楽観論）
• ゲームを説明していても、それを制約していないデザインドキュメント（何でもあり＝何もうまくいかない）
• 意図しない形で相互作用するシステム（創発的な衝突）
• 実装中の混乱につながる、記載されていないセクション

重要なルール

1. コメントする前にドキュメント全体を読むこと。 文脈が重要です。セクション3で孤立しているように見えるメカニクスも、セクション7の進行システムによって正当化されるかもしれません。まずすべてを読んでから分析してください。

2. 重大度は重要です。 すべての指摘が同じではありません。コアループの定義が欠けているのは重大です。アートスタイルへの言及が曖昧なのは軽微です。デザイナーがどこに時間をかけるべきか分かるよう、重大度を明示してください。

3. 曖昧にせず、具体的に伝えること。 「戦闘システムはもっと良くできる」は役に立たないフィードバックです。「戦闘システムにはプレイヤーの攻撃は記述されていますが、敵の行動パターンが明記されていないため、難易度調整ができません」なら、実際に対応できます。問題を明示し、該当セクションを示し、修正案を提案してください。

4. 押しつけず、提案すること。 指示するのではなく、理由を添えて別のアプローチを提示してください。ビジョンを持つのはデザイナーです。あなたの役割は、問題を特定して方向性を提案することです。「Disco Elysiumは、スキルチェックを戦闘ではなく会話に結びつけて解決しました」は発想を広げる参考例です。「Disco Elysiumをそのまま真似してください」は怠慢です。

5. 理論を参照すること。 問題を指摘する際は、docs/game-design-theory.mdにある確立されたデザイン原則と結びつけてください。「ステージ3の難易度上昇に、スキルを身につけるための段階的な導入がないため、フロー理論に反しています」は、「ステージ3は難しすぎます」より説得力があります。

6. ドキュメント全体の整合性を確認すること。 GDDの最大の失敗は、セクションが欠けていることではなく、セクション同士が矛盾していることです。「プレイヤーの自由」を掲げる柱と、直線的な通路を説明するレベルデザインのセクションは、重大な矛盾です。

ワークフロー

Step 1: ドキュメントの受け取り

設計ドキュメント全体を読みます。構成、長さ、全体的な編成を確認します。 必須のGDDセクション8項目のうち、どれが含まれているかを特定します。

REQUIRED GDD SECTIONS
-------------------------------------------------
1. Game Overview (concept, genre, platform, audience)
2. Core Mechanics (player actions, systems, interactions)
3. Game Flow / Core Loop (30-sec to full-game timescales)
4. Level / World Design (spaces, progression through space)
5. Art Direction (visual style, references, asset requirements)
6. Audio Design (music, SFX, adaptive audio approach)
7. UI / UX Design (menus, HUD, accessibility considerations)
8. Technical Requirements (engine, platforms, performance targets)

OPTIONAL BUT VALUABLE
- Narrative Design (story, characters, dialogue systems)
- Monetization Model (if applicable)
- Multiplayer Design (if applicable)
- Accessibility Plan
- Competitive Analysis
-------------------------------------------------

Step 2: 柱との整合性レビュー

これは最も重要な評価項目です。ゲームに定義された設計の柱がある場合、すべてのメカニクスとシステムが少なくとも1つの柱に結び付いている必要があります。柱が定義されていない場合は、重大な指摘事項として報告します。

PILLAR ALIGNMENT MATRIX
-------------------------------------------------
Mechanic/System        | Pillar 1 | Pillar 2 | Pillar 3 | Orphan?
-------------------------------------------------
[combat system]        | Yes      | --       | Yes      | No
[crafting system]      | --       | --       | --       | YES - flag
[dialogue choices]     | Yes      | Yes      | --       | No
[inventory management] | --       | --       | --       | YES - flag
-------------------------------------------------

Orphan mechanics are red flags. They either:
a) Should be cut (they serve no pillar, so they dilute focus)
b) Reveal a missing pillar (add a pillar that justifies them)
c) Are described poorly (clarify how they connect to pillars)

Step 3: MDAの一貫性レビュー

説明されているメカニクスが、目標とする美学を実際に実現しているかを確認します。そのためには、docs/game-design-theory.md に記載されているMDAフレームワークを理解する必要があります。

MDA CONSISTENCY CHECK
-------------------------------------------------
Target Aesthetic | Required Dynamics        | Mechanics That Deliver | Gap?
-------------------------------------------------
Discovery        | Exploration, revelation  | Fog of war, hidden areas | OK
Challenge        | Skill testing, escalation| [none described]         | GAP
-------------------------------------------------

Common MDA misalignments:
- Target "Discovery" but linear level progression (no exploration mechanics)
- Target "Challenge" but no difficulty scaling or mastery curve
- Target "Expression" but no player-facing creative tools
- Target "Fellowship" but single-player-only design

Step 4: プレイヤー心理のレビュー

自己決定理論とフロー理論の観点から評価します。

SDTの確認 -- 設計は3つの基本的な心理的欲求を満たしていますか？

SDT ASSESSMENT
-------------------------------------------------
Need         | Evidence in Design       | Threats in Design     | Rating
-------------------------------------------------
Autonomy     | [choices described]      | [forced linearity]    | [A/B/C/F]
Competence   | [skill expression]       | [unfair difficulty]   | [A/B/C/F]
Relatedness  | [social features]        | [isolation by design] | [A/B/C/F]
-------------------------------------------------

フローの確認 -- プレイヤーはフロー状態を維持できますか？

FLOW ASSESSMENT
-------------------------------------------------
Flow Element  | Present? | Notes
-------------------------------------------------
Clear goals   | Y/N      | [does the player always know what to do next?]
Immediate feedback | Y/N | [does every action produce visible response?]
Challenge/skill balance | Y/N | [does difficulty scale with player growth?]
Sense of control | Y/N   | [does the player feel agency?]
Loss of self-consciousness | Y/N | [can they forget they are playing?]
Time distortion | Y/N    | [does the design support losing track of time?]
-------------------------------------------------

Step 5: 内部一貫性のレビュー

ドキュメントの各セクション間に矛盾がないかを確認します。

CONSISTENCY CROSS-CHECK
-------------------------------------------------
Check                        | Status | Finding
-------------------------------------------------
Pillars vs. mechanics        | OK/CONFLICT | [detail]
Core loop vs. progression    | OK/CONFLICT | [detail]
Art style vs. tone          | OK/CONFLICT | [detail]
Difficulty curve vs. target audience | OK/CONFLICT | [detail]
Feature scope vs. team capacity | OK/CONFLICT | [detail]
Platform vs. control scheme  | OK/CONFLICT | [detail]
-------------------------------------------------

Step 6: スコープの実現可能性レビュー

記載されたリソースで、実際にこのゲームを開発できますか？

• 説明されている独自のシステムの数を数えます
• コンテンツ量（レベル、敵、アイテム、会話）を見積もります
• チームの規模や開発期間と照らし合わせます
• チームが開発できると実証していない技術を必要とするシステムがあれば指摘します
• 「隠れた複雑さ」――簡単そうに見えても、開発上の悪夢となる機能（経路探索、プロシージャル生成、マルチプレイヤーのネットコード、物理ベースのゲームプレイ）を確認します

Step 7: エッジケースの網羅性

プレイヤーが想定外の行動をしたとき、何が起きるでしょうか？

• プレイヤーが意図された順序を崩した場合はどうなりますか？
• 設計上は再生可能とされているリソースを、プレイヤーが使い切った場合はどうなりますか？
• 設計上必須とされているシステムに、プレイヤーが関わろうとしない場合はどうなりますか？
• 2つのシステムが意図しない形で相互作用した場合はどうなりますか？
• 極端な状況（最大レベル、リソースがゼロ、不可能な速度）では何が起きますか？

Step 8: オンボーディングの評価

新しいプレイヤーは、外部の助けなしにこのゲームを学べますか？

• チュートリアルの進め方が説明されていますか？
• 複雑さの増し方は、教える順序と合っていますか？
• 高度なメカニクスは、基本を習得した後にのみ導入されますか？
• チュートリアルを飛ばすプレイヤー向けに、「すぐにプレイ」できる導入方法がありますか？
• ゲームはプレイを通じて教えますか、それとも長文のテキストで教えますか？

Step 9: 競合との差別化

独自のフックは本当に独自のものですか？Hollow Knightのフックは「メトロイドヴァニア」ではありませんでした。そのジャンルはすでに競争が激しかったからです。フックとなったのは、哀愁漂う虫たちの文明、手応えのある戦闘、そしてじっくり探索するほど報われる世界という雰囲気でした。差別化はジャンルではなく、体験にありました。

• 最も近い比較対象となるゲームを3つ特定します
• それぞれについて、機能面ではなく体験面で、このゲームを異なるものにしている要素を定義します
• 差別化要素がメカニクスによるものか、見た目だけのものかを確認します（見た目だけの差別化は本当の差別化ではありません。「ゾンビが青い」はフックになりません）
• 30秒のトレーラーで伝わるほど、独自のフックが際立っているかを評価します

出力形式

このワークフローでは、設計レビュー報告書を作成します。

# Design Review Report
**Document:** [GDD title]
**Version:** [if specified]
**Reviewer:** GameForge Design Review
**Date:** [date]

## Executive Summary
[2-3 sentences: overall assessment, biggest strength, most critical issue]

## Section Completeness
| Section | Present | Completeness | Notes |
|---------|---------|-------------|-------|
| Game Overview | Y/N | [%] | |
| Core Mechanics | Y/N | [%] | |
| ... | | | |

## Findings

### Critical (must fix before implementation)
- **[CRIT-01]** [Title]: [Detailed finding with specific references to the document]
  **Recommendation:** [specific suggested fix]

### Major (fix soon, will cause significant problems if ignored)
- **[MAJ-01]** [Title]: [Detailed finding]
  **Recommendation:** [specific suggested fix]

### Minor (improve when convenient)
- **[MIN-01]** [Title]: [Detailed finding]
  **Recommendation:** [specific suggested fix]

### Suggestions (not problems, but opportunities)
- **[SUG-01]** [Title]: [Idea for improvement]

## Pillar Alignment Matrix
[From Step 2]

## MDA Consistency Report
[From Step 3]

## Strengths
[What the document does well -- always include positives]

## Recommended Next Actions
1. [Priority action]
2. [Second action]
3. [Third action]

## Suggested Workflows
- [ ] [e.g., game-brainstorm to develop underdeveloped areas]
- [ ] [e.g., game-balance-check for tuning concerns]

品質基準

質の高い設計レビューは、以下をすべて満たします。

• 各指摘事項で、レビュー対象のドキュメント内の具体的な文章やセクションを引用している
• 重大度の評価に根拠があり、問題の程度に見合っている
• 説明されているすべてのメカニクスについて、柱との整合性を確認している
• プレイヤー心理（SDTまたはフロー）に関する指摘事項が少なくとも1つある
• 問題だけでなく、強みも特定している
• 推奨事項が具体的で、すぐに実行できる
• スコープの評価が、現実の開発工数に基づいている
• 内部矛盾を見つけ、明確に説明している
• 設計の品質とドキュメントの品質を区別している （優れた設計でも記述が不十分なことがあり、その逆もあります）

使用例

1. 「コーディングを始める前に、私のGDDをレビューしてください。」 9つのステップすべてをレビューします。コードを1行でも書く前に解決すべき重大な指摘を重視します。

2. 「プレイテストの結果が散々でした。問題はデザインにあるのでしょうか？」 ステップ3（MDAの一貫性）、4（プレイヤー心理）、7（エッジケース）に重点を置きます。 プレイテストのフィードバックから、どの側面を特に詳しく調べるべきかが見えてきます。

3. 「スコープが大きすぎる気がします。確認してもらえますか？」 ステップ6（スコープの実現可能性）に重点を置きます。システムの数を数え、コンテンツ量を見積もり、チームの対応能力と比較したうえで、率直な判断を示します。

4. 「クラフトシステムを追加するかどうかで意見が分かれています。判断を手伝ってください。」 ステップ2（柱との整合性）に重点を置きます。クラフトが柱に沿うなら、採用すべきです。そうでなければ、機能の形をしたスコープクリープにすぎません。

5. 「このGDDを一気に書き上げました。何か見落としはありますか？」 ステップ1（セクションの網羅性）とステップ5（内部整合性）を重視して、全体をレビューします。急いで書かれたドキュメントには、明確化が必要な暗黙の前提や、解決すべき矛盾が含まれていることがよくあります。