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

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




















このスクリーンショットではわかり難いんですが、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

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

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

背景スクロール実装

とりあえず仮で背景を描いてスクロールさせてみました。
最初の方で自機を操作できるようにしたとき、自機が画面外に出てもエラーにならないことを知りました。
つまり表示されている画面の外にも描画できるって事ですよね。
ってことは画面サイズより大きな絵を描いて、あとはそれを表示する座標を動かしてやればスクロールは実装できるはずです。

で、想定通りできました。
もっと躓くかと思っていたんだけども、あっさり成功。
ササッと描いたので、絵の出来には突っ込み無しで（笑）
まあ、本腰入れてもたいして変らないと思いますが・・・。











なんかスクリーンショットはだいぶＲ－ＴＹＰＥっぽくなってきました。
いや、親の贔屓目全開ですが・・・w






上下の壁などと同じ絵の中に描いた星空と別に、画面サイズと同じ大きさで真っ黒な画像に星を描いて、背景の1枚奥に表示しています。
手前の背景は1フレーム毎に1ドットスクロールし、奥の星空は手前の背景のＸ座標を2で割った余りが0の時だけ1ドットスクロールします。
つまり、奥の星空は2フレームに1ドットスクロールする事になります。
この背景2枚をスクロールさせるのは試しておきたかったことの1つで、これが出来れば今回やるかどうかは別として、背景の多重スクロールが簡単に実装できるか実験できると思いまして。
あとは絵の端が切れるタイミングでループするように表示するだけなんで、プログラム的には簡単でした。

ちなみに当たり判定はまだ無いので、自機も敵機も波動砲も、壁を突き抜けます。

では実行ファイルを。
操作、ダウンロードについては＃８の記事を参照してください。
http://multip.net/view/4maUo603x2

画面だけはいっちょ前になってきました。

 

休日

昨日は仕事が休みで、朝から家族サービスしてました。
毎晩、子供寝かしてからパソコン部屋に引きこもるわけにもいかないんで(笑)
昼間、近場のショッピングモールに出かけ、たまたま遊びで妻が買ったナンバーズがボックスで大当たり！
3万円強の儲けです(笑)
換金したら、服とかたまには自分の好きな物買いなって言ったら喜んでました。
夜、子供を寝かしてからは二人でお茶しながら最近妻がハマってる数独をやってました。
上級問題はけっこう難しいもんですね。
それでも、わりと得意分野なんでサクサク解いていると、妻が悔しがってました。
妻と雑談しながらも、これを解くアルゴリズムはどんな感じになるのかなぁなんて、頭の中でコードを書いてました(笑)

そんなわけでシューティングゲームは進んでません。
今後は、とりあえず仮の背景を描いてスクロールの実験、敵をゲームの進行に合わせてスケジュール通りに出すプログラム、そして背景との当たり判定って感じで実装を進めようと思ってます。
そこまで出来れば、あとは実際に使用する背景を描いたり、敵の種類や動きを増やしたりと、時間をかけてやってゆく作業的な部分がほとんどになってくるので、完成できる確率もかなり高くなるんじゃないかと思います。
焦っても仕方ないんで、ひとつひとつじっくり組んで行きます。