ブログ

今日は。
なんだっけ。講義受けて・・・即帰り。
帰って来てから・・・またシューティングいじって。
そう。
どう改造するか決めてた。

で。
こうした方が便利かな？の繰り返しで、どえらいことになってしまった。
入力コマンド管理とプレイヤーの表示画像管理を別のクラスでやるってのも、
まあ無茶というか、無駄というか、なんだけども。
画面に表示する画像すべてを別クラスで管理とか、
画面上の当たり判定をすべて別クラスで管理とか、
思い立ったはいいものの、改造量が壮大すぎる。
でもそうでもしないと、正直馬鹿なオレにはやりにくい。
特に当たり判定。

各画像の当たり判定範囲の情報として必要なのは実質
判定を取る大きさと、座標と、あとはその判定の有効無効だったりする。
判定を大きさが変わる時ってのは、画像そのものがデカくなることと同意とすると、
わざわざ巨大化するためだけに画像を用意するような特例なわけで。
そういうことは今回する予定もないし、大丈夫だろうということで。
そういう状況で、だよ？
個々のクラスで生数値打ち込んで当たり判定の大きさを
設定しなきゃいけない現状がどうも気に入らない。
ゲーム全体として、どういう当たり判定を持ったものが
ステージ上にあるのか、把握しにくくて仕方がない。

我思うに。
「現在の画面のこの部分には今一体何がありますか？」と聞かれて、
「これとこれがあります」とか返してくれた方が断然いい。
返答によっての動作は受け取った側で決めるとして、
そこにあるすべてが何か分かるような状況の方が、断然分かりやすい。
プレイヤーも敵もブロックも。あるいは敵とブロックの各種類すら。全部。
破壊できるできない、当たると死ぬ死なない、それ以上移動できない。
そういうことは後で考えることであって、そこにあるかないかという問題の方が先。
・・・だと馬鹿は思うのです。

そこを全部管理するとなると、表示する画像の大きさだとか
位置も、一括で管理してしまえばいい。
各画像の位置の移動は各クラスで行うにしても、その移動によって
当たり判定位置がどう移動したか把握しなきゃいけない。
ということは、画像がどう移動したかも把握できる。
どうせ画像の大きさも設定しなきゃいけないんだし、
先に画像の初期設定を全部済ませてしまうクラスを作ってしまえばいい。
移動先の座標だけ設定して、指定されたものを移動させるだけ。
もし表示する画像のタイプを切り替えるのなら、
切り替える画像のインデックス値とか、アルファ値とかだけ受け取って、
それを反影させた方が、オレ的にはやりやすい。

そうなると、画面上に表示するものには種類別IDが必要になる。
でも、それで一括管理できるのなら、それに越したことはない。
「その種類のオブジェクトはこの画像で、この当たり判定のサイズです。
移動や画像変更あればどうぞ。あ、今これと重なってますよ」
とか。そういう感じ。
言うのはいいんだけどね。結構厄介なんだよね。
画像の読み込み場所と、画像の移動はそれぞれ別クラス。
当たり判定も各クラスで当たり判定サイズを持たせておいて、
そのサイズを参照しては当たってるか判定、当たってるか判定。
オマケに、複数の敵とか、複数の弾との当たり判定も、ループ管理状態。
そう。ループで管理してるからこそ、画像が重なっていても、
一つ一つを管理することができるわけで。
それをまとめて管理するとなると、どう実装するのか。
・・・。
考えればできそうな気もする。
画面内オブジェクトの個数管理と種類管理、座標管理っしょ。
逆算して当たり判定範囲が出せるし・・・
うん。多分。
出来ずに自滅してやる（そっちかい）