テストにつなげるゲームデザインドキュメントのテンプレート

次のビルドに必要な文書を書く

ゲームデザインドキュメント（GDD）には、何を作り、何を含めず、プロトタイプが動くかをどう判断するかを説明します。AI を活用した開発では、具体的なルール、操作、範囲の境界、受け入れ確認が特に役立ちます。長いストーリーの概要だけでは、アイテムを二重に数えてよいか、再スタートで何をリセットするかは決まりません。

このガイドでは一貫して、ロボットの小さな配達ゲーム「Rain Route」を教材として使います。GDD、プロンプト、変更、テストはすべて同じ提案上のゲームを扱います。実際に生成したプロジェクトや報告されたユーザー体験ではありません。このワークフローは、提案したビルドがすでに存在すると主張せずに、判断を実装につなげる方法を示します。

記入済みのミニ GDD をコピーする

Rain Route、デザインバージョン 0.1。

企画概要：見下ろし視点のロボットが、雨の降る街の一区画で思い出の荷物を運ぶ。

プレイヤーとプラットフォーム：デスクトップブラウザでキーボードを使う一人プレイ。初回プレイ約5分をデザイン目標とし、測定済みの結果とはしない。

約束と柱：落ち着いた移動、見分けやすい目的地、小さな経路選択。追加システムより明確なフィードバックを優先する。

基本の流れ：集配所で荷物を一つ受け取り、対応する番号の玄関まで歩いて配達し、次の荷物を取りに戻る。三回の配達で勝利。

操作とカメラ：固定の見下ろしカメラ。WASD または矢印キーで移動。表示された操作範囲内で E を押すと荷物を受け取るか配達する。勝利後は R で再スタート。画面に操作説明を表示する。

ルール：持てる荷物は一つだけ。配達順は1番、2番、3番のドア。間違ったドアで E を押すとメッセージが表示され、荷物はなくならない。正しい配達ごとにカウンターが一回増える。E を繰り返し押しても完了済みの配達を再度数えない。

マップと課題：一区画、集配所一つ、ドア三つ、水たまりを横切る道、乾いた迂回路。水たまりの中では移動速度が通常の半分。体力減少、敵、時間切れによる失敗はない。

フィードバック：現在の目的地、運搬中の荷物、完了した配達数を表示する。ドア番号を区別し、配達確認を見える形で示す。雨の環境音は静かにし、ミュート機能を用意する。

技術的な範囲：ブラウザ向けプロトタイプ一つ。アカウント、クラウドセーブ、ネットワーク、購入、追加マップ、アンロックシステムは含めない。再読み込みで新しいプレイを開始する。基本の流れがテストに通るまでは、単純なオリジナルの図形を使う。

勝利とリセット：三回目の配達後に勝利パネルを表示する。R でロボット、荷物、目的地、配達カウンター、勝利パネルを初期状態に戻す。

レビューの問い：初めてのプレイヤーは、画面に表示された説明だけで最初の配達を完了できるか？

ステップ1：GDD を一つの制作依頼に変える

文書は入力として使い、実装の証拠とは考えません。送信前に、範囲、操作、勝利条件の矛盾を確認します。「再読み込みで新しいプレイを開始する」なら配達状況の永続化は約束できず、「荷物一つ」なら隠れたインベントリーの待ち行列は含められません。実装時の推測に任せず、GDD で決定してください。最初のプロンプトの例は次のとおりです。

デザインバージョン 0.1 に基づいて Rain Route を作ってください。まずマップ、移動、集配所での荷物の受け取り、1番ドアへの配達だけを実装します。後のドアは見える状態にしますが、操作できないようにしてください。現在の目的地と荷物を持っているかどうかを表示します。単純なオリジナルの図形を使います。天候効果、アンロック、失敗タイマー、追加の仕組みは入れないでください。変更したコンポーネントと、受け取り、間違ったドアでの操作、正しい配達、E の連打をテストする方法を説明してください。

最初の依頼はこの配達部分に限定します。目的地を増やす前に、完成した一つの操作の流れを確認できる出力が必要です。文書化された操作でルートを完了できない場合は、マップを広げるのではなくその部分を修正します。

ステップ2：同じゲームで要件とテストを対応させる

重要なルールに短い識別子を付け、プロンプト、メモ、テスト記録で共通して使います。

実際の観察結果は、ビルドのバージョンと環境を添えて別の実行ログに記録します。合格、失敗、ブロックなどの状態は、操作を実行した後にのみ付けてください。最初の部分で R2 が失敗した場合は、三回の配達を依頼する前にその操作を修正します。他の人が失敗を再現できるよう、入力手順を正確に残してください。

ステップ3：基本の流れを拡張してから雰囲気を加える

最初の配達がテストに通ったら、2番と3番のドア、勝利とリセットの状態を依頼します。R1〜R4 と R6 を再実行してください。その後、水たまりでの減速を依頼し、受け取りのロジックを変えずに R5 を確認します。

これらのルールが通ってから、雨の映像と静かな環境音を追加します。雨が番号や操作マーカーを隠さず、ミュートが機能することを確認してください。天候効果でマップが読みにくくなる場合は、文書化したプレイヤーへの約束を犠牲にして雰囲気を優先せず、効果を弱めます。

ステップ4：証拠によって判断が変わったら GDD を更新する

将来のプレイテストで、プレイヤーが現在の目的地を見落とすことが分かったと仮定します。ここでは仮の観察であり、実際の結果ではありません。範囲を絞った変更として、ドアの順番と配達ルールを維持しつつ、目的地ラベルをより目立たせるよう依頼します。別の新しいプレイヤーで、最初の配達について同じ問いを再テストしてください。

この判断をバージョン 0.2 として記録し、変更理由を記し、影響を受ける要件とビルドに結びつけます。古いテスト結果を新しいルールの証拠と取り違えないよう、以前の判断も参照できる状態にします。変更した要件には、過去のどの確認を再実行する必要があるかを示してください。

生成された変更が以前の要件を壊したら、その変更を戻すか切り分けます。失敗した要件、正確な入力、期待結果、実際の結果を報告してください。「E を繰り返すと R3 が二回数える」は、「プロトタイプにバグがありそう」より具体的に対応できます。

仕様とテストログの間で SEELE を使う

SEELE は自然言語によるゲーム制作と、ゲームプレイ、シーン、アセットの反復的な変更をサポートしています。ミニ GDD をデザインの入力として渡し、範囲を絞った実装部分を一つ依頼します。役立つ出力は同じ文書と比較できるビルド候補であり、設計判断や完了済みのテスト記録の代わりではありません。

追加の依頼では毎回、変更した要件と安定させるべき要件を明示します。より分かりやすい目的地ラベルを依頼しても、タイマーが黙って追加されたりドアの順番が変わったりしてはいけません。整った説明が実際の挙動の代わりにならないよう、文書、プロンプト、観察結果をバージョンで結びつけます。

GDD を使って制作を先延ばしにせず始める

役立つ GDD は、判断から確認までの距離を縮めます。Rain Route には長いストーリーの概要より先に、明確な受け取りルール、目的地の順序、リセットの定義が必要です。文書は短く保ちつつ、別の人が同じビルドを判断できるほど正確にルールを定めてください。

仕様を SEELE にコピーし、最初の配達部分を依頼します。文書、動作するビルド、テストログのバージョンを合わせてください。同じゲームの既存ルールが実装と変更後も維持された場合にのみ範囲を広げ、証拠によって判断が変わったら GDD を更新します。

よくある質問

プロトタイプの GDD はどのくらいの長さにすべきですか？

次の実装判断を解決できる範囲で、できるだけ短くします。記入済みの例では、長大な制作資料を作らずに範囲、操作、ルール、テストを指定しています。誰かが作るものや確認するものが変わる場合にセクションを追加してください。操作ルールの欠落は、背景設定の一ページがないことより大きなコストになります。

AI に文書を書いてもらえますか？

AI は各セクションの下書きや曖昧さの発見を支援できますが、ルールの決定と実現可能性の確認は自分で行う必要があります。矛盾する要件や不足した受け入れ基準を特定するよう依頼してください。整った文書を、面白さ、実装品質、アセットの権利、未確認の製品機能の検証と見なしてはいけません。

GDD とテストログはどう違いますか？

GDD は意図した挙動と決定を示します。テストログは特定のビルドと環境で実際に起きたことを記録します。両者は関連付けつつ分けてください。合格するという期待は、テストの合格ではありません。観察結果によってルール変更が妥当になった場合は、設計を明示的に更新し、影響する確認を再実行します。

より大きな GDD の章のチェックリスト

セクションは、次のビルドの決定に役立つ場合にのみ追加してください。聴衆、プラットフォーム、そして一文のピッチから始めます。コア ループ、コントロール、進行状況、世界または物語、アートとサウンドの制約、および技術的要件に従ってください。範囲内の各機能について、その所有者、プレイ可能な最小のプルーフ、およびチームが再実行できるテストを記載します。オプションのアイデアを別のバックログに移動します。