壁を作る - Githubissues

Marco3jp commented 2 years ago

ステージの外壁を作る
ついでに雑な実装になっている反射の実装を改善する
- あわせて、Componentの向きの概念を固める必要はありそう

Marco3jp commented 2 years ago

当たった相手が直線の場合の反射
- その当たった相手のどの面に当たったかの情報が必要
- これ今の情報から計算だけで算出できる？
- それに対する角度を算出して反射の計算をする
- 直線と直線の角度算出するの、どうするんじゃ
- と思ったけど、それぞれの角度を足し引き算で雰囲気でいけるじゃん
- 多分、 z = x - y; z > 180 ? z - 180 : z でいける
当たった相手が曲線の場合の反射
- 接線を引いて、それに対する反射の計算をする
- 直線に対する反射に落とし込むので、ロジックとしては直線への反射計算を流用する
- https://kou.benesse.co.jp/nigate/math/a13m1301.html とか参考になりそう

当たり判定のロジックにも手入れ必要かも
- ~width, heightを使って当たり判定を算出しているけどangleが0じゃないと意図した方向にwidthが向かないのでコメントに記載したような判定にならない~
- ~なのでwidth, heightとangleを用いて実際にx, y軸に向かってどのサイズがあるかを計算する必要がある~
- ~このロジック自体はsin, cosがあれば計算できそうな気がしてきた~
- あ、いやこれ違うかも、widthを当てているのはinstanceの生成時で、当たり判定を処理するときはgetBoundsで矩形をってるから大丈夫だ

Marco3jp commented 2 years ago

https://twitter.com/Marco_utau/status/1515017015849005057

このスレッドに当たり判定と反射のメモをした

Marco3jp commented 2 years ago

まずはミニマムにしたいので、1tick内に

当たり判定サービスが当たったことを検知
当たった場所を検索するサービスが座標を算出
反射を計算するサービスが反射を算出

を順番に叩くだけにしようなので1と2と3をもとに、進んだ距離を調整するとかは一旦しない

Marco3jp commented 2 years ago

あ〜〜〜でもこうなると、CollisionCheckerって名前がだんだん適さなくなってきたな物理処理全般見る形になっている気がする

Marco3jp commented 2 years ago

ただ、CheckerがないとTickerにベタ書きするしかなくなっちゃうんだよな当たり判定は別に反射に依存するものではないし、当たった場所の検索も反射に依存するものではないでも当たった場所の検索は当たり判定に依存する反射の計算は当たり判定、当たった場所に厳密には依存しないはず → これはどう分離するか次第で、ある直線に対する反射計算に落とし込むなら独立できる。となると曲線に対して接線を引くサービスが別で必要になりそう

Marco3jp commented 2 years ago

でも当たった場所の検索は当たり判定に依存する

これどうなんだろ、当たり判定のロジックにもよるけど、当たった直線、曲線をグラフとして抽出してこれるなら当たり判定のロジックとは切り離して単なる式に落とし込めるような気もする……？

Marco3jp commented 2 years ago

反射ロジックをサービスに切り出せたので、あとは衝突面の直線を出すサービスがほしい気はするなぜか衝突時に明後日の座標に飛んでいってしまう（そこで動いている角度は正しそう）ので、座標系と角度、移動サービス周りの関係性を整理して壁を作っても大丈夫にしたい

Marco3jp commented 2 years ago

衝突したことを判断することとか、反射角を算出することは比較的汎用なのかな〜と考えていたんだけど、後者はともかく前者はオブジェクト自身が持っていてよかったのではと思ったりしている

Marco3jp commented 2 years ago

衝突判定
- 今のロジックだとすべてのコンポーネント同士を比較している
- あくまで当たるかどうかに収めておいて、当たったあとのことは知らない
- 今は矩形衝突判定しかないんだけど、増やすなら https://davidfig.github.io/intersects/ を参考にするイメージ
- 何を判定する責務があるか
- 『このフレームの終点で衝突するアイテムがあるかを判定する』のはずだった
- 今は特に何も考えずにTickerにつけているので、各コンポーネントのTickerとどちらが先に処理されるか不明
  - = 『このフレーム前後で衝突するアイテムがあるかを判定する』くらいふわっとした感じ
- 『このフレームの終点で衝突するアイテムがあるかを判定する』のためには、このフレームの終点がどこになるかがほしい
  - 移動予測位置と、最終移動位置という概念が出てきそう
- 各コンポーネントのTickerより先に『このフレームの終点で衝突するアイテムがあるかを判定する』メリット
  - 各コンポーネントが onCollition を持つような設計ではなくて、 onTick で当たっていたかを見るのが可能になる
  - onCollition で処理するのもいいんだけど、例えば動く処理とか毎フレームの処理に介入することが設計上不可能
  - パラメータで衝突判定があったフレーム番号を記録すれば onTick で衝突判定がこのフレームであったことを確かめることができる
  - 各コンポーネントのTickerとしては1フレーム内での折返し処理とかも可能になる
- 今のところは『このフレーム前後で衝突するアイテムがあるかを判定する』で致命的ではない
衝突位置の情報
- ↑に書いた移動予測位置と最終移動位置という概念に基づいて直線を作り、衝突相手との交点を出すイメージ？
- 曲線と矩形だと例えば2点交点ができたりもするのか、うーんたしかに。Arrayで持ったほうがいいかも
- うーん、とはいえ仮に2点の交点を返せても次のステップで接線作ったとしてじゃあどう動くんじゃってなるよね
- 物理的に言えば矩形ではなく台形だった場合とかだと図形のバランスによって反射の向きが変わるとかになる？
- これは正直結構厳しいのと、ゲームデザイン上回避させていくのでいいと思う
- まあ、実際どうなるかわからんので耐えられるような設計にはしつつ、計算はしないつもりでエラー返すとかかなぁ
- 位置がわからないと、衝突箇所に対しての接線が作れないから必要
衝突相手の直線情報
- 衝突位置から接線（直線なら接触した線）を返す
反射判定
- すでにあるロジックでOK

Marco3jp commented 2 years ago

ここから作るもの

『このフレーム前後で衝突するアイテムがあるかを判定する』のままで衝突位置の情報を取る仕組み？
- うーん、もしかするとちょっと難しいかもしれない
- onCollisionのタイミングだとまだ角度は変わってないので、引き算していって当たらなくなった場所を基準にするとか？
- 点と角度がわかっていれば直線引けるので、相手の曲線なりブツがあれば計算させられるかも
- それでいうと相手のブツはArgにあるので大丈夫
- どうやって切り分けていこう
- うーん、一旦曲線との衝突はないかな？
- ボールとの衝突はあるけど、ボールを正方形だと思いこんで動かして大丈夫そう（どっちかっていうと早めにゲームデザインに入りたい）
- 四角形（直線で構成されたオブジェクト）に対して当たったときに、入ってきた側の直線を返す、というやつを作る
  - これはどこで呼ぶか
  - これは何を必要とするのか
  - あたりを考えよう
それとは別に衝突面とか、衝突される側、衝突側などの名称を確定させたほうが良いかも
- 反射のコンテキストだと reflective, wall ってなっているんだけど、実際はここで渡される wall って接線みたいなものなので、当たられる側を壁と呼ぶのはちょっと違うんすよね
- 例えばボールとボールが衝突するようなゲームデザインだった場合、 wall にあたるものって同時にreflectiveとしての処理が同じフレームで走ってるので説明がややこしい

Marco3jp commented 2 years ago

壁作って反射させることができたので一旦Done

Marco3jp / GameForMeProject

壁を作る #3