見出し画像

黎明期のパソコンゲーム開発#40

■ZAXUSを創る ~PC-8001の限界に挑戦~

1.ビームと弾

ZAXUSは動きの滑らかさを表現するため、もともとPC-8001の限界に挑戦する作品でもありました。そのため移植性は全く考えずプログラムもPC-8001に限りなく特化した作品となっていました。

特に高速化が求められたのはスクロールと弾の処理。多重スクロールを実現しながら、時には大量の敵の弾をよける動きにするため画面に100個近く敵の弾が表示されても十分動作するようなプログラムを組んでいました。

また敵の弾の動きも単純な動きだけではなく、直線弾・放物線弾・誘導弾など様々な動きや、弾の動く方向によって弾のキャラクタも変化させるなどかなり細かいロジックを組んでおりスピードとの闘いとなっていました(面数が上がるにつれ、弾の動きもだんだん巧妙になる作りにしていました)。 

弾の動き

また画面上にぶわっと広がるトラクタービームもスクロールしながらの表現となるため、処理が落ちないようプログラムを組んでいます。

画像2

2.高速化への挑戦

スクロールしながらトラクタービームの描画を表現するためには、可能な限り無駄な処理は廃止するとともに個々の処理をより短時間に処理する必要があります。そのため画面のアトリビュートエリアも固定領域・変動領域と分け、高速スクロールする下半分の領域はアトリビュートを計算し、その他は無視するなど細かな配慮をしています。

また背景のドットスクロールも1つ1つの処理の高速化を図るだけでなく、画面上の星の数を制限しつつ、かつ制限した星でちゃんと背景になるようデザイン面も合わせて考慮することで高速化を実現しています。

プログラム的には個々のクロック数を意識したコーディング、サブルーチンや無駄なループをなくした高速化やスタックポインタを使った高速画面クリア、時にはZ80の未定義命令までも活用して高速化を行っていますが、そもそも高速化やプログラミングテクニックはテクニックを見せるものではなく、ゲームの面白さを半減させる動作・欠点を隠すためのもののため、必要となった部分にプログラミングテクニックを活用していった形としています。

あとは少ないメモリをどう活用するかという点。メインメモリが32Kbyteというハード的な制約があったため、まずはアイデアレベルにあった多数のキャラクタの中から選別していきましたが、それでもどうしてもメモリが足りず、時には1byteのメモリを圧縮するためハンドアセンブルのリスト全体を1byte分シフトするなど地味な努力をしていました。

最後は数byteのメモリを浮かすためN-BASICのROM内ルーチンを活用したりと限界まで切り詰めてPC-8001の性能の限界まで詰め込んだものとなっていました。

今のマシンはメモリもストレージもふんだんにあり、開発ツールも整っているためこんな地味な努力はもう不要なものとなっていますが、「無駄を切り詰めるための工夫」「ゲームの面白さをなくさないために何を残すか」の考え方は他の仕事のやり方にも活きているように思います。

次回は隠しボーナスとエンディングについて書いてみたいと思います。


この記事が気に入ったらサポートをしてみませんか?