現在、80mk2 専用で開発を進めているゲームですが、実は当初 60mk2 で全ての面が同時接続状態の広範囲で動ける内容で作ろうと考えてたモノでした。ところが 60mk2 ではあまりに荷が重くて挫折。今回ターゲットを 80mk2に変更してCPUパワーは上げたものの、あの時の反省と教訓を活かしまくっています。その内容は以下の通りです。

4方向自由に向きが変えられると、実は攻撃パターンも4方向全て別々に用意する必要が出てきます。武器の種類を増やしたくても、全てが4倍のデータ量になるため、手間もデータもかかりすぎてしまいました。そのため、シューティングゲームで最初に目にしたスペースインベーダーよろしく、上方向だけに限定することにしました。

これのメリットは大きくて、例えばプレイヤーの通常弾は、真上に上げるだけですから Y座標を減らすだけです。そして、移動に関しては、常に真下の差分サイズを元に戻すだけで良いのです。様々な方向に撃てると全消し後の全描き直しか、または各方向毎の専用描画ルーチンが必要となります。時間もメモリも無駄ですよね。

当たり判定だって単純明快になります。下から上がるだけなので、まずは Y座標で範囲を絞り込むと、だいたい最初の絞り込みで殆ど終わってしまいます。残った候補の X座標判定のみですから、2回判定が殆ど通らなくなりました。

…まあ、そのうちワイドショットやらダブルショットやらバックショットやら作り始めたら、このメリットは減りはしますが、全部上向きだけですから、4倍作らなくても良いってのは大きいですよね？

あと、地味にプレイヤー画像も上向きだけで良いのでメモリの貢献度も高いです。

Newシティヒーローでは、今どきのゲームっぽく、上の1行に情報表示を集めて、下側は全域にゲームエリアとして使いました。今回は縦シューメインですから、上方向は1行でも広く使いたい。そこで、ボスコニアンのような、レトロゲームではよくある左側にゲームエリアを持つデザインとしました。

横64キャラって実は凄く都合が良いのです。理由はアドレス計算です。縦横4ドットを移動最小単位とした場合、画面全体は 80x50キャラと考える事が出来ます。其々のVRAMアドレスをチェックすると、面白いことが分かりました。まずは全数チェック表結果を御覧ください。
※クリックで拡大しないと読めないと思います。

赤色を付けた場所がアドレスの上位8bitが変化した箇所です。なんと全ての桁上りが、X座標 64 の場所で発生しています。これの意味するところは、X座標が 0 から 63 までなら、桁上りを意識する必要がないということです。これで頻繁に計算される座標アドレス変換を高速化できます。

敵が多数ともなると、ワークエリアも多数使用することになります。使用している、あるいは空いている場所を探す時間的なロスが馬鹿になりません。そこで、ゲーム内で処理する3つ以上の連続物は、なにもかもリスト管理とすることにしました。これで、怪物の発生は怪物空きエリアからもらうだけです。怪物の処理は処理リストから終端コードまで続けるだけです。

さらに状態により分岐も極力なくしました。状態別リスト管理です。怪物がやられると爆発します。以前なら爆発中という状態にしていましたが、今回は爆発リストにワークを繋ぎ変えています。これで、怪物の移動リストでは、移動に専念できます。処理中の分岐を分けられる場所はなるべく分けるようにしました。

弾の移動は64方向としています。これは実験により、64×50ゲームエリアの端から端を狙うために必要な最低限の解像度だと自分で決めたためですが、以前はそれをそのままゲーム内に登場する怪物キャラにも適用していました。

弾のサイズは基本 8×8ドットです。では、怪物のサイズはといえば、基本は 16×16ドットです。つまりは2倍デカいのです。その大きさに対して 64方向はオーバースペック過ぎました。なにせ大きさ換算すると、32×25解像度と大差ないためです。そこで、怪物とプレイヤーの移動は専用の8方向固定小数を用いることにしました。これで意外なぐらい高速化しています。