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

敵弾発射実装














敵の弾がヒットした瞬間のスクリーンショット。




敵が一定確率で自機に向かって弾を撃ってくる処理を実装した。
敵の弾は座標、当たり判定用の半径、移動用のベクトルなどをデータとして持っている。
発射時点で、敵と自機の座標を結ぶベクトルを作成し、それを長さで割って正規化（長さ１のベクトルを作る）する。
それに１フレームで進めたいピクセル、つまり速さを掛けると、移動用のベクトルになる。
あとは、毎フレーム弾の座標に移動用ベクトルのX、Y成分を足してやればOK。

同時に自機と敵弾との当たり判定も実装した。

実行ファイルを。
いつも通りソース同梱です。
ダウンロードと操作説明は＃８の記事を参照してください。
http://multip.net/view/33TBP8ChJL

今、朝の６時過ぎ・・・もう限界。
ねますzzz

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

波動砲貫通実装




















スクリーンショットは、最大にためた波動砲が１機目のザコ敵を破壊して貫通した瞬間です。
ためた状態に応じて、波動砲にパワーを表す数字を１～16まで振り分けます。
今は敵機に堅さの概念が無いので、敵に当たる毎にパワーから１を引いて、０になったら消滅するようにしました。
グラフィックも現在のパワー値に応じて変化するようになっています。

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

進行方向で向きの変る敵を実装




















このスクリーンショットではわかり難いんですが、1番右の敵機が斜め上を向いています。
波運動する敵は、自分の現在の状況を角度で持っている（詳しくは波運動実装の回を参照）ので、その角度に合わせて表示するグラフィックを変えてやるだけです。
プログラムそのものより、思った軌道で敵機を飛ばすデータを作るのがなかなか難しいですな。
角速度などの数値を少しいじっては実行を繰り返し、徐々に理想のラインに乗せてゆきます。

次は地上を歩く敵を作ってみようかと思っています。
新しい動きの関数を増やさなくてはなりません。
平らな地上を左右に歩くだけなら、背景の当たり判定は無くてもそれなりに見せられるかな。

あ、あと、敵も弾を撃ってくるのをすっかり忘れていました。
まだまだやることあるなあ。
いろいろな処理を想像すると楽しいです。
敵の固さの概念も無いし。

最終的に敵1体につき、いくつのデータが必要になるのかなあ・・・。
シューティングゲームの1ステージに出てくる敵が必要とする数字要素がこんなに多いなんて、作り始める前は想像もしていませんでした。
遊ぶ時は一瞬で画面から消えるザコ敵にもこんな苦労が必要だったんですね。
これからはもっと味わって遊ぼう・・・。

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

複数の敵機表示実装
敵機出現のタイムスケジュール化実装



















敵機のデータの構造体を配列にして、複数の敵を同時に表示できるようにしました。
方法的には自機の波動砲連射と一緒です。

で、同時に敵の出現をタイムスケジュール的に管理できるようにしました。
敵のデータの1番最初にゲームスタートから何フレーム目に出現するかが入っています。
プログラムは次に出現する敵機の出現フレーム数と、現在のフレーム数を毎フレーム確認して、等しい値になったら敵を出現させます。
その後はまた次の敵の出番待ちとなります。

この実装に伴って、最後の敵が出現してしまうと、それからは一切敵機が出現しなくなりました。
現在14機で終了です。
このスケジュール表をボスに至るまで埋めてゆく事でゲームを構成してゆくことが出来るかなと思っています。
スケジュール表には現在の時点で、出現フレーム数、動きのパターン番号、グラフィックハンドル番号、出現時のX座標、同じくY座標、円の当たり判定の半径etc・・・と1機につき11種類のデータが入っています。
おそらく今後新しい動きなどを実装する過程で、さらに増えるでしょう。

また、これらのデータを調整することで最終的にはゲームのバランスを取って行く事になります。
その際、データがソースに含まれていると、変更の度に開発環境を立ち上げてデバッグしなければなりません。
そこで、敵機に関するデータを別のファイルにいれて、プログラム側がこのデータファイル読み込んで取得するかたちにしました。
敵のデータはテキストファイルに数字の並びで入っています。
敵の出現タイミングや動き、座標などを調整したい時は、このテキストファイルをルール（データの格納順など）に従って書き換えてやれば開発環境をいちいち立ち上げる事無くゲームバランスの調整が可能になります。
最初に使っていたテキストと、DXライブラリやC語標準ライブラリからファイルの読み込みに関する関数を調べて、なんとかうまく実装できました。

実行ファイルを。
ソース同梱です。
ダウンロード及び、操作の説明は＃８の記事を参照してください。
http://multip.net/view/pPGHNQgi1U

よし、これでシステム関係の重要項目は実装できたんじゃないかな？
あとはステージを作りながら、敵の動きや種類を追加して行って、最後にボス戦を実装って感じかな。
まだまだ、壁には当たるだろうけど、時間と根気でクリアできる気がする。
この企画をスタートした時の完成確率が10％未満だったとしたら、五分五分までは行かないけど、30～40％くらいにはなったんじゃないかと。
がんばります。

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

背景との当たり判定実装

背景と自機、波動砲に当たり判定をつけてみました。
敵機に関しては、壁に衝突（自爆）するような飛ばし方はしないので今のところ必要ないなと。
あ、床を歩き回るような移動砲台には必要か。

自機と敵機で使ったような円の当たり判定だと、直線主体の判定ラインがボコボコになってしまいます。
小さな円を線に沿って沢山並べればカバーできますが、それを一つ一つ判定するのは余りに効率が悪い。
と言うわけで、最初に線と円の接触判定を考えてみました。
えーと、背景の線分Ｐ-Ｑと自機の中心点Ａの距離を求めるには、角ＡＰＱと角ＡＱＰが90度以内の時はＡＰ×sinθで、いや、待てよベクトルが使えたような・・・とやってるうちに馬鹿馬鹿しくなりました（笑）
わかりやすく言うなら、めんどくさくなりました。
そこまで厳密にやる必要があるか？と。
自機の範囲を表す四角形と背景の範囲を表す四角形で良くね？と。
当たり判定をシビアにするか甘くするかは、厳密なラインが無くても自機や背景の範囲を実際に表示されている絵より大きくしたり小さくしたりでカバーできると思われます。
その点は円の当たり判定も一緒ですが、直線メインで描かれる背景は四角で表現した方が判定対象となるオブジェクトの数を少なく出来るでしょう。
頭の中で考えただけでも、明らかに四角形の当たり判定の方が処理が軽そうだし、それでカバーできないほど複雑な形のマップを描いてしまったら、またその時に考え直せば良いかと。


















こんな感じで四角形AとBを描いて各座標の状態を調べます。
Aの左上・右下の座標を（X0,Y0）、（X1,Y1)
Bの左上・右下の座標を（X2,Y2）、（X3,Y3)　とした時に
X座標、Y座標それぞれについて、接触しない状態を考えます。
『接触しない』状況を考えた方が最終的になぜたった4つの条件で判定できるのか理解しやすいと思います。
例えばAがBの左側から近づいて行った場合をX座標でみると、AのBよりの座標X1がBのAよりの座標X2より小さいうちは接触しません。
右側から近づいた場合はお互いさっきと逆側の座標で比較します。つまり、X0がX3より大きいうちは接触しません。
同じ事を上下方向から近づいた時のY座標でも考えます。
そして、これらの条件は『接触しない』条件ですから、この条件の不等号を逆にしてやると『接触する』条件が現れます。
その条件はたった4つ。

X0＜X3、X2＜X1、Y2＜Y1、Y0＜Y3

これだけです。
当たっていればTRUEを返す関数をコードにすると

～前略～
if ( (X0<X3) && (X2<X1) && ( Y2< Y1) && (Y0<Y3) ) return TRUE;
～後略～

って感じです。これは見るからに軽そうです。

で、サクッと実装できると思ったんですが意外と苦労しました。
スクロールに合わせて当たり判定の位置も動くからです。
背景の当たり判定用の四角形の座標を1ドットスクロールするたびに全て動かすのは、あまりに頭が悪そうだな（効率悪そうだな）と思ったので、自機や波動砲に2つの座標を持たせました。
1つは前からあった画面に表示するときに使う画面上の座標。
で、もう1つが新しく増えた背景座標系内の座標。
この座標は表示サイズよりも大きい背景画面の何処にキャラクターがいるか表す座標で、画面上の座標にスクロールしたドット数を足すと求められます。
この座標をもとに当たり判定の四角形の座標を求め、同じ座標系の背景の四角形の座標と比較して当たり判定を行うわけです。

今はまだ背景がループするので、その辺の処理がまた余分に面倒でした(笑）
1ステージ分の背景を作りきってしまった方が、ループが無いので処理はシンプルそうな気がします。
ただその場合、背景の四角形も相当な数になるので、沢山の中から画面内に入っている分に関してだけ当たり判定を行うようにしないと無駄が多くなる気がします。

実行ファイルを。
申し訳ありませんが見た目は何も変っていません。
ソースもいつも通り同梱です。
http://multip.net/view/f10PgPvBrW

そろそろ関数とかを整理してソース見通しを良くしておかないと自分でもいじりずらくなるかな・・・。