今回はゲームプランナーを目指すなら、絶対に作らないといけない資料。
「仕様書」の書き方について解説したいと思います。
そもそも仕様書って何？
鶴が一言で述べるならば、
各画面の機能の説明やこれが正解・不正解（または問題）をまとめた資料
と答えます。
なぜならば仕様書が
・ゲームデザイナーに必要なデザイン素材を用意してもらう
・デバッカーに問題やバグがないか確認してもらう
のに必要な資料として使われるからです。
この仕様書がないと、
どんな機能・仕組みを作ればいいか分からない！
どういうデザインを描けばいいか分からないわ！
何が問題で、バクじゃないない挙動か判別できません
と、プログラマー、デザイナー、デバッカーが混乱してしまいます。
また人によって口で伝えたものだけでいざゲームを作ろうとすると解釈が違ったりします。
お互いの認識を合わせるために必要になるため、仕様書は必要不可欠のものなのです。
仕様書はどうやってまとめればいいか
では仕様書にはどういう内容がまとまっていればいいのか。
ずばり、
ゲームプログラマー・ゲームデザイナー・デバッカーが見て必要な情報がまとまっていること
です。
ただ仕様書は勤める会社によって
・使うツールが異なる
・まとめ方も人次第
となっているのが現実のため、一言にこういう風にまとめましょう・これを使ってまとめますという決まった答えがありません。
そのため、あくまでどういう内容をまとめればいいかという概要程度のものでお伝えいたします。
ゲームプログラマーに必要な情報
ゲームプログラマーに必要な情報は、
画面仕様書・フローチャートとなります。
画面仕様書というのは、その画面に必要な情報やどういう挙動をするのかをまとめたものです。
画面仕様書と仕様書が似てて混乱すると思うので、画面仕様書は仕様書の中にあるページの1つと思ってください。
例として、「LINE ディズニーツムツム」のプレイ画面の一部を鶴（つる）なりに仕様書としてまとめてみました。
このようにどんな機能があるのか。
どういう機能なのかの概要しかざっくり書いてませんがそれ以外にも、
・スコアやコイン獲得の計算式はどうするのか
・各演出はどういうイメージなのか
とまだまだたくさん書くことがあります。
ただゲームによりけりだったり、人によって見やすさなども変わるため一例としてみてください。
画面仕様書をまとめたら必要な情報や最低限度の挙動が記載されてるので完成と思うでしょう。
残念ながらまだまた足りません。
これだけですと、どういう時にどんな挙動をするのかが書かれてないため、それをまとめる必要があります。
それがフローチャートと呼ばれるものです。
先ほどの通常のプレイ画面のフローチャートを一部分だけ書いてみます。
ゲーム開始時のほんの一部分しかまとめてないのに機能として列挙して、フローチャートをまとめてみましたが長いですね。
フローチャートは機能が多いほど、複雑になりがちです。
見やすさを意識して細分化するか、情報を一つにまとめて整理するかなど画面によって書き方が問われます。
そのため、フローチャートは流れを書くだけではないということも念頭に入れておいてください。
ゲームデザイナーに必要な情報
ゲームデザイナーに必要な情報は
画面仕様書と素材発注書（デザインのイメージ）あれば問題ありません。
ゲームデザイナーはゲーム全体を見て、デザインイメージを考えながら各画面の素材を用意していきます。
画面仕様書をお渡しすると素材のサイズも問われますが、下手に記入しない方がいいです。
完成形の画面仕様書を渡してるわけでないため、デザインを用意してくれるゲームデザイナー側で最終的に決めてもらうとスムーズなためです。
そしてデザインのイメージは概要程度を添えるだけで問題ありません。
一発でデザインが決まることは少なく、徐々にブラッシュアップをかけて完成品を作っていくのがほとんどなためです。
また具体的にイメージがあるのであれば、参考例としてこれと近いものにしてほしいですという要望を出すでも問題ありません。
今回の参考にしたツムツムで、デザインのイメージを伝えるとしたらどうまとめるか。
鶴ならこういう風に伝えます。
・ゲームは簡単操作なパズルなのでUIはシンプルに
・ツムはポップでかわいいデザインで（イメージ：おまんじゅう）
・フィーバーは派手な演出にしたい（イメージ：ディズニーランドのエレクトリカルパレード的な）
・スキルはなるべくキャラの個性を捉えたものにしてください
（アラジンであれば魔法のランプという感じに）
これだけ！？
と思った人も多いと思いますが、具体的な例がない限りはほとんど抽象的な言葉しか出てこないのが事実です。
ただ抽象的ですと自分のイメージと相手のイメージが異なるため、共通のイメージになるように実際にあるものをイメージの参考例として添えましょう。
もし他にも要望があれば、デザインのイメージと併せて伝えます。
鶴が要望を添えるならば、簡単操作で遊べるパズルのため、一目で分かりやすいUIでお願いします
ですかね。
プレイ画面で重要なのは操作性と判断したためです。
これらの情報がまとまれば、ゲームデザイナー側で要望に沿った素材や画面構成をしてくれます。
デバッカーに必要な情報
画面仕様書と実際に動くゲームがあれば問題ないです。
そのため、こちらもゲームプログラマーやゲームデザイナーと同じ情報を渡すことになります。
もしチェックで重点的にしてほしい部分があれば、要望として伝える必要があります。
そういう場合はチェック要望をリスト化したものを渡したりします。
または逆にこういうチェックをするので資料や情報がないかという要望をされる場合もあります。
その場合は迅速に対応しないとチェックが遅れます。
俊敏な動きができるように相手の望むものを判断できるように意識してください。
そしてデバッカーのチェック（デバック）はスケジュール通りに開始できないこともあります。
もしそうなってしまったら、デバッカーに現状の共有と何がデバックできるか・いつまでにできるのかといった入念なやり取りが必要となります。
そういった俊敏性を求められることが多いため、日ごろから相手が何を求めているのかということを意識しているといざって時にすぐにやりとりできます。
仕様書は明確なルールはないけど、内容は決まっている
仕様書の書き方や使うツールは特にルールは会社によってなので、絶対にこれですというものがありません。
ですが、どんなジャンルのゲームでも内容は決まってます。
そのため、自分が書く仕様書には
・情報に何が必要なのかを見極める
・見やすさや内容の統一など何を優先としてまとめるか
を意識してまとめれば、確実です。
また就職してから仕様書をまとめる時も参考にしてるゲームが多いです。
そのため練習がてら、好きなゲームの特定の画面の仕様書をまとめてみてはいかがでしょうか。
では今回はこの辺で失礼します！
コメント