プログラムの組み方について基本的なことは学びました。 しかし、単に思いつくままプログラムを組んでいては、 いつまで経っても質のよいゲームが出来ないだけでなく、開発効率があがりません。 特に就職や、インターネットなどでの公開を考えている場合、 思いつくまま組んだプログラムは見た目にも汚く、とても他人に評価してもらえるものではありません。 開発効率のいい、美しいプログラムを心がけましょう。
どんなゲームを作るかよく考えて下さい。学生が卒業研究などで作成するゲームで必ず失敗するのが 「何を作るのかよく考えないままプログラムを作り始める」という点です。 ゲーム業界では普通、企画書を作成し、企画会議などで検討が行われ、そこでGOサインが出たらゲームを作り始めます。 つまり、企画書だけでゲームのイメージが全て伝わらなければなりません。 そして企画を通すかどうかの判断は企画書を作った本人ではなく、企画部長や役員です。 また、企画が通ったらプロジェクトチームが立ち上がり、複数の人でゲームを作ります。 自分の頭の中にあるぼんやりとしたイメージだけでは絶対にゲームは作れません。
ということで、まず企画書の作成から始めていきます。開発期間は４月から１２月までの９ヶ月です。 間に夏期休暇が入りますので、実質７ヶ月くらいしかありません。この期間で開発できるものを企画して下さい。
ボリュームはＡ４サイズの用紙で２，３枚で結構です。１０枚、２０枚も書く必要はありません。
企画書は「ゲームのイメージを第三者に伝える」ものです。 それに対して仕様書は「プロジェクトチームのメンバーが見る」ものです。 企画書を元にゲームのルールや流れを厳密に決め、仕様書として書き出します。 仕様書を見て、プログラマはプログラムを作り、グラフィッカーはCGを作ります。 仕様書をしっかり作るかどうかで開発効率が大きく左右されます。 仕様書を作らないでプログラムを始める人に理由を聞くと必ず 「書くのが面倒」「頭の中で出来ているから大丈夫」と言います。 しかしそのチームは終盤になりかならず作業の遅れにより、ろくな物が出来ません。 では、何故失敗するのか？それは、作っていくうちに”自分の都合のいいようにルールを変えたり”、 ”最初に考えていたルールを忘れてしまう”ことはもちろん、作ってみて初めて”矛盾”に気が付くからです。 その”矛盾”が分かるたびに仕様を変更したりしていたのでは、いつまで経っても進まないだけでなく、 その変更により”矛盾が矛盾を生む”という悪循環にはまってしまいます。
しかし、ルールに基づいた全てのパターンを前もってシミュレートすることで、 この矛盾をなくすことが出来ます。そのためには、とにかく紙に書き残し、ファイリングすることです。 ゲームのルールや画面遷移図だけでなく、必要になる画像のパターンや音楽のリストなども作成します。 そしてそのファイルはメンバー全員が分かる内容でなければなりません。 これが出来れば全体の作業量が見えてきます。メンバー全員が仕様書を把握できたとき、 初めて作業に取り掛かれるのです。
仕様が決定したらプログラムですか？まだです。 プログラムチームはここで「システムフローチャート」を作成します。 これらを書くことで、プログラムの流れが把握できます。
プログラムの流れが把握できれば、どんな関数や変数が必要なのかが表現できます。 また、複数人でプログラミングする場合、システムフローチャートを元に作業分担を行います。 （って言うか、口答だけで作業分担は無理!!）
作業分担が出来たら、担当した部分（モジュール）の階層図を作成します。 これにより、ゲームルールやプログラムの矛盾が早期発見でき、 プロジェクトを円滑に進めることが出来ます。 モジュール階層図サンプル
ここまで準備が出来たらプログラミングに取り掛かれるでしょう。 とは言っても、設定の甘さからどうしても矛盾や足りないところが現れ、仕様変更が入ります。 変更点はすぐにノートに書き込み、資料として残しておきましょう。 プログラマは自分の好きなようにプログラムすればいいわけではありません。 他のプログラマと完全にリンクしながら進めなければなりません。 メンバー同士のコミュニケーション。これが一番大切なのかもしれません。
