ゲームデザインドキュメント テンプレート：1枚から始める設計書の作り方
要約
ゲームデザインドキュメントは、1枚に収まる小さなものから始めるべきです。ピッチ、コアループ、プレイヤーの動詞、ワールド、システム、スコープ、未解決の質問の7ブロックで十分です。コアループは時間付きの一文で書き、動詞は一つ削ってみてください。生成されるワールドでは、制約とプロンプトの種をドキュメントに残すことで、再現性のある設計になります。
ゲームデザインドキュメント テンプレートは、1枚に収まり、ゲームが必要とする分だけ育つものが理想です。まずは7つのブロック（ピッチ、コアループ、プレイヤーの動詞、ワールド、システム、スコープ、未解決の質問）から始めてください。ひと晩で埋められます。今月中にプロトタイプで試せないものは削りましょう。この記事の残りでは、そのテンプレート本体と、多くのガイドが触れない部分を扱います。
なぜ多くのゲームデザインドキュメントは2週目で力尽きるのか
40ページの設計書を想像してください。きれいな表紙、目次、誰も頼んでいない世界観の章。ところが2週目には、プロトタイプは設計書から離れていき、ドキュメントは化石になります。
本当の失敗はそこにあります。セクションが足りないのではなく、ファイルが正しさを保てなくなるのです。GDDは作業道具であり、聖典というより変更履歴に近いものです。ドキュメントとビルドが食い違えば、負けるのはドキュメントです。そして人は開かなくなります。
だから問いは「ゲームデザインドキュメントに何を書くべきか」ではありません。「自分が正直に更新し続けられる、最も小さなドキュメントは何か」です。
1枚で始めるゲームデザインドキュメント テンプレート
このアウトラインをコピーしてください。各ブロックは2〜5行にとどめ、最初の版ではそれ以上書かないようにします。
ピッチ。 初対面の人が繰り返せる一文。例：「潮の満ち引きで毎晩地図が書き換わる、協力型の港町」
コアループ。 1分以内にプレイヤーが何度も繰り返す行動。動詞の円として描いてください。
プレイヤーの動詞。 5〜8個。機能ではなく動詞で書きます。登る、交易する、隠れる、分岐する、修理する、など。
ワールド。 場所、雰囲気、常に成り立つ3つのルール。天候もルールとして数えます。
システム。 動詞を面白くする2〜3個の仕組み。経済、ステルス、クラフトなど、ループを支えるもの。
スコープ。 何を出荷し、何を削り、何をストレッチゴールにするか。それぞれに日付を添えます。
未解決の質問。 まだわかっていないことの正直なリスト。このブロックがページで最も価値があります。
あえて入れていないものに注目してください。マネタイズ、マーケティング計画、キャラクターの生い立ちの章などです。それらは別ファイルに書けばよく、プロトタイプがループを証明してから書けば十分です。公開されているテンプレートの多くがそこから始めるため、設計書が完成しないのです。
チームの承認が必要な場合の長い構成については、GitBookのゲームデザインドキュメントの書き方ガイドが古典的な章立てを示しています。1ページ版から始め、プロトタイプで裏付けられた分だけ詳細を足すという助言は正しい方向です。
コアループのセクションに本当に書くべきこと
形容詞は省きましょう。ループは時間付きの一文で書きます。
40秒の採集 -> 桟橋に運ぶ -> 素材を交換して強化を1つ得る -> 潮が変わり地図が変化 -> 繰り返す声に出して読んでみてください。どこか一つの段階が死んでいると感じたら、それが最初のプロトタイプの課題です。すべて良さそうに聞こえるのに、プレイヤーがなぜ戻ってくるのか説明できないなら、ループには理由が欠けています。その場合は段落の中に埋もれさせず、未解決の質問として書き出してください。
私が使っている基準があります。ループの文は1行のテキストに収まるべきです。段落が必要なら、それは二つのループであり、二つのゲームをデザインしていることになります。
どのセクションなら迷わず削れるか
容赦なく削りましょう。ソロや2人のプロジェクトなら、初日に次を外せることが多いです。
キャラクターの詳細な経歴。 名前、欲しいもの、欠点だけ残します。詳しくは、ビルドに登場したときに書けば十分です。
レベルの詳細な説明。 部屋ではなく、レベルのルールを書きます。
プラットフォームやマネタイズの章。 ループが機能するまで保留にします。
アートバイブル。 参考画像3枚とパレットがあれば足ります。
72時間のゲームジャムに出すなら、ピッチ、ループ、動詞がドキュメントのすべてで構いません。パブリッシャー、コンソールの認証プロセス、深夜に質問できない外注スタッフがいるなら、フルリストを残す価値があります。
Unityのゲームデザインドキュメント テンプレートのPDFは、チームが関わるときにメカニクスやオブジェクトの振る舞いをどう書き残すかの参考になります。チェックリストとしてではなく、カタログとして読んでください。
ドキュメントはどこに置くべきか
毎日編集する場所に置いてください。当たり前に聞こえますが、差分が取れないPDFに眠っているGDDがどれほど多いか見てみてください。
見出し、タスク用のデータベース、変更履歴を備えたツールを選びましょう。データベース型のメモアプリは、未解決の質問やスコープの一覧を、腐っていく箇条書きではなく追跡可能な項目に変えられるので相性が良いです。
リポジトリ内のプレーンなMarkdownも良い答えです。コードの隣にあり、差分がきれいに出て、プルリクエストの中で更新を忘れにくくなります。難点は、技術者でないチームメンバーが触りたがらないことです。
どちらを選ぶにせよ、1ページの要約を一番上に置き、詳細は別ファイルにリンクしてください。ページが地図で、ファイルが土地です。
エンジンによって書く内容は変わるか
多少は変わります。エンジンによって、安く作れる動詞と高くつく動詞が決まるので、システムとスコープのブロックにはそのことを率直に書くべきです。
フル3Dエンジンで大規模なアセットパイプラインを使うなら、スコープにはアセットのカテゴリごとに行が必要です。コンテンツこそ、スケジュールが崩れる場所だからです。
ロイヤリティ計算の要らないオープンソースのエンジンを使うなら、スコープブロックはもっとシンプルになります。ライセンスの行は不要ですが、自分で作る機能については実のあるメモが必要です。
メカニクスが緻密な2Dゲームなら、コアループのセクションがほぼすべてを担います。小さく読みやすいゲームには、小さく読みやすいドキュメントが合います。
どのエンジンが勝者かを決めるのが目的ではありません。「使用エンジンとツール」は捨て行ではなく、エンジンが何を簡単にし、何を面倒にし、何を作らないと決めるかを列挙すべき欄なのです。
自ら生成するワールドのGDDはどう書くか
ほとんどのテンプレートにあるのがこの欠落です。すべての木を手で置くことを前提にしているのです。
ワールドがプロンプトから生成されるとき、設計書の形が変わります。部屋を指定するのではなく、制約を指定することになります。エンジンが生成しうるすべてのワールドで必ず成り立つことと、変化してよいことを書くのです。
1ページ版に次の2つのブロックを足してください。
ワールドの制約。 決して破ってはならないルール。「どの集落からも2分以内に水場がある」「行き止まりのクエスト地点は作らない」など。
プロンプトの種。 実際に使った正確なプロンプトを、ドキュメントの一部として保存します。
種の実例はこうなります。
霧がかった低潮時の港町。灯台が一つ、狭い階段、屋根の間を結ぶロープの橋。まだ人影はないプロンプトを保存し、返ってきた結果を保存し、どこを分岐させたいかをメモしてください。プロンプトは仕様であると同時に変更履歴にもなります。分岐させ、一つだけ変えて、何が起きるかを見る。その差分をドキュメントに書く。この習慣があれば、生成されたワールドを論理的に扱えるようになり、チームには漠然とした雰囲気ではなく、批評できる具体物が手に入ります。
注意点があります。生成の品質はツールによって大きく違い、業界全体でまだベータの機能もあります。すべての種の横に、バージョンと日付を書いておきましょう。その結果が再現可能なのか、たまたま当たった結果なのかが分かるようになります。
ループを検証する手早い方法
新しいアイデアで私が実際にやる、夜の作業手順はこうです。
1ページ版を30分で書きます。読み直さないでください。
ピッチと世界のルール3つをプロンプトにして、空間の最初の版を生成します。
その空間でコアループを、手作業でも粗いプロトタイプでも歩いてみます。
手応えがなかった段階すべてに印をつけ、未解決の質問に入れます。
動詞を一つ削ります。必ず一つ削ってください。
削ることこそ、人が飛ばしがちな部分です。増え続けるだけの設計書は、やりたいことの願望リストにすぎません。動詞を一つ抜くと、残りの動詞がより多くの役割を担うことになり、どのシステムが実際に仕事をしていたのかが見えてきます。
2週目以降もドキュメントを生きたままにするには
心がけることは3つ。どれも大げさではありません。
未解決の質問には日付を入れましょう。 3週間以上前から未解決のままの質問は、答えを出すか、避けていることを認めるかのどちらかです。
ビルドと同じ時間にドキュメントを更新しましょう。 あとでは駄目です。「あとで」が化石を作ります。セッションの最後に2行直すだけなら1分で済みます。
ドキュメントの末尾に「捨てたアイデア」の一覧を作りましょう。 同じメカニクスを毎月議論し直すのを防げます。そして、「ノー」と言ったことで実際にどれだけ作り上げてきたかが見えると、意外なほど励みになります。
新しいメンバーが参加したら、まず1ページ版を渡し、どこで混乱するかを観察してください。混乱のたびに、ドキュメントに足りない一行が見つかります。
実際に使うならどれか
一人、あるいは二人のチームなら、7ブロックの1ページ版とプロンプトの種のリストで、最初の1か月は十分です。チームがいるなら、1ページ版を玄関として残し、プロトタイプが正当化するたびにシステムやコンテンツの別ファイルを足してください。パブリッシャーがいるなら、長い版を渡して構いませんが、あなたが信頼する版は1ページ版であり続けます。
今夜、白紙のページを開いてピッチを書いてください。一文です。そのあとに、時間付きのループを書きます。30分で終わらないなら、そのアイデアはまだ夢のままです。一か月かける前にそれが分かるのは、役に立ちます。