| 【 Making「ActBarrier2」その１ 】 |
|---|
| Home | PC-6001mkII | Program | etc |
| 2017/08/xx：はじめに |
|
ActBarrierの作成も2017/5に一段落してしばらく経った。せっかくドット単位でキャラクタを動かすプログラムを作成したのだし、これを活かした続編を作りたいな。 ということで、こんな感じのゲームを計画してみる。
|
| 2017/09/09：オプション同期移動 |
|
前作ActBarrierのマシン語ソースをベースにして、少しずつ改造していくことにする。 まずは、オプション関連で不要となる処理の削除から。オプションパワー減少、オプションの収束処理、オプションパワー回復処理あたりの処理を外す。 次に、自機とオプションの同期移動を行う。これを実現するために、自機とオプションの座標形態を相対座標に変えて、相対座標＋オフセット座標を元に画面表示を行う。 イメージ的には、自機とオプション用のレイヤーを別に用意して、自機とオプションの同期移動時にはレイヤーごと動かす感じだ。
|
| 2017/09/10：敵の管理データ構造(Ver.1) | ||||||||||||||||||
|
ゲームを作るにあたって、重要となるデータ構造を考える。まずは敵の管理データから。 前作は、敵1体当たりのデータを、HP, Y座標,X座標,キャラクタ番号(CH),Y移動量(W),X移動量(V) の6バイトで管理していた。今回は複数種類の敵を動かす予定なので、敵の種類も情報として追加する。あと、敵毎の処理できっとワークデータが必要になるので、合わせて追加する。
|
| 2017/09/12：敵の移動タイミング処理 | |||||||||||||||
|
敵の移動速度を可変にする仕組みを考える。 ベースとなるタイミングデータと、敵毎に用意する速度用データを使って、タイミングが合った時のみ敵の移動処理を行うようにする。 タイミングデータは、初期値11H(ビット列00010001)として、1ループごとに00100010→01000100→10001000→00010001のようにビット位置をずらしていく。 一方、敵毎にも速度用データを用意する。こちらは基本的に敵出現時から変更しない。 タイミングがあったかどうかは、タイミングデータと速度用データのANDが0か否かによって判定する。 例えば、敵のタイミングデータが01010101だった場合は、以下のように4ループ中2回移動することになる。
この仕組みを使えば、同じ敵速度用データを複数の敵に適用することで複数の敵を同時に動かしたり、逆に敵速度用データを意図的にずらすことで移動処理の偏りを軽減する事ができる、はず。 タイミングデータを00000001のように1bitだけ立てることで、理論上8段階の速度を実現できるのだが、敵速度用データの作成が面倒になりそうなので、今回は4段階の速度にする。 |
| 2017/09/12：敵の管理データ構造(Ver.2) | ||||||||||||||||||
|
さて、この敵速度用データをどこに格納するか。 とりあえず、管理データの大きさはそのままにねじ込んでみる。敵が16種類以内に収まるとすると情報は4bitで足りるので、残りの4bitに敵速度用データ(SP)を入れるか。 ということで、1バイト目の上位4bitを敵番号、下4bitを敵速度用データにしてみる。
変更してはみたものの、敵が16種類を超えたらどうしよう。そんなに敵の種類を作るのかという話でもあるけど。 |
| 2017/09/18：敵移動処理分岐 |
|
敵の複数種類化を実現するため、敵番号による敵移動処理分岐を実装する。 敵番号毎の移動処理開始アドレスのテーブル(敵番号毎に2バイト)を用意しておく。敵出現処理の分岐処理で、まず開始アドレスをHLレジスタに格納し、敵番号の2倍を加算、JP (HL)で移動処理に移る。 処理分岐を確かめるため、画面上から下に直進する敵1と、画面左右で跳ね返りながら下に降りてくる敵2の移動処理(仮)を作成する。
|
| 2017/10/09：敵出現フォーマット(Ver.1) |
|
今回は、面毎に敵の出現パターンを決めておきたい。ということで、敵出現データのフォーマットを考える。 敵出現データは少な目にしたいので、とりあえず敵番号と付属情報の2バイトセットで考える。敵の編隊飛行等、同じ敵を連続で出したいので、連続出現数と出現間隔を入れておくか。 ひとまず、敵番号1バイトと、出現数3bit(1〜7)＋出現周期5bit(1〜31)の1バイト、の2バイトデータを1セットにしてみる。 敵出現データの処理と、仮の敵出現データを作成し、動きを確認する。
|
| 2017/10/09：敵の管理データ構造(Ver.3) | ||||||||||||||||||||||
|
敵の管理データだが、また気が変わった。 敵の管理データの1バイト目だが、敵番号が4bit(最大16種類)だと心許ないのではないか？あと敵番号を取り扱う度に上位4bitを取り出す処理が必要になって、処理効率が悪いように思う。1キャラ8バイトにこだわるつもりだったが、ここはひとつデータ構造を変えるか。 敵速度用データ(SP)を分離して、ついでにワーク領域を2バイト(WK1, WK2)に増やす。 合計10バイトになるが、管理データ全体を256バイトに収めることを考えても、最大256÷10＝25.6。最大25キャラクタを制御できるので、まあ許容範囲だと思う。
一旦、これで様子を見よう。 |
| 2017/10/15：敵番号細分化 |
|
左右端で跳ね返りながら斜め下に降りる敵2だが、左スタートと右スタートというように複数の登場パターンを作りたい。 敵の種類ごとに敵番号を割り振ろうと思っていたが、敵の種類＋出現パターンごとに敵番号を割り振った方が、融通が利きそうだな。敵番号がどこまで多くなるかわからないけど、まあ256種類には収まるだろう。 |
| − | Making「ActBarrier2」 | その２ |