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

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

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

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

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

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

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

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

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

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

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

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

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

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