2015年03月18日の日記です


手相開発時の技術話(4)  2015-03-18 09:05:00  業界記

先に、僕は当時 awk が使えた、と書きましたが、手相占いの作成の際には awk が大活躍しました。


新人の仕事は、データ整理であることがほとんどです。

プログラムは余り書かせてもらえません。というか、データが多すぎて整理だけで日が暮れます。


…セガは大手だから「プログラマーの」新人が沢山いて、データ整理は新人の仕事でした。

中小メーカーだと、プログラマーって貴重だから、雑用アルバイトの仕事です。

もしくは、「企画」という名目の、雑用の仕事です。


まぁ、誰がやるんでもいいのですが、コンピューター使っていて、コンピューターなら簡単に出来るはずの作業を、なぜか人が延々と繰り返さないといけない。




そんなのコンピューターでやってよ、と思うでしょう。


でも、ゲームプログラマーって、C言語とか、それに類する言語使っていることが多いです。

これで作成したプログラムは、非常に高速に動作する。ゲームを作るのには非常に良い。


その反面、プログラムを組むのが非常に面倒で、デバッグも手間取ります。


そんな言語で、データ整理プログラムを書くのは大変なのです。

誰かが1日かかればなんとかなる作業をするプログラムを書くのに、1日以上かかってしまう。


それに、プログラマーは貴重なので、その貴重な能力を別のことに1日割くことはできません。

結果として、誰かが不毛な作業を延々と繰り返すことになる。




awk で組んだプログラムは、動作が非常に遅いし、できることも非常に限られています。


その代り、「守備範囲」のプログラムであれば、非常に簡単に作れる

うまく動作しない時のデバッグも、すごくやりやすい。



今なら awk よりももっといい言語があります。

でも、当時は awk が「知る人ぞ知る」言語で、perl はまだマイナーでした。ruby は登場前。


awk(1977) も perl(1987) も UNIX 由来のプログラム言語。

 awk を元にして perl が作られ、さらに ruby(1995)が作られています。


 awk は DOS に移植され、スキモノが使ってました。

 perl は当時はまだ基本的に UNIX 用だったので、それほど普及してなかった。

 (もちろん、CPANなんてありませんし、Linux も普及前なので、一部の人しか触れなかったのです)




それはさておき、手相の場合、主な「データ整理作業」は画像の整理で、主に次のようなものでした。



まず、誰かが作った UNIX 用のソフトがありました。

これを使い、デザイナーが描いた画像1ファイルを処理すると、System32 が使えるデータの形式で出力します。


このデータは、2つの出力に別れていました。

まずは、キャラクタ ROM に書き込むためのデータファイル。


そして、このファイルの中身がどのようなものか、標準出力に表示される「画像サイズ」などのデータでした。




ファイルの中身は、アセンブラプログラムの断片になっていました。

ここに、ラベルなどを付けて「画像アドレス」がわかるようにしたうえで、アセンブルします。


画像の差し替えの場合は、すでにラベルが存在している場所を探し出し、中身を置き変えます。


その後、このファイルを「アセンブル」して、画像データの塊であるバイナリを得ます。

このバイナリは、ROM サイズごとに複数に切り分け (UNIX の split を使用)、Intel HEX 形式(ROM にデータを入れる際に使われる形式)に変換します。




「標準出力」に表示される画像サイズなどは、先の画像データにつけられた「ラベル」と一緒にまとめて、データテーブル化します。

これにより、画像のサイズ、データアドレスがわかるようになるので、画像を表示できるようになるのです。


さらに、アニメなどで一緒に使う画像をひとまとめにして、「アニメ用テーブル」を作ります。

このテーブルは、アニメーションする画像群の数だけ出来上がります。


キャラクタ番号何番を、オフセット座標いくつで、何フレーム表示、というのを列記します。



さらに、アニメ用テーブルをまとめるテーブルを作ります。これが「キャラクタ番号」でアニメを表示するためのテーブルとなります。


ただ、キャラクタを番号だけで扱っているとややこしいため、番号を分かりやすい名前で定義します。

Cなら enum で行うところですが、アセンブラなので define の羅列です。



…と、ここまでが「データ整理」の作業。大変です。

こんなことやっていたら、プログラムを作る時間は無くなります。




僕は、手順を理解したところで awk にやらせるためのスクリプトを組みました。


デザイナーから貰った画像を、アニメで一緒に使うグループごとにディレクトリに入れます。

この時、ディレクトリ名が「グループ名」となります。

画像のファイル名は「キャラ名」になります。



ここまで作ったら、あとは awk スクリプト起動。

多数のファイルを次々ツールにかけ、アセンブラを起動し、バイナリを Intel HEX 化し、キャラアドレス・キャラ番号まで作り上げます。


アニメのフレーム数などの指定は無いため、アニメーションテーブルは手で作っていたのではないかな。

値を調整して終わり、という程度の雛形は吐き出していたかも。


ともかく、大変な作業の8割は、awk で自動化できた。


人がやっていると、データの差し替えなんかでミスをすることもありました。

でも、「差し替え」なんて面倒なことを考えず、毎回全部作り直すようにしていたので、画像ディレクトリの中さえ整理をしておけば、間違いのないソースを生成してくれました。


ただし、毎回全ファイルを処理していたので、時間はかかりました。


それでも、15分程度で終わったのではなかったかな。



グラフィックの人から画像データを渡されて、30分後に画面で表示して「動きました」なんて見せると、仕事が速いと驚かれました。

普通、午前中にデータ渡したら夕方に画面に表示される、とかだったのね。




こんな作業もありました。


手相は占いゲームだったので、膨大な文章データがありました。

こちらも、アセンブラのデータの形でソース内に入れ込んで処理、ということになった。


ところが、このアセンブラが…特定の漢字が入ると、動作がおかしくなる問題があったのね。


まぁ、具体的に言えば Shift JIS の 2byte 目が 0x5c の場合、それ以降の文字が化けます。

アセンブラが日本語対応していないという、ありがちな問題。

解決するには、その特定文字を見つけ出し、後ろに \ を入れてやればいいです。


これもデータ整理の問題なのですが、テキスト内から 2byte 目が 0x5c の漢字を探し出して、\ を後ろに入れた上でアセンブラのソースにする、ってプログラム作ったと思います。


これは、絵のデータ整理ほど何回も使うものではなかった。

でも、awk だとこういうプログラムは組みやすいので、すぐに作れる。




あぁ、そうだ。こんなのもあった。


画面に結果を表示するため「JIS 漢字を全部画像として持とう」ということになりました。

とはいえ、当時は Font って、ものすごく高かった。権利買えません。


しかし、著作権の問題もあるから、そのまま使うわけにはいかない。

ベクターフォントを 16x16 で表示したのを並べて、違うフォントだと言えるくらいまで手を加えて、それで使おうということになった。


でも、それを「すべての漢字」についてやるなんて言うのは、気が遠くなる作業。


そこで、画面表示する予定の占い文章の文字を全て1文字づつ切り出して、集計し、使っている文字一覧を作った。

これをテキストファイルにしてデザイナーさんに渡し、Photoshop にテキストを流し込んで文字一覧の画像を得る。


これなら、使わない文字を作業する必要はない。

こんな集計作業も、awk なら簡単です。



出来た画像は、多数の漢字を並べて1枚にしたものですが、ここから 16x16 で切り出して1文字づつにする、という部分まで処理したと思います。

画像の元になったテキストファイルがあるので、どこから切り出したのがどの文字か、もちゃんと紐づけられる。




他にも、そういう「1回しか使わない使い捨てプログラム」を何度も書いたと思います。

awk だけじゃなくて、tcsh なんかも使ってました。適材適所で。


ファイルをまとめてリネーム、とかいう作業が生じた時は、tcsh が便利だった。


デザイナーさんから貰うファイルは、たびたびファイル名の英語がスペルミスしていたりしたので、tcsh でリネームしたりね。

先に書いたように、画像のファイル名を元にソースを自動生成していたので、スペルミスがソース内に持ち込まれると気持ち悪いのね。



手相の時は perl は使いませんでしたが、awk ではちょっと力不足、と考えて、次のプロジェクトの時には perl を覚えました。


今でも awk 好きですけどね。awk の方が適した作業、というのもある。

適材適所で使っています。




ゲームプログラマーを目指している人は、何かこういう「困った時の強力な道具」をひとつは覚えておくと良いです。

絶対に役に立つから。


当時は awk くらいしかなかったけど、いまなら perl や ruby でもいいと思います。

Excel が強力な武器となることもある。状況次第で使い分けられるように、いろいろ覚えておくといい。


企画を目指している人も、不毛な作業をしたくなければ覚えるといいよ。

プログラマーが「やりたくない」雑用仕事は、どんどん企画に回ってくるからね。


#最初のほうに書いた通り、プログラマーは貴重なので、無駄な時間を使わせたくないのです。


だから、企画であっても多少のプログラム能力は無いと、苦労をすることになります。



ところで、こういう道具を使う時は、8割の作業を目指すのがコツ。


データ整理は、目的ではなくて過程です。

過程部分で完璧を目指して苦労するのは無意味。8割できたら後は人がやる、くらいにしておいた方が苦労を最小に出来ます。





書きたいと思っていたことは、大体書き終わった。


また思い出したら急に書くかもしれませんが、次は7月上旬ごろにまとめて書く予定でいます。


業務用ゲームも、発売が多い時期があるのね。

夏休み前に発売したゲームに関わっていたので、そのゲームは7月上旬で20周年になります。




同じテーマの日記(最近の一覧)

業界記

関連ページ

ST-V 開発環境【日記 17/11/16】

最近の同人【日記 15/04/06】

僕の担当部分【日記 15/07/11】

作り棄てる日々【日記 15/03/26】

作り棄てる日々【日記 15/03/26】

別年同日の日記

02年 3/18

05年 引越し見積もり

12年 女の子向け


申し訳ありませんが、現在意見投稿をできない状態にしています


戻る
トップページへ

-- share --

2000

-- follow --




- Reverse Link -