古籏一浩氏の昔話【後篇】 ～ MZ-700版スペースハリアーの開発話

古籏一浩 @openspc

昔話：3D座標変換は一応できたので次に敵や障害物の拡大縮小処理です。当時は知りませんでしたが、本物の基板には拡大縮小機能なんて豪華なものはなくてパターンチェンジで処理していたとの事。はっきり言って騙されたと思いました。真面目に考えてしまいました。

古籏一浩 @openspc

昔話：なんにせよ当時はパターンチェンジだとは思っていなかったので割と真面目に処理するしかありません。ライン描画のアルゴリズムを応用して拡大縮小処理は可能です。が真面目に処理すると処理速度が低下してしまう事があります。また、mz-700ならではの問題もありました。

古籏一浩 @openspc

昔話：mz-700ならではの問題というのは画面が40文字×25行という粗さです。このため、普通に拡大縮小処理を行うと、敵や障害物が遠くにあると消えてしまう事があります。木の枝の隙間などは透明ですから運が悪いといきなりでかい木が出て来るという事になります。

古籏一浩 @openspc

昔話：そこで一工夫する事にしました。キャラクタの横幅は奇数(11文字)にしておき、その中心だけは透明にしないというものです。これならキャラクタが遠くにあっても１文字分だけは表示されるはずです。と思ってライン描画を応用してやってみましたが失敗しました。

古籏一浩 @openspc

昔話：ライン描画のアルゴリズムでは、どうしても中央の文字が表示されない場合がありました。いろいろ考えた挙げ句、真面目に処理しない事にしました。あらかじめ、どこを表示しないかをテーブルで用意しました。後はZ80のCPI命令を使って比較し表示処理をしました。

古籏一浩 @openspc

昔話：CPI命令を使ってどこを表示するかを処理することで期待通りの拡大縮小処理ができるようになりました。実際には大きいサイズのキャラクタを用意し縮小しているだけです。速度も思ったほど低下しませんでした。これで、ようやく移植の目処がついた事になります。

古籏一浩 @openspc

昔話：拡大縮小機能ができたところで次に実際に表示する物体を作成しないといけません。今ならばPhotoshopなどのツールがありますが、当時はそういったツールも自分で作成しなければいけません。XEVIOUSの時は画面に描いて転送しましたが、スペハリでは自作しました。

古籏一浩 @openspc

昔話：ツールといっても豪華なものではなく、左側に11×20サイズのキャラクタ作成画面。ここでカーソルを移動させて0〜7などのキーを押すと文字の色と背景の色が設定できるというもの。右側には作成したキャラクタを保存するアドレスを指定するだけというシンプルなものです。

古籏一浩 @openspc

昔話：最初に描いたのは1面に出て来る、あのでかい樹木です。緑色でだいたいらしく描いて、後は木の幹の部分を描いて完成。文字色と背景色をうまく組み合わせることで立体的な樹木になります。早速、プログラムに組み込みます。ちゃんと樹木が遠くから迫ってきました。

古籏一浩 @openspc

昔話：mz700版スペースハリアー。無事に樹木が遠くから近くに迫ってくるようになりました。次にハリアーの弾を出す処理を作成しました。これは、単純に弾をZ方向（奥）に向かって出すだけです。と書くのは簡単ですが、これまでの2Dのゲームにはない問題がありました。

古籏一浩 @openspc

昔話：2Dゲームにはない3Dゲーム特有のものとして奥行きがあるという点です。つまり2Dゲームのように単純に弾を表示しただけでは駄目でした。もし、2Dゲームと同じようにしてしまうと近くの樹木の上に遠くの弾が表示されてしまうという珍現象が発生します。

古籏一浩 @openspc

昔話：このためZ座標を元にしてソートする必要があります。これが、敵や弾が全部四角形で描画されていれば、うまくごまかす事ができるのですが、mz-700ではモザイク表示なので、それはできません。というか、実際に2Dの手法でやってみたら、やはり見た目に駄目でした。

古籏一浩 @openspc

昔話：スペースハリアーはZ座標順に敵や障害物、自分の撃った弾をソートする必要があります。ただ、これまで作ったゲームは敵は敵専用の領域（C言語なら構造体。オブジェクト指向言語ならオブジェクト）、弾は弾専用というように別個になっていました。

古籏一浩 @openspc

昔話：別個になっていたのは、その方が作りやすかったからというのがあります。基本敵にゲームはトップダウンで考えて必要なルーチンを書き出します。その後、ボトムアップで作ります。ばらばらになっていると1つずつ作ってうごかせるので楽でした。

古籏一浩 @openspc

昔話：スペースハリアーの場合は全部同じ領域に全てのデータを入れる必要がありました。こうすることで表示処理、移動処理は1ループでできるので高速化することはできます。ただ、使わないメモリ部分が出てしまい無駄が発生します。でも、その無駄は仕方がないということで、そのままにしました。

古籏一浩 @openspc

昔話：全部同じ領域に敵も自分のデータも入っているのでZ座標によるソートは簡単です。が、記憶ではソートはしてなかったはず。Z座標は小数値ではなく整数値で管理していて、単純に数の大きい方から表示する、というような仕組みにしてあったと思います。これだとソート自体が不要だからです。

古籏一浩 @openspc

昔話：これで、ようやく正しく奥行きが処理され疑似3Dゲームとして見られるようになりました。ここからは1面ずつ作成していくことになります。つまり、敵の動きもグラフィックも1面ずつ作っていくわけです。ただ、基本的な部分ができてしまえば完成までは早いものです。

古籏一浩 @openspc

昔話：スペースハリアーの敵のグラフィックは一度にまとめて作成していったわけではありません。1面から出て来る順番に作っていきました。また、当初完全に全部のキャラクタを出そうとは思っていませんでした。エンディングロールで出て来る敵が作成した順番になっています。

古籏一浩 @openspc

昔話：スペースハリアーの敵は、ほとんどのものがアニメーションしません。アニメーションする敵は1面で出て来る黒いトモスというキャラです。丸い状態で飛来してきて手前で花びらのように開きます。他には天井が下りてくる面に出て来るビンズビーンなど4つか5つだけです。

古籏一浩 @openspc

昔話：メモリの少ないmz-700にとって敵のアニメーションが少ないのは幸運でした。アニメーションすると、そのグラフィックの分だけメモリを消費してしまうからです。フロッピーもないマシンですので全てオンメモリで実現しないといけません。

古籏一浩 @openspc

昔話：とは言っても左右逆になっているものは処理速度などの都合で、あらかじめグラフィックで用意しなければいけませんでした。それでも、mz-700全てのメモリを食いつぶすこともなく全部入ったのは助かりました。余裕があったのでX68K版のキャラ（HAYAOH）も入れました。

古籏一浩 @openspc

昔話：敵キャラのグラフィックの作成と同時に敵の出現パターンも作成していきます。敵をどのタイミングで出現させるか、というのはタイミングカウンタを用意し、そのカウンタの値と一致したら敵を出すという仕組みになっています。ゼビウスの時と全く同じ方式です。

古籏一浩 @openspc

昔話：敵の出現タイミングが分かっただけでは駄目でした。というのも同じ敵でありながら、どこまで接近してくるか、どこから出現するかが微妙に異なっているためです。そこで、動かす敵の情報（データ）をメモリに転送し必要に応じて書き換えるようにしました。

古籏一浩 @openspc

昔話：オブジェクト指向ならクラス（敵）を実メモリに転送し実体化させる、という部分になります。そして、一部だけを書き換えて使うということです。マシン語だとオブジェクト指向は省メモリになるので都合がよい部分もあります。

古籏一浩 @openspc

昔話：敵の動きはアルゴリズムの番号で管理していました。（ソースコード中のALG35などALGとついているものがそうです）スペースハリアーのコードはシンプルで敵か障害物かなどの区別は無く共通のコードで行っています。ちなみにゼビウスでは全て別個でした。