Geistburg

想定通り、頭が作曲モードに切り替わってBGMの増備をやっているので、ゲーム本体に目に見える進捗はない。


本稿では暇潰しに、ささやかな差異を含みつつもゼビモドキ以来踏襲している拙作における敵キャラクターの管理手法と、関連して、今更気づいたMSXの謎仕様について触れる。MSXのゲームプログラミング自体に関心のない人からすればどうでもいい話になるが、それを言ったらボクの書くことはすべてそうだ。

今日的なビデオゲーム開発においては……ここでいう「今日的な」は、ゲームプログラマは自身でメモリの物理アドレスを意識することがない、の意味になるが……敵、に限らずゲーム上のキャラクタは、そのデータ構造の雛形から登場毎にメモリ上のどこかに生成（コピー）され、必要がなくなれば削除（当該メモリの解放）されるもの、ということになる。

主にプログラマから見て予測不可能なメモリ確保のオーバーヘッドを回避してパフォーマンスを向上させるために、今日においても予め確保済みの枠から必要に応じてキャラクタに割り当てる手法は普通に存在するが、この場合でも通常プログラマはそれがメモリのどこであるかは意識する必要がない。

対して、MSXを含む、プログラマが直接メモリの物理アドレスを管理するゲームプログラミングにおいては、予め一定範囲（このサイズが同時登場キャラクタ数の上限になる）のメモリを確保しておいて、必要に応じてその中から1キャラクタ分のメモリを利用する、といったことをおこなう。

この枠組みの中では、ゲーム中の任意の場面において新たなキャラクタを登場させるに際し、上述の一定範囲（実体として項目×キャラクタ数の表構造になるので、ボクは管理テーブルと呼ぶ、以下同）の中から、現時点で使用されていないアドレスを探し出す、あるいは現時点で上限に達しているのでこれ以上キャラクタの生成は出来ないと判断する処理が必要になる。

常日頃言っているように、これもまたくだらない車輪の再発明に過ぎないのだが、ボク個人の体験としてはドラコニックスロウンの開発に際し確立した方法論を使い回している。一見してドラコニックスロウン、佛陀斬、INQ&SUQは横スクロールシューティングという共通点を除けばまったく異なるゲームだが、実はアセンブラレベルの実装はほとんど共通している。

さて、MSXにおいてキャラクタと言えば何はさておきスプライトなのだが、拙作における敵キャラクタ管理テーブルは、MSXの基本仕様の1つとなるスプライトアトリビュートテーブル（のメインRAM上のコピー）の拡張を基本としている。

スプライトアトリビュートテーブルは、32枚あるスプライトそれぞれについて、その表示位置2バイト、表示パターン番号1バイト、表示色＋付加情報1バイトの計4バイトが順に並んでいる総計128バイトのデータ構造だ。MSXにおいてスプライトを動かす、というのは、VRAM上のスプライトアトリビュートテーブルの位置情報の値を更新することに他ならない。