MCL(78)

インデックスに戻る

前のMCLへ  次のMCLへ

▼ My Computer Life (78)

78. メインプログラマとして

 G1の開発がスタートし、約1か月ほどで大きな方向転換を迎えたわけだが、この1か月の間に、メインスタッフが決まってきた。

ディレクターTOM
企画TOM(メイン)&全員
プログラマTOM、じんべ
グラフィックくらち、K A M E
音楽ILL君68k、北GEN、N.Masuoka
面デザインK A M E 、ILL君68k、くらち、N.Masuoka、北GEN、TOM

 大きなところではこんな感じだが、他にも関わったメンバーはいる。例えばウチナーさんは、パブリッシングというか、あとは情報収集であるとか、そういうような事を色々やってくれたし、またOPAさんはテストプレイヤーとして結構意見を上げてくれた。テストと言う意味では、MXUGに関わらずMIYA-NETの人は色々と意見や感想を述べてくれたりしたので、関連するメンバーはたくさんいる。掲示板でちょっとした意見をくれるだけでも、結構参考になるので、間接的に携わった人は多い。
 また、上記の大きな区分以外に、結構みんな色々な分野に手を出していたりする。例えば、グラフィックに関しては、イラスト的なものをくらちさん、工業デザイン的なものをK A M E さんという感じでゆるやかに担当わけしているが、それ以外のメンバーも関わっている。例えば、主人公のデザインはILL君だし、またフォント・アイテム・爆風や敵弾などエフェクト系のスプライトは私が全部作っていた。それと、面デザインというところに主要メンバーがいるが、これは敵やブロックの配置とか以外にも、そのステージのオブジェクトや敵の画像ごと作成しているメンバーもいた。

 メンバー表通り、言いだしっぺの私の責任範囲は結構大きかった。ディレクターに、企画に、プログラマに、フォントやエフェクト他ある程度グラフィックデザインもしている。
 これは、元々ゲーム会社に勤めていたくらちさん以外ほとんどの人がそうだろうが、私にとっても特に、初めての経験だった。もちろんちょっとした趣味のゲームを作った事などはあったが、これだけ大掛かりというか、複数のメンバーが関わるゲーム制作でのディレクション・企画・プログラムというのは初経験だった。
 中でも、プログラムに関しては、自分の中ではやってみなければ分からないというものの筆頭であった。

 今回、G1は最初から最後までC言語で書いている。C言語は、私は「地獄のエイリアン伝説2」の時にゲーム開発に使い始めた。それ以降、大きなものは作っていないが、小さなものはポツポツとC言語では作っていた。
 で、その地獄のエイリアン伝説2は全く完成していないので、私にとってはG1が初のC言語で作る大きなプログラムになる。
 一応、C言語の理解度は、BASICと同等レベルには上がっていたが、そもそもBASICで大きなプログラムを組んだ事もないので、大きなプログラムを作る事自体が初挑戦と言っても良かった。
 結構、無謀な計画ではあった。

 で、前回の続きで、「なぜG1の方針転換を進めたのか」の話になるが、一番大きな理由は「もっと面白くしたい」だが、もう一つの理由として、「なんかプログラマとして行けそうな気がしてきたから」というのもある。
 正直、最初のゲームは完成重視の小さなものにしようと提案したのは、メンバーそれぞれのスキルや熱意の問題もあったが、もっとも問題だったのは私のスキルである。所詮アマチュアで、どれほどのものが作れるか自分でわかっていなかった。まあ自信家の私は、「必死に勉強すれば何とかなるだろ」みたいな気持ちでいたが、だからこそ最初のゲームは勉強として、とにかく作ってみるという気持ちでいたのだ。

 だが、プロトタイプとしてのG1ができた時に、「あれ、これ別に本格的なゲーム作れるんじゃね?」と思った。
 まだゲームとしては未完成だったものの、基本的なシステムはできた。プログラム全体の初期化と終了があり、またステージに入るとゲームが進行し、自分と敵がそれぞれ動き、目的を達成するとクリアになる。これだけなのだが、ここにゲームの基本が大体入っており、あとはこれの拡張で行けるじゃん、なんだ俺やれるじゃんとか言う手ごたえがあった。
 これは、今考えても特に間違っていないと思う。今現在では、当時より更にプログラマとしての技術は上がっているが、その視点から見ても、アクションゲームなどの開発でキーとなるポイントがいくつかあって、私はG1の開発初期にそれらを習得したように思う。なので、もうそのタイプのゲームであれば、ある程度複雑になっても作りきれるだけの実力はついていたはずだ。

 G1のプログラムは、98%ほど私が書いている。残り、ちょっとした部分をじんべさんに書いてもらっている。ただ、じんべさんの貢献が少なかったというわけではない。じんべさんにはむしろ、私のソースコードを添削していいただくという、重要なタスクをしてもらっていた。
 この時じんべさんは、職業プログラマとして働いており、キャリアとしては当然アマチュアの私よりずっと上だった。だが逆に、アマチュアで時間もある私がメインを務めるにあたって、じんべさんにはサポートとして、私のソースコードを色々見てもらった。

 こうして、じんべさんの添削を経て、私のG1のソースはだんだんまともになっていった。具体的には、以下のように変わっていった。

・ほとんどスペースを使わずに詰めて書いていたが、適切にスペースを入れるようにした。
・変数名が「n」「a」など意味不明だったものを、わかりやすくした。
・シンボルの命名に統一性がなかったのを、ある程度ルールづけした。
・ワーニングを無視し、特にプロトタイプとの型チェックを丸無視していたが、きちんと型チェックを行い、ワーニングを出さないスタイルにした。

 逆に言えば、最初はこれらが守れていなく、かなりメチャクチャだった。
 特に最後の、プロトタイプ宣言を無視して、型違いを許容するとか、今考えると全くあり得ない。
 プロトタイプ宣言とは、ある関数が、どの型の引数を何個受け取って、何型の返り値を返すかを「宣言」する事である。現在普及しているC++は、型チェックが厳しい言語なので、これを無視する事が不可能である。正しく宣言された通りに呼ばれていないと、エラーになる。JAVAやC#などの類似言語も同様だ。
 だが、C言語は歴史的な問題で、そこまで厳密ではない。プロトタイプの仕組みが取り入れられたのがANSI C以降であり、最初のK&Rと呼ばれるスタイルの時にはなかったので、その当時に作られたプログラムは、呼び出しが定義通りであるかどうかをチェックしない事を前提にしている。なので、ANSI C以降プロトタイプ宣言が入ったが、違反していてもエラーにせず、ワーニングで済ます。

 そのため、謎の不具合が都度発生していた。例えば、ある関数の引数が3つだったとして、ある日仕様変更して4つに拡張したとしよう。これはきちんとプロトタイプ宣言がなされていれば、古い引数3つの時代だった頃の呼び出しは発見できる。しかしそれをしておらず、ワーニングも無視していると、発見しづらくなる。その関数を引数3つで呼び出す事は、C言語では可能なのである。その際、新しく作られた4つ目の引数に何が渡されるか。これは不明である。恐らく動作上、スタックのゴミが入る。結果として良く分からない動作をしはじめるし、スタック形成ロジックの機嫌次第では、アドレスエラーを出す事もあるだろう。
 このようなミスは実際あった事で、じんべさんに発見していただいた。そういうのを経て、だんだんソースコードはまともになっていった。

 それでもまだ、稚拙なコードはたくさんあるが、それはまた後の回に書く事にしよう。


前のMCLへ  次のMCLへ

戻る

TOM 2014