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

もう２０回目ですか・・・。
大きなギミックを実装する時以外は、基本的に敵の出現スケジュールファイルを書き換えてはテストプレイ、敵の移動関数を修正してはテストプレイの繰り返しになります。
出てくる敵を増やすとその前後も調整してバランスを取ったり。
はっきり言って地味な作業の連続なんですが、おそらくこの作業がシューティングゲームの面白さを決めるファクターの半分以上を占めているんじゃないかと思っていたりします。

基地侵入前の部分に関してはあと一機、上空に向かって破壊可能なミサイルを連発する移動砲台を実装できればパワーアップアイテム以外の部分でRーTYPEの基地侵入前のギミックは網羅できた事になるんじゃないかと思います。
敵の出現位置やタイミングはかなり違うと思いますが、もともと移植が目的ではないので。



















ほんと、少しずつですが確実に進んでおりますのでご安心を。
いや、誰も心配はしてないと思うのですが。
実行ファイルのアップタイミングはけっこう悩んでいたりします。
やはり、ある程度大きな進歩があってからやるべきですかね。
ただ、もし初心者の方がソースを見ているなら、あまり一気に進めると前回までのソースと比較しずらくなるんじゃないかとも思います。
まあ、どうでもいいか（笑）

あ、そうそう、各敵機は出現時の初期化の際に乱数を一つ持つようにしました。
今のところの使い道はアニメーションです。
今まで同じ敵機が複数画面にいる場合、全員が同じタイミングでアニメーションをしていました。
時刻をキーにして表示フレームを割り出しているので仕方なかったんですが、各キャラクターの持っている乱数を時刻に足してから表示フレームを計算することで解決できます。
よってアニメーション関数に渡す値が一つ増えました。

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

歩行戦車の動きを作りこむ

お粗末なグラフィックで走っていた移動砲台を描き直しました。


















４本足にしちゃった。えへへ・・・。
攻殻を見てる人にはバレバレだろうけど、モデルはタチコマ君です（笑）
４本足でチョコマカ動く姿は、我ながらなかなか愛らしく描けたんじゃないかと。

動きも後半に出てくるのは進化しました。
自機を追って来ます。
互いのX座標を比較して、自機の方に動かしてやるだけなんですが、そのままだと止まると言う事がほぼ無く、常にせわしなく動いている感じになります。
これではいかにも単純なプログラムで動いているっぽくてリアリティがありません。
そこで、自機のX座標に一定間隔まで近づくと、１秒間停止するようにしました。
たったそれだけなんですが、動きは格段にソレっぽくリアルになります。

ロボット型の敵の動きに小さな波運動を加えたときも思いましたが、「こう動かしたい」をそのままプログラムするだけで終わりにせずに、どう見えるかを意識してほんの一手間加えるだけで格段に見栄えが良くなりますね。

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

敵機の移動は今まで状況に応じて直接座標を増減させていたんですが、移動用のベクトルを定義してこれを座標に足し引きすることで移動するように変更しました。
敵弾を動かす処理と同じ考え方です。

現在のところは座標を直接増減させる方法でも問題なかったんですが、後々敵機が動いているのか止まっているのかなどの情報を得たい場合が出てきた時に、ベクトルを使っていればその値から判断できます。
重力や慣性を取り入れた動きなど、物理的な動きをさせたい場合もベクトルを使っていた方がやりやすいはずです。
処理的には少し複雑になるので、シンプルな動きしか必要ないゲームでは無駄が出てきますが、シューティングゲームや、アクションゲームなど動きの種類が多く複雑なジャンルのゲームではベクトルの概念を導入しておいた方が応用が利きます。

重力などの様々な条件が含まれる処理の流れを比較すると、

座標を直接いじる場合
座標　（X，Y）　＝　様々な条件を考慮した値

ベクトルを取り入れた場合
移動ベクトル　（X，Y）　＝　基準ベクトル値　＋　重力ベクトル　＋　摩擦ベクトル　＋　慣性ベクトル　＋・・・
座標　（X，Y）　＝　座標　＋　移動ベクトル

って感じになります。
文章で見ると「なんだ、座標直接いじる方がシンプルじゃん」って感じでデメリットが無いように見えますが、実際プログラムしてみると『様々な条件を考慮した値』をどうやって得るのかといった問題がおきます。
条件は動きによって異なってきます、必要な条件を考えてそのつど値を入れて行くわけです。
では、ゲームバランスを調整する過程で、重力と摩擦の係数だけ少し変えたいとなったらどうでしょう。
全ての動きに関して入れる値を計算しなおす必要が出てきます。
そういう場面はゲームを作っているとしょっちゅう起こります。
ゲームプログラミングを始めて１ヶ月半の僕にさえ相当な回数訪れています。
つまり、プログラム的には無駄がないのだけど、プログラミング的には無駄が多くなります。

そこで、ベクトルを導入します。
まず基準ベクトルは初期値だったり、前のフレームの移動ベクトルだったりです。
そこに必要な条件ベクトルを加算してゆきます。
例えばジャンプ運動で考えた場合、上昇中は前のフレームのベクトルに重力ベクトルを加算する事で徐々に上昇スピードが落ちてゆきます。
ジャンプの初めに与えた上昇方向のベクトルを、加算して行った重力ベクトルが超えると下降し始めます。
下降中も同じく重力ベクトルが加算されるので落下するまで下降スピードがどんどん上がってゆきます。

各条件ベクトルは、それぞれを計算する関数によって得られるようにしておくとソースがわかりやすくなります。
で、上に書いたように条件の要素を変更する必要が生じた場合どうなるか。
例えば、重力加速度を変更したい場合は、重力ベクトル計算を行っている関数内の重力加速度の値を変更してやれば、重力ベクトルを条件として使用している全てのキャラクターの動きを修正する事が出来ます。
プログラムの規模が大きくなって複雑になるほど、これが便利になってくると思います。

また、最初の方に書いたようにキャラクターの動きの状態を知りたい場合があります。
例えば走るアニメーションがあるキャラクターの場合、まず止まっているのに走るアニメーションが表示されたらおかしいです。
また、右に走っているか、左に走っているかなども知る必要があります。
右に走っているのに左向きのアニメーションを表示したらおかしなことになります。
そのフレームでの移動ベクトルを調べる事でそういった情報が得られます。
移動ベクトルが　（０，０）　なら止まっているし、X成分が０より大きければ右へ、小さければ左へ動いているといった具合です。

長々と書きましたがゲームの見た目はまったく進歩していません（笑）
ベクトルの導入にけっこう手間取りました。
が、こういうのは気付いたら早めに変えておかないと後が大変です。
敵の種類が20、30になってから全ての移動関数の処理概念を変更するようなことはしたくありませんから。

あと、別ファイル化した敵のデータにも無駄があったので修正しました。
当たり判定用の半径はファイルに持っていなくても、初期化のときに敵の種類を調べて値を入れてやるほうがシンプルです。
敵機の当たり判定の大きさを調整する場合にファイル内に何十何百とある半径データを書き直すよりは、プログラム内に一箇所ある半径の数値を変えてリビルドする方が効率が良いかと。
あと、爆発グラフィックを表示するために破壊された時刻を入れる変数（破壊されていなければ0）があったんですが、これも出現時は絶対に破壊されていないわけですから初期化する際に0を入れときゃいい話です。

本日は見た目に反映されない地味～な更新でした。
でも、たまに書いてきたプログラムを見直して気付いた範囲で最適化とか修正とかする時間を意識的につくることはけっこう大切なんじゃないかと感じてます。

いや、それにしても時間かかります。
あきらかにぷよの時より時間がかかりそうです。
２ヶ月はかかるかな・・・っていうかまだゴールが見えないので予想ができない・・・。
今のところぷよの消去アルゴリズムほどの問題に当たっていないので、単純に作業量の違いでぷよより時間がかかっているって事ですね。
もう少し進むと、観覧車のように回転する敵砲台のギミックがあるので、そこはちょっとした壁になってくれそうな予感・・・。
オラ、なんだかワクワクしてきたぞ！

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

地面を歩くロボット型移動砲台（？）実装




















非常にお粗末な絵ですが、現状でちゃんとアニメーションして歩きます。
とりあえず左に向かって歩きながら一定確率で自機に向かって弾を撃ってきます。
ゆくゆくは、自機との位置関係によって左右に動く場面も出てくるので、その時は新しい移動パターンを実装し、向きの概念を持たせて左右反転グラフィックも表示できるようにしなければなりません。
ちなみに地面を歩いているように見えますが接地処理をしているわけではありません。
左へ真っ直ぐ敵機を飛ばすのと同じ関数で移動させ、表示をアニメーションにしてるだけです。

ちょっと歩くアニメーションがコミカルすぎて可笑しいです（笑）
他のキャラと世界観があってません。
まあ、ぷよのときと同じく、まずゲームとして動くようにする事を最優先して進めます。
絵は頭が疲れたときに、息抜きがてら少しずつ描くので勘弁を。

あまり変ってませんが報告として実行ファイルを置いておきます。
http://multip.net/view/RUrUP2aEAN

操作やダウンロードについては過去の記事を参照してください。
ソーステキストファイルも同梱されています。

 

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

ロボットタイプの敵実装




















ロボット型の敵機を作ってみました。
画面端で自機に高さを合わせながら、波動砲のような弾を一定時間間隔で撃ってきます。
上下移動だけだとそれっぽく動かないので、半径を小さめに設定した上で波運動のルーチンを通す事で動きに揺らぎを持たせています。

同時に敵データに固さのデータを追加しました。
このロボット型の敵機は波動砲最大溜め撃ち２発で倒せます。

さらに敵データに出現してからのフレーム数を追加しました。
これによって、出現してから１秒は下方向に動き、その後０．５秒掛けて左方向へカーブを描き、1.5秒過ぎからは画面端に切れるまで左へ真っ直ぐ飛ぶといった感じで複雑な動きをさせる事が出来ると思います。
また、今回のロボット型の敵機のように一定時間感覚で玉を打つといった処理も可能になりました。

あとは、敵弾に通常段、波動砲など、タイプを表す変数を設定して参照しながら表示しています。


～追記～
恥ずかしい話ですが、敵機の動きを確認するテストプレイの際に、目的の敵にたどり着く前に撃墜されるケースが出てきたので、自機の当たり判定部分のソースをコメント化して無敵状態になってたりします（笑）