1セクタゲーム作成に挑戦

世の中には1セクタ分のサイズ、512バイト制限で作るゲームがあるらしいとのこと。

ファンダムの1画面プログラム的なものでしょうか。面白そうなので挑戦してみます。

後先考えずに始めているので、完成まで持っていけるかどうかは分かりません。

実行方法を考える

ブートセクタに書き込んで、電源スイッチON、フロッピー読み込み、ゲーム開始。こんな流れがスマートでしょうか。

早速ブートセクタの詳細を調べてみます。

うーん、ゲームをブートセクタに配置するにはなんとも中途半端ですねぇ。

1セクタの容量を使いたい場合は、自力で1セクタの読み込みをする必要があるのかな?

C001H～C01DHの29バイトの空きも微妙です。

などと考えていると、ブートセクタに配置するのはテストが面倒になることに気付きました。アセンブルしてバイナリを別途ツールでブートセクタに書き込んでリセットしてテスト…。

エミュレータで開発することを考えても、普通に512バイト以下のファイルで実行したほうが楽ちんです。DOSのCOMファイルで実行することにしましょう。

プログラム方面と、ゲーム内容方面と両方考えて行く必要があるのでなかなか大変ですが、大雑把にアクションゲームとします。

あとスクロール。MSX1の機能で1ドットスクロールするゲーム。こんな目標を立てました。

キャラクタ単位の移動をドット単位の移動に見せかけるには、絵の内容をドット単位でずらしていく訳ですが、そのとき溢れたドットは隣のキャラクタに移動する必要があります。

そうすると、隣のキャラクタもドットが溢れてその隣へ、その隣も隣へと連鎖して1ライン画面端までパターン書き換えが発生します。

スクロールするとはそういうことなので別におかしなことではないのですが、これだと画面のドットを書き換える量が多いので速度的な問題は発生しそうです。

今回は動かしたいキャラクタのスクロール先に緩衝用のキャラクタを置いてみます。

この緩衝用キャラクタにドットが入ってきても、そのままにします。

キャラクタが移動した後には緩衝用キャラクタの色が回り込みます。

どんどんドットがずれ込んで、完全に1キャラクタ分ずれるときにキャラクタ毎左へ移動させ、画像を初期状態に戻します。

この場合に限定すると、16パターン用意しておくとキャラクタの切り替えと配置だけでドットスクロールが表現できます。

この考えを延長してキャラクタが複数集まって1つの形を作っている場合や、いろいろなマップチップを使うとなると用意するパターン数が多くなります。1x1キャラクタ=16パターン,2x2キャラクタ=48パターン、4x4キャラクタ=160パターン…。

数が増えると予め用意しておくということは厳しそうです。

しかし今回は512バイト限定なのでそこまで広げて考える必要はないかも知れません。

それともう1つ、色についても制限が出ます。

1キャラクタで1ラインに2色設定できますが、

スクロールすると1ライン3色になってしまうので、色化けを許容するか色数を減らすかしないといけません。

色化けを許容するとこんな感じ。ちょっと見辛いです。

色数を減らして、緩衝用キャラクタ含めて1ライン2色にすると色化けは発生しません。

1ライン単位で上手く色分けしたデザインに出来ない場合は、見た目にはほぼ単色表示に見えます。

今回は、色数を減らす方法を採ります。スクロールさせたいキャラクタも1つだけ。16パターン事前作成にします。

先ほど決めた内容で画面を構成してみます。MSXのBASIC画面でポチポチ入力するだけで大雑把な感じが分かるのは便利です。

それと、どうせ単色になるのならデータ量の多いSC2モードじゃなくてSC1モードで実行することにしました。

ここで確認しているのはゲーム画面のサイズ感です。まぁこんなもんでしょうかね。

あとこの作業で問題点が1つ確認できました。

ドットスクロールする予定の四角(障害物とします)は、上記のルールだと緩衝用キャラクタがあるので1つおきにしか配置できません。

連続して配置したい場合もありそうなので、対策を考えます。

対策は16パターンに加えて、障害物の画像がループする8パターンを加えることで上手く行きそうです。

こんな感じで8パターン追加。合計24パターンになりました。

スクロールの方法がなんとなく固まったので、これらのパターンをどのキャラクタコードに割り当てるか考えます。

0を空白キャラクタにして、1～24を使うことにしました。1～8が緩衝用のパターン、9～16がループパターン、17～24が障害物単体のパターンになります。

さて、そろそろプログラムの方に取り掛かります。