phaser-gdd

Phaser 4 ゲームデザインドキュメントジェネレーター

Phaser 4 ゲーム向けの包括的なゲームデザインドキュメント（GDD）を生成します。GDD は、メカニクス、アート、オーディオ、進行、技術的制約といったすべての設計上の決定を 1 つの Markdown ファイルにまとめるため、コードを書く前にチーム全員（またはソロ開発者）が共通の参照資料を持てます。

GDD の構成（13 セクション）

生成されるすべての GDD には、以下の 13 セクションをすべて含める必要があります。ユーザーがセクションの詳細を指定していない場合は、ジャンルと規模に基づいて妥当なデフォルトを提示し、前提は `` でマークして簡単に見つけて修正できるようにします。

---

セクション 1 — ゲーム概要

ゲームのアイデンティティを一目で確立します。

含める内容:

• タイトル — 仮タイトル（プレースホルダーでも可）。
• タグライン — フックを売り込む、印象的な一文。
• ジャンル — 主要ジャンルとサブジャンル（例: 「ローグライクプラットフォーマー」）。
• ターゲット層 — 年齢層、プレイヤープロフィール、カジュアルかハードコアか。
• エレベーターピッチ — ちょうど 2 文: プレイヤーが何をするのか、なぜ楽しいのか。
• 独自のセールスポイント（USP） — このゲームを差別化する 3〜5 個の箇条書き。
• 類似タイトル — ユーザーやターゲット層が認識する既存ゲーム 2〜3 本と、何を取り入れ、何が異なるかの簡単なメモ。

---

セクション 2 — コアゲームループ

プレイヤーを惹きつけ続ける反復サイクルを定義します。

含める内容:

• 30 秒ループ — 最小の原子的アクションサイクル（例: ジャンプ→着地→収集）。
• 5 分ループ — レベルやウェーブのクリアなど、中規模のアーク。
• セッションループ — 1 回のプレイセッションの全体像（カジュアルなら 15〜30 分、ハードコアなら 60 分以上）。

各ループは ASCII フロー図 として提示します:

[Action] --> [Feedback] --> [Reward] --> [Decision] --+
   ^                                                  |
   +--------------------------------------------------+

• 勝利条件 — ゲームまたはレベルを「クリア」するためにプレイヤーが達成すべきこと。
• 敗北条件 — 失敗の原因と、その後に起こること（レベル再開、残機減少、ゲームオーバー）。

---

セクション 3 — メカニクス詳細

プレイヤーが触れるすべてのインタラクティブシステムを詳述します。

含める内容:

• 主要メカニクス — 1〜3 個のコア動詞（例: ジャンプ、射撃、マッチ）。それぞれについて: 入力、物理挙動、エッジケース。
• 副次メカニクス — 補助システム（例: インベントリ、クラフト、会話）。それらがコアゲームループにどう還元されるかを説明します。
• 操作方法 — プラットフォームごとに入力を対応付けます:

アクション	キーボード	タッチ	ゲームパッド
移動	WASD / 矢印キー	仮想ジョイスティック	左スティック
ジャンプ	Space	右側をタップ	A ボタン

---

セクション 4 — 進行システム

難易度、コンテンツ、報酬が時間とともにどう変化するかを説明します。

含める内容:

• 難易度曲線 — 意図する上昇の仕方（線形、指数関数的、のこぎり波状）を説明します。具体的なマイルストーンを参照してください。
• アンロック順序 — プレイヤーがいつ、どの新しい能力、レベル、アイテムを獲得するか。
• スコアリングシステム — スコアの計算方法、コンボ倍率、リーダーボードがあればその有無。
• リプレイ性のフック — プレイヤーが戻ってくる理由（New Game+、デイリーチャレンジ、プロシージャル生成）。
• 推定プレイ時間 — 初回クリアまでの時間と、100% クリアまでの時間。

---

セクション 5 — レベル / ワールドデザイン

ゲームの空間構造を計画します。

含める内容:

• レベル数 — レベル、ワールド、ゾーンの総数。
• テーマ — ワールドごとのビジュアルとメカニクスのテーマ（例: 「ワールド 2 — アイスケイブ: 滑る床、壊せる壁」）。
• フローマップ — レベルの進行と分岐を示す ASCII 図:

[Level 1] --> [Level 2] --> [Level 3]
                  |
                  +--> [Bonus Level A]

• 難易度スケーリング — レベルごとに敵の数、速度、パズルの複雑さ、時間的プレッシャーがどう増加するか。

---

セクション 6 — キャラクターとエンティティ

ゲームプレイに関連する詳細をすべてのゲームオブジェクトについてカタログ化します。

含める内容:

• プレイヤーキャラクター — 基本ステータス (速度、体力、ジャンプ高)、能力、ステートマシン (待機、走行、ジャンプ、被ダメージ、死亡)。
• 敵の種類 — 表形式:

敵	HP	速度	行動	攻撃	ドロップ
スライム	1	40px/s	左右に巡回	接触ダメージ	コイン (50%)

• NPC — 役割、会話トリガー、クエストとの関連付け。
• 収集アイテムとパワーアップ — 効果、持続時間、レアリティ、視覚的インジケーター。

---

セクション 7 — UI/UX ワイヤーフレーム

プレイヤーが目にするすべての画面を定義します。

含める内容:

• HUD レイアウト — ゲーム内オーバーレイの ASCII ワイヤーフレーム:

+---------------------------------------+
| [Lives: x3]          [Score: 00000]   |
|                                       |
|                                       |
|              GAME AREA                |
|                                       |
|                                       |
| [Item1] [Item2] [Item3]    [Pause]   |
+---------------------------------------+

• メニューフロー図 — 画面間のナビゲーションを示す ASCII:

[Title Screen] --> [Main Menu] --> [Play] --> [Level Select] --> [Game]
                       |                                           |
                       +--> [Settings]                     [Pause Menu]
                       +--> [Credits]                          |
                                                         [Game Over] --> [Main Menu]

• 画面モックアップ — 各固有画面 (タイトル、メインメニュー、設定、ゲームオーバー、勝利) の簡単な説明。
• アクセシビリティの考慮事項 — 色覚サポートモード、フォントサイズオプション、再割り当て可能な操作、スクリーンリーダーのヒント。

---

セクション 8 — アートディレクション

ビジュアルアイデンティティとアセットパイプラインを確立します。

含める内容:

• ビジュアルスタイル — 1〜2 文で説明します (例: 「モダンなライティング効果を備えた 16 ビットピクセルアート」)。
• カラーパレット — 役割ラベル付きの 5〜8 個の hex コード:

役割	Hex	用途
プライマリ	#3A86FF	プレイヤー、UI ハイライト
セカンダリ	#FF006E	敵、危険
背景	#1B1B2F	空、メニュー

• 解像度とスケーリング — ゲーム解像度 (例: 800x600)、スケールモード (Phaser FIT、RESIZE など)、ピクセルパーフェクトフラグ。
• アニメーションガイドライン — フレーム数、アニメーションタイプごとの FPS (待機: 4 フレーム @ 8fps、走行: 6 フレーム @ 12fps)。
• 仕様付きアセットリスト — 必要なすべてのアセットの表:

アセット	タイプ	サイズ	フレーム数	フォーマット
player_idle	スプライトシート	32x32	4	PNG
background_forest	静的	800x600	1	PNG

---

セクション 9 — オーディオデザイン計画

サウンドスケープを定義します。

含める内容:

• シーンごとの音楽ムード — 各シーン/レベルを音楽のムードとテンポに対応付ける表:

シーン	ムード	テンポ	ループ?
メインメニュー	神秘的、魅力的	90 BPM	はい
レベル 1	明るい、冒険的	120 BPM	はい
ボス戦	激しい、緊迫した	150 BPM	はい
ゲームオーバー	物悲しい、内省的	70 BPM	いいえ

• SFX リスト — アクションとサウンドの対応付け:

アクション	サウンドの説明	優先度
プレイヤーのジャンプ	短い軽やかなシュッという音	高
コイン収集	明るく上昇するチャイム	高
敵へのヒット	柔らかい鈍い音 + グチャッという音	中

• フォーマット要件 — すべてのオーディオはクロスブラウザ互換性のため MP3 と OGG の両方で提供する必要があります。Phaser は実行時に最適なフォーマットを選択します。
• 音量の階層 — 相対的な音量レベルを定義します: 音楽 (0.4)、SFX (0.7)、UI サウンド (0.5)。それらがどのように相互作用するかを説明します (主要なイベント時に SFX が音楽を一時的にダッキングするなど)。

---

セクション 10 — 技術要件

Phaser 固有の技術的決定を明確にします。

含める内容:

• Phaser バージョン — ユーザーが別途指定しない限り phaser (v4.2.1 stable)。
• 物理エンジン — 1 つを選択し、根拠を示します:
  • Arcade — シンプルな AABB、プラットフォーマーやシューターに最適。CPU コストが低い。
  • Matter.js — 完全な剛体物理。回転、ジョイント、複雑な衝突形状を必要とするゲームに使用します。
  • なし — 物理シミュレーションのないパズルやカードゲーム向け。
• パフォーマンスバジェット — 目標フレームレート (60 FPS)、1 フレームあたりの最大ドローコール数、最大同時パーティクル数、テクスチャアトラスのサイズ制限。
• ブラウザ/デバイスターゲット — 最小ブラウザバージョン、モバイルデバイス層 (例: 「2020 年代のミッドレンジ Android で 30+ FPS で動作すること」)。

---

セクション 11 — 対象プラットフォームとデバイスプロファイル

ゲームをどこで実行するか、入力がどのように異なるかを指定します。

含める項目:

• 主要プラットフォーム — デスクトップブラウザ、モバイルブラウザ、PWA、Electron、Capacitor/Cordova。
• プラットフォームごとの入力:

プラットフォーム	主な入力	補助入力
デスクトップ	キーボード + マウス	ゲームパッド
モバイル	タッチ	ジャイロスコープ(オプション)
タブレット	タッチ	Bluetooth ゲームパッド

• デプロイ方法 — ゲームをどのようにビルドして配布するか(静的ホスティング、itch.io、Capacitor 経由のアプリストアなど)。

---

セクション 12 — マネタイズとリリース計画(オプション)

ビジネス面について話し合いたい場合にのみ、このセクションを含めてください。出力ではオプションとしてマークしてください。

含める項目:

• ビジネスモデル — 無料、プレミアム、フリーミアム、広告収益型、またはドネーションウェア。
• マイルストーン — 主要な日付またはフェーズ:

マイルストーン	目標日	成果物
プロトタイプ	第2週	コアループがプレイ可能
アルファ	第6週	すべてのレベルがブロックアウト済み
ベータ	第10週	機能完成、プレイテスト実施
ローンチ	第14週	磨き上げ済み、デプロイ済み

• 配布 — ゲームをどこで公開するか(itch.io、GitHub Pages、Steam、アプリストア)。

---

セクション 13 — 受け入れ基準

他のすべてのセクションは意図を説明します。このセクションだけが、機械がチェックできる唯一の部分であり、 GDD をドキュメントから仕様へと変えるものです。

各基準は、観測可能で、数値的で、ゲームが間違っていれば false になるように書いてください。 「プレイヤーは強く感じるべき」は基準ではありません。「チャージ攻撃は基本ダメージの3倍を与える」は基準です。

基準はセクション 3(メカニクス)、4(進行)、6(エンティティ)から直接導き出してください — 設計が数値にコミットしている箇所では、その数値が基準です。

基準	観測可能な状態	プレイテストのアサーション
プレイヤーが3タイル(96px)の高さまでジャンプする	頂点での player.y	player.y、atMost: spawnY - 96
基本敵は3回のヒットで死亡する	enemy.active	攻撃を3回押す、その後 enemy.active、equals: false
スコアが GameOver まで保持される	registry.get('score')	遷移、その後 atLeast: 10
コヨーテタイムは100ms	台から離れた後にジャンプが成功する	歩いて離れ、80ms 待ち、ジャンプ → body.velocity.y < 0
ウェーブ5で12体の敵がスポーンする	アクティブな敵の数	ウェーブを設定、その後 enemies.countActive(true)、equals: 12
50エンティティで60fpsを維持する	game.loop.actualFps	50体スポーン、その後 atLeast: 55
起動から3秒以内にメニューへ到達する	t=3s でのシーンキー	game.scene.isActive('MainMenuScene')、equals: true

基準は、それを満たす必要があるマイルストーンの下にグループ化してください:

### Vertical Slice
- [ ] Player spawns at level start and responds to left/right/jump within 1 frame
- [ ] Falling off the map triggers respawn at the last checkpoint within 500ms
- [ ] Collecting a coin increments score by 10 and plays the pickup sound

### Alpha
- [ ] All 8 levels load without console errors
- [ ] Enemy AI pathfinds around static geometry (no wall-clipping over 30s)

本当に主観的なものは、偽の指標をでっち上げるのではなく、そのようにマークしてください:

### Human review required (not automatable)
- Difficulty curve across levels 1-8 feels fair to a first-time player
- Art reads clearly against every background
- Audio mix is balanced at 50% volume

これらを GDD とともに docs/acceptance-criteria.md に保存してください。phaser-playtest スキルは、自動化可能な各基準をシナリオのアサーションに変換します。これにより、設計は単に述べられるだけでなく 検証されるようになります。

---

GDD 後のワークフロー

GDD が確定したら、ユーザーを次のステップへ導きます。

1. プロジェクトをスキャフォールドする — /phaser-new を使用して、GDD の技術要件に一致するベースプロジェクト構造を生成します。
2. アーキテクチャを設計する — phaser-architect スキル/エージェントを使用して、GDD を技術アーキテクチャへ変換します。シーングラフ、クラス階層、データフロー、システム分解などです。
3. 実装を開始する — phaser-coder スキル/エージェントを使用して、GDD で指定されたシーン、メカニクス、エンティティのコーディングを開始します。
4. 動作を検証する — 各バーティカルスライスの後に /phaser-playtest を実行します。セクション 13 の自動化可能な受け入れ基準はプレイテストのアサーションになり、これによって設計が単に述べられるだけでなくチェックされるようになります。
5. リリースする — /phaser-release が準備完了ゲートを実行し、ストアでの露出を準備します。
6. プレイヤーの声をもとに反復する — /phaser-feedback が彼らの報告を失敗するプレイテストシナリオに変換し、次に修正し、その後リグレッションテストにします。

ユーザーが、研ぎ澄まされたコンセプトなしでここにたどり着いた場合 — フックではなくジャンルである、あるいは使える時間に対して規模が定まっていないスコープである場合 — まず /phaser-brainstorm へ送ってください。スコープが定まっていないアイデアを中心に書かれた GDD は、完成しないプロジェクトを記録したものになります。

ユーザーに思い出させてください。GDD は生きたドキュメントです。開発中にゲームが進化するにつれて更新してください。

---

出力形式

生成される GDD は、以下を備えた 単一の Markdown ドキュメント でなければなりません。

• トップレベルの # Game Design Document: [Title] 見出し。
• 13 個の各セクションを ## Section N — Name 見出しとして。
• すべてのフローチャート、ワイヤーフレーム、レベルマップに ASCII 図（外部画像への依存なし）。
• 構造化データ（敵、アセット、オーディオ、操作）用のテーブル。
• 生成器がユーザーから受け取らずに推測したあらゆる詳細の隣に `` コメント。

ドキュメントをプロジェクトルートの docs/GDD.md に保存します。プロジェクトディレクトリが存在しない場合は、完全な GDD をチャット内にインラインで出力します。