シューティングゲームチャレンジ ＃25

敵弾の動きが変だった理由がわかりました。
敵弾の座標にスクロールを考慮するのを忘れていました。
左方向に1ピクセルのベクトルだと、背景や砲台も同じ方向に同じ分動くので、見た目上、X成分は停止しているように見えてしまいます。
今回、動いていない敵から弾が発射されたことで、それが分かりやすい形で露呈しました。
常に実際の表示座標と、スクロール背景内の仮想座標を意識していたつもりだったんですが、頭の中だけでやっていたので穴がありました。
けっこう混乱を招く事項なんで、過信せずノートに書き出しておくべきでしたね。
初心者がスクロールゲームを作る時に落ちやすい穴だと思うので参考になるかと思い、秘密にして直さずにブログで報告しておきます(笑)
恥ずかしい話しですが(^_^;)

シューティングゲームチャレンジ ＃２４

対空ミサイル実装

コケる歩行砲台が対空ミサイルを発射するようにしました。



















初速と重力の値で飛び方が変るんですが、かなり微妙な調整が必要で思った以上に苦労させられました。

何故か左に飛んでくれないトラブルも発生したり。
なんかX成分マイナス方向のベクトルが上手く機能してないっぽいなあ。
スクロールに合わせた座標調整の問題かも知れませんが、よくよく見ると敵弾はミサイルに限らず右方向と左方向で速度が違う気がします。
変数の型の変換が上手く出来てない気もします。

結局左方向のベクトルは少し大きめの値を入れるというその場しのぎ的な解決法でクリア。
まあ、結果オーライで行きます。
プレイする人はベクトルの値なんか意識しないわけですから。

あー、対空ミサイルでこんなに躓くとは！
ホントは一気に固定砲台まで実装したかったのに。

シューティングゲームチャレンジ ＃２3

敵弾と背景の当たり判定を実装

背景との当たり判定復活に伴って、敵弾と背景にも当たり判定を加えました。
これで敵弾が壁を突き抜けて自機を攻撃してくる事は無くなります。
これで当たり判定については現在必要なオブジェクト全てに実装されたことになります。
今後だいぶ先にパワーアップアイテム等を実装するまではこのまま行けるんじゃないかと。

あと、画面内限定で背景との当たり判定を行う事を考えていたんだけども、よく考えてみると四角形の接触判定は４組の数字の大きさを比較するだけで得られる極めて軽い処理で、これらの座標が画面内かどうかを判断する処理を付け加えるのは当たり判定そのものとたいして変らない条件分岐を増やすようなもん（X方向において画面と言う四角形と背景各ブロックの接触判定をするような感じ）なので、処理速度上はあんまり効果が無いんじゃないかと。
背景が相当大きな画像で、沢山のブロックに分けなきゃならないほど複雑な地形だった場合はまた別でしょうけど。
んなわけで、とりあえず今の処理のまま行けるとこまで行くつもりです。

で、今までは各キャラクターと背景の当たり判定を行う関数ごとに、当たり判定の処理を入れていたんだけど、その処理部分を当たっていればTRUEを返す専用の関数にして、判定したい対象オブジェクトのX0、Y0、X1、Y1の座標を渡せば結果が得られるようにしました。




















文章だとわかりにくいですが、ソースだとつまりこういう事です。
この形の方が後から判定したい対象（フォースと背景とか）が増えたりした場合に追加が楽になります。
判定対象のX0、Y0、X1、Y1を定義した上で、BG_Coll関数に渡すだけで判定結果がTRUEかFALSEで返ってきます。

シューティングゲームチャレンジ ＃22

背景の当たり判定用データを別ファイル化

予告通りの仕事を終らせました（笑）
背景に関する当たり判定は以前の記事で書いた様に四角形の接触判定を用いています。
そのため、背景にはグラフィックデータの他に、各ブロックごとの四角形の左上と右下の座標のデータが必要になります。
それらの座標と、自機、波動砲の座標を比較して当たり判定を行うわけです。

で、背景との当たり判定を実装した段階では、とりあえず背景四角形の座標を入れる配列変数を用意して、そこにプログラム内で直接代入しておく方法をとっていました。
当たり判定がしっかり働くかどうかの実験が目的だったので。
ですが、その時点で既にデータは別ファイルにしておくべきだなと思っていました。
徐々に背景のグラフィックを描いてゆく今回のような制作スタイルの場合、区切りの良いところまで描き終わるごとに四角形の座標も追加してゆくことになります。
であれば、敵機のデータと同じく、いちいちデバッグの必要の無い別ファイルにデータを入れておいた方が良いだろうと。
また、今回は１ステージのみですが、複数ステージある場合や、今回の横スクロールシューティングのプログラムをベースに新たなゲームを作る場合に、別ファイルから読み込んだデータから当たり判定を行う方が流用も効きます。

プログラム自体は敵データのファイル読み込みと同じことだし、背景との当たり判定を行う関数は機能させていないだけで既に出来ていたので、あっさり実装できました。
でも、現在のバージョンは画面外も含めて全ての背景ブロックと毎フレーム当たり判定を行っています。
そのことによる処理の遅れは今のところ見られませんが、今後背景を書き足していった時どうなるかわかりません。
それにやはり画面に表示されていないものと当たっているか判定するのはナンセンスです。
なので、次はこの当たり判定を画面内のオブジェクトに対してのみ行うようにしようと思います。





ドット絵エディタに表示した背景の各ブロックの角座標にマウスカーソルを合わせて、表示される座標をノートに書き出します。
これをテキストファイルに打ち込んで、読み込むデータファイルを作ります。
マップエディタとか作る技術が無いので、非常にアナログな作業になります（笑）
いや、これはこれでなかなか楽しかったり。







では久々の更新なので実行ファイルを。
いつも通りソーステキスト同梱です。
http://multip.net/view/H3OtLqfSd1

ダウンロードや操作方法については前の方の記事を参照してください。
 

シューティングゲームチャレンジ ＃２１

歩行型対空砲表示

他の敵の動きの細かい部分を修正しつつ、歩行対空砲を作ってみました。
もはやいつもの事ですが、とりあえずの手抜き仮絵です。













右下の輪郭線だけのオレンジ色のがソイツです。
とことこ歩いてきます。












んで、こうなります。
まるでコケたみたいですが、決してコケたわけではありません（笑）
この後、砲身から上に向かって無数のミサイルを発射するわけですが、それはまだ実装していません。





ミサイルは波動砲で破壊できる予定なので、プログラム的には敵弾ではなく敵機に近いです。
敵機として扱ってしまおうか悩んでいますが、後々誘導ミサイルなども登場する事を考えると別の構造体を定義した方が良いかもしれませんね。