私自らが出る！

おはようございます。本日の当番、プランナーのN.F.Hです。
FはフロントのFになりました。
フロントと聞くと真っ先に昔遊んでいた横シューのオプションを思い出しますが、フ○ントじゃなくてフロントの話でしたね。

さてみなさん、目の前に３Ｄのマップを舞台としたゲームがあると
想像してみてください。
ジャンルやゲームの内容については問いませんが、
最近遊んだゲームが一番手っ取り早いでしょう。
そのゲームの一番前には何が表示されていますか？

プレイヤー？　ちょっと違いますね。
エフェクト？　それも違います。
そう、正解はウィンドウ画面です。多分。

多分と言ったのは適当ブッこいたわけではなく、最近ではゲーム的なウィンドウの表示をなくしたゲームや、ライフや弾数などの数値に変化があった時だけ、その情報を表示するというゲームが多くなってきているからですよ！？
世界観を見せるため、ゲームっぽさを出さないためなど、様々な意図やコンセプトがあっての仕様ですが、それらは逆に「ウィンドウが表示されるとゲーム的である」
という認識があってのことではないでしょうか。

そういった「ゲーム的」という言葉の代表みたいなウィンドウですが、それはゲームとしての「顔」ともいえる重要な役割を持っています。
どういった状況で、どういった情報を、どのような手段で表示するのかを決めて、仕様書としてまとめるのはプランナーのお仕事の１つです。

こうやってできあがった仕様書を元にデザイナーにウィンドウのデザインなどを作成してもらうわけですが、仕様書を書き上げるだけでデザインを作成してもらえるというのは甘い考えです。
デザインを作成してもらう前に仕様書のコンセプトを説明し、デザイナーに自分の考えやアイデアをぶつけていくわけですが、その際にデザイナー側からよりよいアイデアを提案していただくこともありますし、冷ややかな眼差しで

「それが今重要か？」

と切り捨てられることだってあります。
自分が完成したと思っていた仕様書でも、
デザイナーから見れば穴だらけということもあります。
…っていうか過去に何度もそういった経験があり、何度も凹んだものです…

そういった穴を少しでも早く、なるべく多く埋めていくためにも顔をつきあわせ、デザイナーに仕様の説明を行って意見を吸収しつつ、仕様書に落とし込んでいき、よりよいゲームの完成を目指して行きます。

なお、こうしてできあがったデータを表示する仕組みなどをプログラマーに作成していただくわけですが、実際に表示された画面を見て問題があった場合に激しく責められるのもプランナーのお仕事です（涙）

※この話は私の過去の経験に基づいた話ですが、全てのゲーム開発の現場において同じような流れで開発が行われているわけではありません。