インディーズゲーム開発日誌2～3日目：軽視されるGDD

GDDっておいしいの？

画像引用：グッドデザイン賞 - Wikipedia

“Good Design Douyarou?”

ではありませんw

『Game Design Document』と呼ばれる
非常に大事な「ゲームを作るための辞典」みたいなものです！

一通りのコンセプトと最優先したいユーザー体験（UX）が開発チームの中で確定したら、ここに“全ての正解”の文章・絵・図を全部記録します。
もちろんこのドキュメント通りになるとは限りませんが、細部までの方向性は“チームで共通の認識として確定しているはず”なので、大きくゲームのコンセプトやUXがずれることはありません。

宮本茂さんのピクミン3開発秘話にもその大切さが記載されています。

一人や少人数で開発していると、重要なポイントだけ書かれた文字だけのドキュメントなどでも“不足しているゲームのイメージが脳内で補完されやすい”ので、開発しながら多少認識がずれても会話やちょっとした修正でどうにでもなるケースが多いです。
しかしながら、15人を超える開発チームになってくると“話を聞かない・理解できない人”がどうしても出てきてしまいます。
これは彼らには罪がなくて、チーム規模に応じてゲーム規模も大きくなりがちなのがゲーム業界あるあるなんです。
そうなると同じ単語でも認識齟齬が生まれたりと、ゲームのセールスポイントであった部分がどんどんと見失われます。
当然、会議やら口論やらで無駄な時間を使って、その場にいる数人だけの認識が修正されるのがノウハウがあまりないゲームデベロッパーあるあるなんですが…
これが、GDD（辞典）があるとそこを見返せば良いだけなので、より時間を有意義に使えるというわけです。

この“いつでも見返せる”というのが非常に大切で、
デジタルドキュメントだと作成者のディレクトリ
管理次第で埋もれやすいので、原始的ですが大きな紙に
印刷して壁に貼るのが一番有効的です。

画像引用：SMU Guildhall Studio Environment

こうすることにより、“嫌でも目に留まります”。
また、紙なら即修正が必要になった場合に直接書き込めるメリットもあります。

Project "Chamber"のGDD

開発者は私一人だけなので、ちゃんとしたGDDなんて立派なものはいりません。
その前段階のキーコンセプトを整理する資料だけで十分なんですが…
一応は、本来のゲーム開発プロセスを復習したいという勉強目的もあります。

今回はアイデア整理用のドキュメントとGDDを合体させたものを作って、
個人製作において価値が最も高い”時間”を少しでも確保します。

では、個々のスライドの意味や何を作るべきかなどは『まめ知識・テクニック（有料記事）』カテゴリに入ってしまうので、ごく一部を説明なしにペシペシと貼り付けていきますねw

本来ならコンセプトなどが固まってから、GDD完成までに3人日とかかかるものですが、この手法なら1人日もかかりませんでした。
インディーズゲーム開発初心者ですが、いきなり2人日短縮できたのは上々なのではないでしょうか？

オマケ：ゲームデベロッパーで働いてた頃の資料作り

今でも運用中のゲームなので一部ぼかしますが、こうやってスケッチブックに“目で追えるように”様々なコンセプトや仕様を書き散らしていました。
ER図とまでいかないにしても、相関図にすることにより矛盾点や影響範囲が洗い出しやすくなるので、最終的な資料に起こすときにチームに共有してもすぐに理解してもらえるものができやすいです。

この文量でnote続けられるんですかね？w

正直、この調子だと途中でnote投げ出しそうですw
なんとかして、ほどほどな記事にしたいですね。
性格上、難しそうですが…w