先に、僕は当時 awk が使えた、と書きましたが、手相占いの作成の際には awk が大活躍しました。
新人の仕事は、データ整理であることがほとんどです。
プログラムは余り書かせてもらえません。というか、データが多すぎて整理だけで日が暮れます。
…セガは大手だから「プログラマーの」新人が沢山いて、データ整理は新人の仕事でした。
中小メーカーだと、プログラマーって貴重だから、雑用アルバイトの仕事です。
もしくは、「企画」という名目の、雑用の仕事です。
まぁ、誰がやるんでもいいのですが、コンピューター使っていて、コンピューターなら簡単に出来るはずの作業を、なぜか人が延々と繰り返さないといけない。
そんなのコンピューターでやってよ、と思うでしょう。
でも、ゲームプログラマーって、Ｃ言語とか、それに類する言語使っていることが多いです。
これで作成したプログラムは、非常に高速に動作する。ゲームを作るのには非常に良い。
その反面、プログラムを組むのが非常に面倒で、デバッグも手間取ります。
そんな言語で、データ整理プログラムを書くのは大変なのです。
誰かが１日かかればなんとかなる作業をするプログラムを書くのに、１日以上かかってしまう。
それに、プログラマーは貴重なので、その貴重な能力を別のことに1日割くことはできません。
結果として、誰かが不毛な作業を延々と繰り返すことになる。
awk で組んだプログラムは、動作が非常に遅いし、できることも非常に限られています。
その代り、「守備範囲」のプログラムであれば、非常に簡単に作れる。
うまく動作しない時のデバッグも、すごくやりやすい。
今なら awk よりももっといい言語があります。
でも、当時は awk が「知る人ぞ知る」言語で、perl はまだマイナーでした。ruby は登場前。
＃awk(1977) も perl(1987) も UNIX 由来のプログラム言語。
awk を元にして perl が作られ、さらに ruby(1995)が作られています。
awk は DOS に移植され、スキモノが使ってました。
perl は当時はまだ基本的に UNIX 用だったので、それほど普及してなかった。
（もちろん、CPANなんてありませんし、Linux も普及前なので、一部の人しか触れなかったのです）
それはさておき、手相の場合、主な「データ整理作業」は画像の整理で、主に次のようなものでした。
まず、誰かが作った UNIX 用のソフトがありました。
これを使い、デザイナーが描いた画像１ファイルを処理すると、System32 が使えるデータの形式で出力します。
このデータは、2つの出力に別れていました。
まずは、キャラクタ ROM に書き込むためのデータファイル。
そして、このファイルの中身がどのようなものか、標準出力に表示される「画像サイズ」などのデータでした。
ファイルの中身は、アセンブラプログラムの断片になっていました。
ここに、ラベルなどを付けて「画像アドレス」がわかるようにしたうえで、アセンブルします。
画像の差し替えの場合は、すでにラベルが存在している場所を探し出し、中身を置き変えます。
その後、このファイルを「アセンブル」して、画像データの塊であるバイナリを得ます。
このバイナリは、ROM サイズごとに複数に切り分け (UNIX の split を使用）、Intel HEX 形式（ROM にデータを入れる際に使われる形式）に変換します。
「標準出力」に表示される画像サイズなどは、先の画像データにつけられた「ラベル」と一緒にまとめて、データテーブル化します。
これにより、画像のサイズ、データアドレスがわかるようになるので、画像を表示できるようになるのです。
さらに、アニメなどで一緒に使う画像をひとまとめにして、「アニメ用テーブル」を作ります。
このテーブルは、アニメーションする画像群の数だけ出来上がります。
キャラクタ番号何番を、オフセット座標いくつで、何フレーム表示、というのを列記します。
さらに、アニメ用テーブルをまとめるテーブルを作ります。これが「キャラクタ番号」でアニメを表示するためのテーブルとなります。
ただ、キャラクタを番号だけで扱っているとややこしいため、番号を分かりやすい名前で定義します。
Ｃなら enum で行うところですが、アセンブラなので define の羅列です。
…と、ここまでが「データ整理」の作業。大変です。
こんなことやっていたら、プログラムを作る時間は無くなります。
僕は、手順を理解したところで awk にやらせるためのスクリプトを組みました。
デザイナーから貰った画像を、アニメで一緒に使うグループごとにディレクトリに入れます。
この時、ディレクトリ名が「グループ名」となります。
画像のファイル名は「キャラ名」になります。
ここまで作ったら、あとは awk スクリプト起動。
多数のファイルを次々ツールにかけ、アセンブラを起動し、バイナリを Intel HEX 化し、キャラアドレス・キャラ番号まで作り上げます。
アニメのフレーム数などの指定は無いため、アニメーションテーブルは手で作っていたのではないかな。
値を調整して終わり、という程度の雛形は吐き出していたかも。
ともかく、大変な作業の8割は、awk で自動化できた。
人がやっていると、データの差し替えなんかでミスをすることもありました。
でも、「差し替え」なんて面倒なことを考えず、毎回全部作り直すようにしていたので、画像ディレクトリの中さえ整理をしておけば、間違いのないソースを生成してくれました。
ただし、毎回全ファイルを処理していたので、時間はかかりました。
それでも、15分程度で終わったのではなかったかな。
グラフィックの人から画像データを渡されて、30分後に画面で表示して「動きました」なんて見せると、仕事が速いと驚かれました。
普通、午前中にデータ渡したら夕方に画面に表示される、とかだったのね。
こんな作業もありました。
手相は占いゲームだったので、膨大な文章データがありました。
こちらも、アセンブラのデータの形でソース内に入れ込んで処理、ということになった。
ところが、このアセンブラが…特定の漢字が入ると、動作がおかしくなる問題があったのね。
まぁ、具体的に言えば Shift JIS の 2byte 目が 0x5c の場合、それ以降の文字が化けます。
アセンブラが日本語対応していないという、ありがちな問題。
解決するには、その特定文字を見つけ出し、後ろに \ を入れてやればいいです。
これもデータ整理の問題なのですが、テキスト内から 2byte 目が 0x5c の漢字を探し出して、\ を後ろに入れた上でアセンブラのソースにする、ってプログラム作ったと思います。
これは、絵のデータ整理ほど何回も使うものではなかった。
でも、awk だとこういうプログラムは組みやすいので、すぐに作れる。
あぁ、そうだ。こんなのもあった。
画面に結果を表示するため「JIS 漢字を全部画像として持とう」ということになりました。
とはいえ、当時は Font って、ものすごく高かった。権利買えません。
しかし、著作権の問題もあるから、そのまま使うわけにはいかない。
ベクターフォントを 16x16 で表示したのを並べて、違うフォントだと言えるくらいまで手を加えて、それで使おうということになった。
でも、それを「すべての漢字」についてやるなんて言うのは、気が遠くなる作業。
そこで、画面表示する予定の占い文章の文字を全て1文字づつ切り出して、集計し、使っている文字一覧を作った。
これをテキストファイルにしてデザイナーさんに渡し、Photoshop にテキストを流し込んで文字一覧の画像を得る。
これなら、使わない文字を作業する必要はない。
こんな集計作業も、awk なら簡単です。
出来た画像は、多数の漢字を並べて１枚にしたものですが、ここから 16x16 で切り出して１文字づつにする、という部分まで処理したと思います。
画像の元になったテキストファイルがあるので、どこから切り出したのがどの文字か、もちゃんと紐づけられる。
他にも、そういう「１回しか使わない使い捨てプログラム」を何度も書いたと思います。
awk だけじゃなくて、tcsh なんかも使ってました。適材適所で。
ファイルをまとめてリネーム、とかいう作業が生じた時は、tcsh が便利だった。
デザイナーさんから貰うファイルは、たびたびファイル名の英語がスペルミスしていたりしたので、tcsh でリネームしたりね。
先に書いたように、画像のファイル名を元にソースを自動生成していたので、スペルミスがソース内に持ち込まれると気持ち悪いのね。
手相の時は perl は使いませんでしたが、awk ではちょっと力不足、と考えて、次のプロジェクトの時には perl を覚えました。
今でも awk 好きですけどね。awk の方が適した作業、というのもある。
適材適所で使っています。
ゲームプログラマーを目指している人は、何かこういう「困った時の強力な道具」をひとつは覚えておくと良いです。
絶対に役に立つから。
当時は awk くらいしかなかったけど、いまなら perl や ruby でもいいと思います。
Excel が強力な武器となることもある。状況次第で使い分けられるように、いろいろ覚えておくといい。
企画を目指している人も、不毛な作業をしたくなければ覚えるといいよ。
プログラマーが「やりたくない」雑用仕事は、どんどん企画に回ってくるからね。
＃最初のほうに書いた通り、プログラマーは貴重なので、無駄な時間を使わせたくないのです。
だから、企画であっても多少のプログラム能力は無いと、苦労をすることになります。
ところで、こういう道具を使う時は、８割の作業を目指すのがコツ。
データ整理は、目的ではなくて過程です。
過程部分で完璧を目指して苦労するのは無意味。8割できたら後は人がやる、くらいにしておいた方が苦労を最小に出来ます。
書きたいと思っていたことは、大体書き終わった。
また思い出したら急に書くかもしれませんが、次は７月上旬ごろにまとめて書く予定でいます。
業務用ゲームも、発売が多い時期があるのね。
夏休み前に発売したゲームに関わっていたので、そのゲームは７月上旬で２０周年になります。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |