HTML5:重い

　私の好きな隕石ドカドカ破壊ゲーを作成しているのだが……

＜現状＞
■画面作成（まぁただの真っ黒）

■背景の星
　ランダムに１〜２ドット程度の白に近い灰色（rgb(200,200,200)）の点をランダムな速度で下に移動させる。元の構想では色はランダムにしていわゆる「瞬き」を表現し、「キラキラ綺麗なお星さまになるやろなぁ」と思っていたのだが、これが想像以上にうざったかったのでやめた。真っ白じゃないのもうざさ軽減のため。真っ白だと目立ち過ぎて敵などと区別がつきにくくなると考慮した結果。

■自機
　簡単な飛行機。左右に移動した時に機体が傾くようにした。ゆっくりと傾いたり、元に戻ったりという動きを実装するためだけに、特別にタイマー制御をしているという面倒臭さ。
　追加でテスト的に移動速度を１〜９に変更出来る機能をつけておいた。

■操作
　特に問題無く。

■弾１
　前方に飛ぶただの弾。発射にウェイトを少しかけている。移動速度を15ドットにした。弾が8ドットで、敵の最小サイズも8ドットなので、16ドット以上の移動速度にしてしまうと、1フレームで敵を素通りしてしまうかもしれないのでやめた。一応対策としては「移動した範囲の当たり判定も取る」ということをすれば解決できるかなと思うのだが、現状で既に結構負荷があるのでとりあえず保留。

■弾２
　元々は「発射方向の変化による弾グラフィックの切り替え」のテストのために、360度グルグル自動的に発射する弾を出していたが、それも終わって現在は自動で最近の敵を狙撃する弾になっている。
　この過程でわかったのは、→から↓、そして←までの角度が０〜１８０度で、←から↑、そして→までの角度が-180度〜0度ということだった。昔からずっと0度〜360度だと思っていたのに。
　弾のグラフィックは24パターンあるので、360度を24で割って表示する画像の座標をずらすわけだが、実際には360度ではなく、180度から突然-180度になるので、どうしたものかと思ったが、結局「もしマイナスだったら+360する」という条件を追加してなんとかした。本当にこれでいいのか。

■隕石
　8x8ドットと16x16、32x32の隕石をとりあえず用意。最終的にはそれぞれ4種類くらい用意出来たらいいなと思っているのだが、隕石の絵を描くのが大変で、本当にそこまでやるかどうかは未来の私にしかわからない。
　32x32が破壊されると5個の16x16が出て、16x16を破壊すると8x8がまた5個出ることになっている。
　理想的な動きは「破壊前の親隕石の軌道を保ちつつ、少しバラけて子隕石が発生する」という感じなのだが、あまり画一的でも面白くないかなと思って思案中。
　隕石は弾が当たると、当たった事を明示すべく「白く光る」ようにしたかったのだが、いくら調べても「読み込んだ画像データの情報」を得る事が出来そうになかったので、仕方なく「ヒット時の画像を別に用意する」という力技に変えた。一応、キャンバスの画像データは得られるので、やろうと思えば「隕石用のキャンバスを別に用意してそこへ画像をロードすれば画像データを得られる」、そこで画像をいじればプログラムで白隕石を作成することも可能かもしれないが、「実際に使うわけでもないキャンバスを敵画像の数だけ用意する」みたいなのがなんか気持ち悪かったのでやめた。
　イメージを直接ある程度操作する方法くらい用意して欲しいものだ。

■火花
　弾が隕石に当たった時にパチーンと火花が散る演出。昔から結構好きでやっているのだが、これが思ったよりわかりにくい。1x1だと非常に小さく見にくいのだが、2x2だと妙に目立つ気がする……もしかしたらお蔵入りする演出かもしれない。

■ランダム関数
　指定した最小値〜最大値までのランダムな数を得る関数を自作した。じゃないと表記が複雑で……

　(Math.random()*最大値)+最小値

・左が最大値で右が最小値というのがわかりにくい
・（　）の入れ子っぽい感じがエラーを産み出しそうでイヤ

しかもこれ、得られる数値は

　(Math.random()*5)+1

だとすると　1〜5なわけだが、この1~5の間に1.xxxxxという小数点以下の数字もかかわる場合がある。基本的に整数が欲しいので、これを整数に直すために

Math.floor((Math.random()*5)+1)

としなければいけない。さらに入れ子になって（　）の管理が面倒に。

getRandom( 最小値, 最大値 )　←整数だけ
getRandom2( 最小値, 最大値 )　←小数点含む

という関数を別に作成した。あぁわかりやすい！

■爆発
　8x8ドットの爆発するアニメーションを作った。弾が隕石に当たった時と、隕石を破壊した時にポポポンと出るようにした。これが意外とそこまで違和感がない……気がする。


＜今の問題＞
・処理落ちによる画面のちらつき
　考えられる要因として、以前までは「全てのキャラの描画」と「全てのキャラの移動計算」を別枠にしていたのだが、それを「隕石の描画移動」「弾の描画移動」と、各キャラごとにまとめたせいだと思われる。
　そもそもなんで描画と移動をまとめたかといえば、大量に現れるキャラを動かすためにforループで回して各キャラにアクセスするわけで、描画と移動を同時にやればforループが1回で済むんじゃないか？　つまり負荷軽減のつもりだったのだ。しかしそれで画面がチラついてしまっては本末転倒だ。
　といっても、以前の描画と移動を分けていた時もカクっとたまに処理落ちをしていたような節があるので、以前の形に戻した所で、チラつかないだけで妙なカクつきは出るような気がしている。

　さて、どうしたものかというわけで、一番の原因であろう「隕石と弾の当たり判定チェック」をなんとかすればよさそうだとは思うのだが、検索で出てくるような「近い隕石とだけ当たり判定を見る」という仕組みを実装出来るのだろうか……。

　ていうか本来の構想では「隕石と隕石の当たり判定」もやるつもりだったのに、隕石と弾の当たり判定だけでこんなに重いんじゃあ無理かもしれないなぁ。