わからないことを放置して作り進める。
動かないときにあらためて振り返ったらよいやの気持ち。

それでも何がわからなかったのかを備忘録としてここの日記に残しておいて、
いろいろあれして、これして、そうなったら掲示板で聞いてみよう。
そんな気持ち。気持ち大事に。

備忘録ってびぼうろく　じゃなくて　ぼうびろく　って覚えてしまってて困る。
ぼうびじゃなくてびぼう　って脳内変換を毎回してしまう。ってそんなに備忘録って単語を使ったこと無いが。
一応ぐぐって調べたらこれどっちも正解ってことなのかもしれない。ぼうびろくだと変換できないけども。

ＳＴＧ進捗としては、敵の絵を描いている。
当たり判定用に。
しっかし何も考えずになんとなしの大きさで描いてたのだけれど、
当たり判定を考えて描くべきということに気づいた。知った。

ある程度四角形に収まるか円に収まらないとこれ当たり判定すげぇめんどくさいんじゃねぇの。と。
占　こんな感じの敵を描いてたら、これ上の　ﾄ　の部分にも当たり判定が必要で、
占これ全部を占める長方形が当たり判定だとトに届く前に敵が死んでしまう。不遇の死だ。

同人　というとかっこいい？かどうかは置いといて、
まぁ、元ネタのある既存のキャラクタで作ってみてる訳で案外元のキャラクターの形がとっぴなわけで。

とっぴといえば、とっぴーって食パンにかけるふりかけあったような気がするけど、まだあるのかな。
もともと食パンがあまり好みではないので、すっかり食パンにかけるもの業界の話には疎くなってしまった。
アンテナが低いのはよくないとは思いつつも今日も元気に生きる。

ＳＴＧとか全然やらない人から見ると
　完全包括領域　→　ここは当たってないよ領域群
という２段構え程度で判定する　くらいでいいんじゃないかなーとか思うのですが，どうなんでしょう？

占　の例で言えば，

最初はこの絵全体を包括する矩形なり円なりで判定
→弾がこの領域に入ってなければその時点で当たってないので終了
→入ってる場合，
　たとえば　トの左側　と　右上　の２つの四角い領域はセーフ！　ということにして，
　この２つの矩形チェックで不遇の死をいくらか回避する

みたいな．

プログラムの都合に合わせて絵の形を決めるというのも必要かもしれないけれど
できれば　絵に合わせて判定領域を設ける方が，
なんというか　自由というか，抑圧されていないというか，なんかそんな印象．

こめんとありがとうございますー。

>>プログラムの都合に合わせて絵の形を決めるというのも必要かもしれないけれど
>>できれば　絵に合わせて判定領域を設ける方が，
>>なんというか　自由というか，抑圧されていないというか，なんかそんな印象．

たしかにですねー。
作業を一人でやってるとどの作業にリソースを割くべきかよくわからなくなってしまいますわ。
めんどくさいからって回避しちゃあだめですね。うん。
私の場合一人でやってると、楽なほうへ楽なほうへ逃げてしまいがちなのでコメント助かります。



以下独り言メモ。
全体当たり判定と当たらない判定を複数持たせる場合、当たらない判定の数も敵データに必要？
形状によっては当たらない判定より、当たる判定の数のほうが少ない場合<処理が少ない場合はどうするか。
フラグで管理？
一体の敵に対して何回くらい判定してもセーフなのか。

途中だけど投稿

当たらない判定じゃなくて　より細かい当たり判定：複数の領域で構成　でもいいですが，
要は　荒い判定→細かい判定　という段階でやるという話で，
敵の種類によって　形の複雑さに大きな差があるようなら
細かい判定の個数とかも敵毎に変えれた方が便利かもしれませんね．

そういう「データの具合が敵毎に異なる」のが嫌な感じだったら
４分木的な判定にして，木の段数を全敵で固定にするとかでもいいかもしれませんね．

弾が一番大きい包括矩形に入ってる
→弾の座標はそれを４分割したエリアのどこに入っているのかを計算
→そのエリアに弾がある場合には当たる可能性があるのかどうか
→当たり得るなら，そのエリアをさらに４分割したエリアのどこに…

みたいなやつです．
結局は　どの程度細かい判定を必要とするのか？　によって取るべき方法が変わるのかな，と．

ああ申し訳ないです。
メモ代わりに投稿しちゃったのにまでレスいただいちゃって。
でもありがとうございます。

４分木。うわさには聞いていましたがここにきて必要なのかとぐぐりました。
理屈は説明していただいた内容でわかりましたが、はてさてどう実装するのかと。
よさげなページは見つけたのですが流し読みでどうにかなる感じじゃなかったです。
多分これ弾幕系ＳＴＧで必要な度合いが高かった気がしました。過去の記憶で。

どんどん知るべきこと学ぶべきことが多くなってきてうむむ。という感じです。
とりあえず形にすることをメインにすえていこうかと。
いや、別に大変そうだから避けるとかそういう訳じゃ　ない　はず　です。

>とりあえず形にすることをメインにすえていこうかと。
それでいいとおもいます．

私も　ある部分を実際にどうやるか　が決まらないときは
そこはとりあえず最も簡単で適当な方法を実装しといて
他のわかってる部分に注力する　ということで進めます．
例えば，今回の当たり判定だったら
とりあえず判定が甘かろうが厳しかろうが，他の部分が完成すれば「ゲームとしては動く」ので

bool CheckCollision( 弾, 敵 ) //弾と敵との当たり判定．当たってたらtrueを返す
{
//★ここはあとからちゃんと考える★
とりあえず１個の円で判定．
}

みたいな感じに関数なりなんなりにしておいて，最低限動くような実装だけしてとりあえずは放置．
全部動くようになってから関数の中身だけ書き換える予定，ということで．
ただ，それなりの期間放置していると，うっかり修正すべき箇所の存在自体を忘れてしまうので
そういう箇所には必ず↑みたく"★"を注釈にいれたりしてます．


あと，４分木とか言っといてあれですが
私自身「ここは４分木でいくぜ！ＯＫ！」とかいう確固たる形(?)では使ったことが無いような気がしますね．
（まぁ画像ピラミッドとか使ってれば　意味としては４分木なんですが）

いろんなことにつまづきながらのんびりとやっていきますよー。
がんばる。

>>そういう箇所には必ず↑みたく"★"を注釈にいれたりしてます．

これいいですね！
なんとなしにコメンで　後で　とか　そのうち　とか残しているのですが、記号おいとけば検索しやすい。と。
そのうち★まみれでキレイなソースになりそうです。
キラキラ。