| 【 ActBarrier for プチコンmkII 製作過程 その１ 】 |
|---|
| Home | PC-6001mkII | Program | etc |
| このページでは、ActBarrierの骨格部分作成の過程を書いています。 |
| 2012/11/03：移植開始 | ||||||||||||||||
|
HSPプログラムコンテスト用に作った「ActBarrier」、割と素直な作りにしたので、少し手直しすればプチコンmkIIでも動くのではないだろうか？ HSP版とは大きく以下が異なるけど、これくらいなら見た目にはさほど影響ないような気がする。
という事で、グラフィックは後回しにしてHSPソースの自機と敵の移動部分を軽く変換しながらプチコンmkIIに打ち込んでいく。表示方法は流石に大きく異なるが、動きについては移動範囲や速さの違い位で、あまり変更の必要はなかった。 少なくともこの時点では。 |
| 2012/11/03：キャラデータ簡易版 |
|
最低限の動きができたところで、簡単に自機と敵のキャラデータを作成する。 敵キャラ(32x32)の1つ目を簡易的に円で描画後8x8に分割し、スプライト用のキャラクタ0〜15に入れる。ちゃんと表示された。 次に自機(32x32)を三角形で描画後8x8に分割し、スプライト用のキャラクタ64〜79に入れる。ってあれ？なぜ自機のグラフィックが出ないんだ？やっている事は敵と同じはずなのに。 1時間ほど試行錯誤して、ようやく法則をつかんだ。どうやら、SPSETで指定するスプライトキャラ番号は、CHRSETで指定するキャラ番号の開始番号の1/4にするようだ。 後々考えると、スプライトキャラが16x16で1つなのにキャラクタ定義は8x8単位で行うので、スプライトキャラ番号とキャラ番号が4倍違うのは当然なのだが、この時は32x32以上だとそういう特殊な形式になるのかと思っていた。 次はオプション、これは若干小さめだから、16x16のスプライトにしよう。という事で、簡易的に円を作成後8x8に分割し、スプライト用のキャラクタ80〜83に入れる。ってあれ？オプションのグラフィックが表示されない。うーむ、これもSPSETのスプライトキャラ番号を1/4の20にすれば良いのかな。...という事でようやく表示された。 ただ、割と速い段階で処理落ちするな。最初から60fpsではやっぱり無理があったか。 |
| 2012/11/04：プロトタイプ |
|
朝早めに起きて、作成の続きに移る。この日は、ゲームレジェンドの開催日なので、あわよくば途中版を誰かに見せられるかな？とりあえず動くところまではもって行きたい。 まずは、爆風の★を追加する。ここでも昨日と同じ理由で表示に少しつまづいたが、なんとか表示できた。当然ながら処理落ちがよりひどくなったので、fpsを落とすか...。 タイマー待ちのVSYNCの値を1から2に変更し、自機の移動速度のみ2倍にする。これでも数が増えると処理落ちするし全体的にもっさりしてるが、先に進めよう。といった所でゲームレジェンドへの出発時間だ。 電車の中で、オプションのパターンを5つに増やして5色に色分けをする。まだプチコンmkIIの命令やパラメータがすっと出てこないのでマニュアルを見つつ行うのだが、マニュアルを見るとどうも思考が寸断されるな。ポケットリファレンスがあれば良いんだけど。 といったところで、ゲームレジェンドの会場に到着。P6同人誌を受け取ったり、ブースをうろついたりした後、のりさんやTINY野郎さん達に、できたて(全然できてないけど)のプロトタイプを見せてみる。
TINY野郎さんに「あと3倍くらい速くならないですかね？」と言いつつ このプロトタイプを送信し、お返しに「例のモノ」(と実際に言ったような気がする)を戴く。タイトル画面もゲーム画面もぐるんぐるん回るし、やっぱりすごいよ「例のモノ」。 晩になって、TINY野郎さんからツイートが届く。SPOFSの補完フレームとSPCOLを使うと、まだかなり高速化できそうだとの事。 確かに現状、当り判定は敵と自機との距離を都度計算する円形判定をしているので、処理はかなり重いんだろうな。補完フレームとSPCOL、両方ともまだ使った事がないけど、いっちょやってみるか。 |
| 2012/11/05：上下左右 |
|
さて、文字を描くか。 これまで暫定的に1種類にしていた敵のキャラクタを4種類にし、各キャラクタに「上下左右」の文字をGLINEで書き込む。これを、スプライト用キャラクタ0〜15, 16〜31, 32〜47, 48〜63に割り当てるよう処理を作成する。 やっぱりキャラクタに文字が入ると、独特の雰囲気が出るな。
|
| 2012/11/05〜08：自動補完その１ |
|
スプライトの動き補完を実装する。 手始めに、一番楽そうな爆風から実装する。爆風は発生時点から速度や表示時間が固定のため、
SPCLRで消すのがスジなのかも知れないが、毎回SPSETで作成してSPCLRで消すよりも、初回のみSPSETで作成してSPOFSで画面外に追いやった方が速い気がする。という事で、SPCHKの結果0になったらSPOFSで画面外に移動させることで、表示上消えたようにする。 次に、オプションの集合部分に動き補完を組み込む。開始座標は現在のオプションの座標、終了座標は開始時点の自機の位置、補完時間を4にする。いざ試してみると、確かに自機には寄るのだが、なぜか今ひとつ寄り切らない場合があったり、集合後にオプションが1回だけ移動するといった不審な動きをする。 この辺りは、またおいおい直していく事にしよう。 次、敵の動きだ。これも開始地点と終了地点は開始時から決まっているので、開始地点と終了地点の距離差を敵の移動速度(固定)で割り、SPOFSの補完時間にセットする。敵の終了地点は画面外に設定しているので、移動完了後も画面から消す処理は不要だ。 プログラムを終了させても勝手にスプライトが動くのが、妙な感じだ。修正はもうちょっとありそうだが、とりあえず動き補完はこんなところか。 |
| 2012/11/07：コリジョンその１ |
|
さて、コリジョンだ。 衝突判定の簡単そうな例をWebで探す。どうやら、SPCOLで衝突範囲となる矩形範囲を指定し、SPHITで同じグループの管理番号との間で当り判定同士が衝突したかどうか判定するようだ。 ただ、この時点では「同じグループ」が何を表すのかと、複数が同時に衝突したらどうなるかが今ひとつわからなかった。 お、SPHITと似た命令にSPHITSPというのがあるな。こちらは1:1で衝突判定をするようなので、HSPでやっていた方式に似ている。とりあえずこちらを使うか。 まず、敵の当り判定を設定する。SPHOMEでスプライトの表示原点を中央にずらしているから、少し大きめに黄色の範囲とするとこんな感じか。
これでちゃんと衝突判定するのだろうか？と思った時にやる事は決まっている。簡単な例で検証だ。スプライトを2つだけ使用し、衝突範囲を確かめるプログラムを作成する。うん、考え方はまちがってないようだ。 簡単な検証ができたところで、敵とオプションとの間で衝突判定を組み込む。概ねうまく判定しているようだが、なぜかたまに検討違いの場所で衝突判定される場合がある。なんだろこれ？ |
| 2012/11/10〜11：幻のグラデーション |
|
少し、見栄えの部分もよくしていくか。 まずは背景のグラデーション、と一旦は実装した。
表示数はできるだけ変えたくないので、今回は泣く泣く背景色をあきらめることにした。まあ黒だっていいか。 次に、自機の衝突判定、オプションの回復判定を入れる。ちょっと衝突判定がでかいので、後日調節しなきゃな。 |
| − | ActBarrier for プチコンmkII 製作過程 | その２ → |