仕様書を書く時、初めにする事、その前にする事

はじめに

　ゲーム開発でプランナーという仕様書を書く仕事をそこそこ長くやっています。
　この仕様書、書き方を学ぶ事が少ないらしく。
　この記事では、仕様書の書き方全部ではなく、仕様書を書く際に「初めにする事」と「その前にする事」について書こうと思います。
　物事は初めが肝心なので。

初めにする事

「初めにする事」の方から説明しますね。「その前にする事」はこの後で。
　まずは目次を作ります。
　もし、同じようなゲームの仕様書を入手する事ができる場合は、その目次の形式をそのまま使い、作成時に少しずつ変えていく、という方法で問題ないと思います。
　ただ、そういう環境の方は、この記事に興味を持たれないかな、とは思いますけど。

大目次　大きな項目の目次

　目次は、大目次と小目次という２階建の構造とします。
　テーカン時代に、上田さんからこういう風に教わりましたので、ひとまずそのままの形で。
　ざっくりとした分類で良いと思います。
　特定の項目がやたらと小目次の量が多くなる事になっても、それは次のプロジェクトでうまくやるためのステップ、くらいに考えておけば良いです。
　あまりココで考え込むと先に進めませんから、さっさと進めましょう。
　でも、何を書いて良いか分からぬ、ぐぬぬ、ってなるケースもあると思います。この先で説明する「その間にする事」を行うと、やりやすくなると思います。

小目次　各項目の目次

　大目次の内容で、わかる範囲の目次を作ります。
　ここも、目次を作るのはゲームの全体把握ができているかをチェックくらいのものと捉えて、詰まったら「その前にする事」をもう一度見直すと良いと思います。
　大体、ゲーム開発は流動的に進みますから、後から項目を増やしていくのも良くある事です。今の段階で分かる範囲を書いていけば良いと思います。

大目次と小目次の番号

　1-1という、大目次番号-小目次番号、という形式で付けると教わりました。

現在の書き方

　以前はテキストエディタで書いていましたが、最近はmacのNumbersという表計算ツールで書いています。Excelと違い、一つのシートの中に複数の表を置く事ができますので、正方形セルや、セル結合を使わなくても割と整った書式に仕上げられます。
　一つのファイルに一つの項目を記載しています。
　ファイル名は「プロジェクト記号」＋「項目番号」＋「項目名」という形式です。
　TR010doc02_ゲーム概要.numbers　これは、Plants With 5 Elements というゲームの仕様書のファイル名の例です。
　プロジェクト記号に"doc"が付いて、その後の02が項目番号になっています。
　この辺りは、やりやすい方法で良いと思います。
　プロジェクト記号を付けているのは、ファイル名でプロジェクトが判別できるように、番号をつけているのは「項目名」だけだと探し難いからです。
　必要な項目が増えると、順次番号を増やし項目を追加しています。

その前にする事

　さて、目次を書こうと思ったら「このゲームにどんな要素があるんだっけ！？」という思いに囚われて、目次を１行も書く事があったら、あるいは、似たような思いを少し思ったら、こちらの項目が参考になるのでは、と。
　おそらく仕様書を書く段階に来ているのでしたら、企画書があると思います。
　基本的には、その企画書の内容を目次に落として行けば良いのですが、多分、それだけでは抜けが起こる可能性があるかと。
　その抜けをある程度防ぐための方法として

• プレイ年表

• ゲーム要素の関係図

• 画面遷移の大まかなフロー

　の３種類（のラフ）を作る事をお勧めします。
　では、順番に。

プレイ時間を軸とした大まかなゲーム全体の流れ。プレイ年表。

　プレイヤーが初めてゲームを開始して、もしエンディングがあるなら、そこまで。
　あるいは、初回リリースの終わりの部分までなどのプレイヤー視点でのゲームの流れを書いたものです。
　時間は想定するプレイ時間です。
　シナリオがなかったり、マップの広さや種類が決まっていなかったりするかも知れませんが、その辺は、こういう風になるんだろうな、という程度の粒度で決めて行けば良いと思います。
　プレイ時間が何時間必要とか、プレイルートが複数あるとか、そういうのも織り込んでおくととても良いです。
　これで何が分かるかというと、プレイヤーが遭遇するイベントの概要が見えてくる、という点です。
　プレイヤー視点で、どんなゲームかを「想像の上」ですが体験する事ができるのは、作るゲームのメタ認知として有用だと思います。
　プレイ年表はゲームの難易度設計でも使用します。
　この辺は「ターン制RPG戦闘演算ノウハウ」で詳しく説明しています。

ゲーム要素の関係図

　これは、お金など他の流通する単位の流れなど。特に新規要素である場合必要度が高いと思います。
　古典的なRPGのお金を例に上げると、戦闘勝利（お金入手）→お店で武器を買う（お金消費）という流れです。
　他にお金に関わる要素があれば、入手と消費という矢印で結んでいきます。
　同じようにHPや魔力などのパラメータの流れで新規のものがあれば、それを入れる必要があると思います。

　仮定のゲームのゲーム要素の関係図です。
　戦闘で魔獣から各部位を取って、それを元に素材合成、売却してお金や魔法力の素を得る、という部分の図です。

仮定のゲーム要素の関係図

画面遷移の大まかなフロー

　企画書にある内容や、類似するゲームの仕様書などから、画面の種類とその遷移を大まかに描写したフローです。
　大まか、というのは、ある程度のカテゴリを一つの画面とみなす、という意味です。

おわりに

「その前にする事」はゲームのジャンルによってはもっと多いかも知れません。
　ゲーム全体を俯瞰する、という気持ちで企画書を読み込んで、それを実現するための仕組みはどのようなものか、各仕組みの相互関係はどうなるのが良いか、などを考えていくと、この記事で不足しているものが見えてくるのでは、と思います。

　目次ですが、大目次を一通り書いたら、上司に見せて、過不足の確認をして貰えたら、一層良いと思います。
　経験を積んだ方なら、目次を見ただけで、不足している項目を言ってくださる筈です。

　ゲームを作っている方、作ろうとしている方の一助になれば幸いです。