さて、その１で表示系と操作系について考えましたが、この後は実際のゲームの「ゲーム」としての
部分を作る作業に入らなければなりません。しかし、これに関しては本当にゲームによって
まちまちでして、強いて言えばアクション系、シューティング系は結構似ているかもしれない、とか
アドベンチャー系とＲＰＧ系はフラグ立ての部分が似ている、といった位で本当にゲームによって
違ってきます。そこで、ここでは具体的な説明はしないことにしてその部分の作成時の考え方
等を提示してみたいと思います。
まず、必要なことなのですが仕様を良く見る、という事です。重要なことですが、この段階で仕様
がある程度出来上がっていないとここから先にはプログラマは進めません。仕様書きとプログラマ
が同一の場合はここでプログラムの手を休めて仕様書きに入らなければなりません。大体この
辺で出来上がるゲームの最初から最後までの大まかな部分の説明位が必要になります。
というか、後は仕様が出来上がったらそれを順次プログラムしていく、といった形になります。
で、仕様が来たらどんなデータが必要かをデザイナーさんやコーディネイターさんと話し合い、その
データをデザイナさんに作成してもらうことになります。作成してもらうデータの詳細はプログラマが
決めなければなりません。何故なら、コーディネイタには実際に使用するデータの詳細は関係無い
し、デザイナサイドでも、どんなデータを渡せばよいのかがわからないからです。ここでは表示部分
作成時に既にデータ構造等が決まっているので、その時に決めた事柄をデザイナチームに
伝えます。
或いは場合によってはデザインでは無くシナリオデータが欲しくなる場合もあります。この場合は
普通、自分の決めたシナリオデータを吐き出すツールなどは市販されていないので、自分で
作ることになります。ここでは別にツールを作ってもよいし、何らかの形式からのコンバータを
作っても良いのですが、そのデータを入力する人がコンピュータに余り慣れていないような人の
場合はツールを作ってあげましょう。こういう場合にはDelphiやVisualBasic等の開発ツールが
大いに役に立ちます。
さて、デザイン、或いはシナリオデータが来たらそれをプログラムに取り込みます。
最初に仕様が来た時に何を作るかはわかっている筈なので、プログラマサイドはデザインが
上がるまでにはその部分の仕様をこなす汎用的なプログラムを上げておきます。但し、この
プログラムは別に最終バージョンである必要は特にありません。ただ、Ｃならはっきり個別の
関数として定義しておきましょう。そして関数のインターフェイス部をしっかりデザインしたら、
中身は一時的なものでもＯＫでしょう。中の処理が変わってもインターフェイスが変わらなけ
れば他の部分には影響を与えないからです。また、こういったプログラム設計はバグ取りの
時にも結構役に立ちます。
で、こうやって個別に来る仕様をプログラムに組み上げていくわけですが、単体テストが段々
やりにくくなってくるので、起動時に表示されるメニュープログラムをサクッと作ってしまいます。
このメニュープログラムはどうせ後で消す物なので、簡単に作った方が良いです。こんな物に
時間をかけてはいけません。で、このメニュープログラムから各仕様の実装へジャンプし、各
仕様を実装したプログラムは、取りあえず現時点ではこのメニューに戻ってくるように作ります。
また、ＲＰＧ等のパラメータが絡んでくる物では必須なのがデバッグモードです。しかし、これは
出来るだけプログラマの秘密にしておきます。結局最終的にはプログラマもテストプレイヤー
の真似事をする事になるので、本来のテストプレイヤーの皆さんには本来の難しさでプレイ
して貰い、難易度等もチェックして貰わなければいけないからです。
実際問題、こうやって夫々個別の仕様を作り上げていって最後に連結させてしまえば
ゲームが一本出来上がるんですね。簡単そうですね。でも、バグは必ず出るといっても
良い物なので、この後に地獄が待っています。実際問題ここまではゲーム作りも楽しい作業
なのです。が、この後は特にプログラマにとっては地獄のデバッグが待っています。
デバッグですが、これは今までチームに関わってもらった人だけではなく、全然関係無かった
人にも頼みましょう。難易度や面白くない点が発見しやすくなります。又、人数が多ければ
それだけバグを発見する確立も高くなるという物です。で、メインのテストプレイヤーの皆さん
にはデバッグシートを配っておいて、バグの出た個所、症状、どうやったら出たか、再現性等
を細かく書いて貰います。家庭用ゲーム機の場合はテストプレイの最中はそのプレイをビデオ
にとっておいて、バグが出た場合はプログラマーにそのビデオを見せる、といった様な事を
して細かい状況の伝達に役立てるのですが、残念ながらWindowsの場合はそういった事が
出来る環境ばかりでは無いし、家庭用ゲーム機の様に320*240なんていう解像度でも無い
ので、やはりデバッグシートに細かく書いてもらうしか有りません。で、プログラマは
デバッグシートを見て状況を把握し、自分の所で再現させる事が出来たらもう取れたも同然
です。問題は再現性の無いバグで、しかも「何かしらんがとんだ」、なんて言われた日には
泣きたくなってきます。まぁ、どうしても取れないバグは仕方が無いのですが、取りあえず
取れるものは全てとっておきましょう。この段階ではまた、仕様変更も沢山来るでしょう。
全てゲームを面白くする為なので、頑張りましょう。また、自分でも遊んでみて、気に入らない
部分は皆に意見を聞いて（勝手にいじったら駄目です。そこが面白くないと思っているのは
プログラマだけかもしれないし、また何か意味のある場所かもしれません）、直す場合は
直しましょう。で、そんなこんなで納期が来て、それまでに仕上がってない場合は発売延期
になる訳ですね(^_^;。