「あめばれっと」でしなかったこと

自作シューティングゲーム「あめばれっと」の最新Ver. 1.5をVectorへ申請登録したけど、まだ返事がなくてウズウズしている魔偶です(汗
((o(> <)o))ｳｽﾞｳｽﾞ

さて、リリースをしてから色々と御意見をいただいて、バージョンアップを繰り返した当ゲームですが、あえて「しなかった」ことが実はあります。

というのも、10月12日の記事のコメントで、mirage17さんが「背景スクロールとかできたら…」とあったので。

まず、このゲームの開発にあたって、開発言語であるHSPと、HGIMG3モジュールを使用しているんですが、「どれぐらいのものがどこまでできるのか？」と漠然とした上で始めました。

過去の記事を見てもらうとわかりますが、シューティングゲームというジャンルはいかんせん画面に登場するキャラクタ数が多いものです。
敵弾だけでも数百発あったりするので、それらを画面に表示することと、自機の当たり判定を処理することにマシンパワーが必要だったりします。
そういったパワーをパソコンのCPUに負担させるのでは、あっという間に処理過多となって動作が重くなってしまうので、DirectXの技術を使ってグラボ等に処理を分散させて快適に動作するものに仕上げるわけです。

で、今回はそのDirectXを使って比較的快適に動作するシューティングゲームを作るわけなので、DirectXを使うためにHGIMG3モジュールを適用し、開発を行いました。

まぁざっくり説明すると、今回のようなゲーム開発はそういった感じ。

【HSP詳しい人向け雑記】━━━━━━━━━━
ちなみにHGIMG3じゃなくても、HSPDXFIX等が有名ですが、ゲームを配布する際にそのDLLファイルも配布しないといけなくて、インストールしたフォルダ内のファイルを見た時に「何このDLLファイル…」と思う人がいるかもしれん！という、特に意味のないこだわりによって、採用を取りやめました。
EXEとメディアファイルだけですっきりっていうのが理想で、自分が触れないDLLファイルを一緒に混ぜるのはどうもすっきりしないので…。
DLLファイルをEXEに梱包できるといいんだけどなぁーと思ってみたり。
━━━━━━━━━━

で、HSP+HGIMG3で開発を始めて、実際にモノを仕上げた時、なるべく快適に動作する範囲としてどれぐらいの処理をさせれるかというのが、ずーっと気になっていたところです。

例えば、先ほどの敵弾と自機の当たり判定の処理は、HGIMG3でラクしてる部分もありますが、シューティングゲームの当たり判定のアルゴリズムとしては、だいたい以下の感じ。

①自機の位置座標を得る。
②敵弾の位置座標を得る。
③自機と敵弾が重なっているか、それぞれのキャラクタの大きさを加味して判定する。
④重なっていれば「当たった」ので、自機ダメージの処理へ。
⑤当たっていなければ、次の敵弾について②の処理へ戻って同じように処理。

ということを、敵弾数ぶん…つまり場合によっては数百回パソコンに処理させるわけです。しかも約1秒間に。

なので、なるべく負荷をかけないように…と意識しながら、敵弾数を調整して弾幕を作ったり、当たり判定の処理数を減らしてみたり、当たり判定自体のアルゴリズムを模索してみたりして、できあがったわけです。

前置き終わり。
Σ(・∀・*；) ﾅｶﾞｲﾖ

mirage17さんの背景スクロール案を取り入れるかどうかについては、そういった模索する点のひとつに当初から入っていましたが、開発を進めていく中で処理負荷の軽減や、ゲーム上の舞台として、画面枠内でキャラを制御し、画面外には自機弾･敵弾しか出ないという仕様にしたことから「スクロールは無し」とし、更に敵弾やキャラクタ(とくにアメーバ)の視認性をなるべく落とさないために、「背景は何も無し」としたわけです。

本題終わり。
Σ(´Α｀；) ｽｸﾅｯ

そんなわけで、ある程度は色々とできることが「あめばれっと」の開発を通じて十分にわかったので、次回作「eXamio(イグザミオ)」では背景スクロールを取り入れて仕上げます。
多重スクロールとか面白そうだねーとか、R-TYPE3の3面みたいな斜めスクロールとかも面白そうだねーと思ってみたり。

eXamioもHSP+HGIMG3で3Dシューティングなので、カメラ機能を使った演出で楽しく開発をしたいと思います。自機の後ろから見た視点でボスが登場とか…想像しただけでワクワクすっぞ(爆
((o(´∀｀)o))ﾜｸﾜｸ