「funyak」に関する日記(5)

共通当たり判定の板と針の位置補正の一般化をがんばってきたけど、納得いくものに全く近付きもしないので、いったんそれは置いといて別のところを実装し始めました。
ひとまずは、ふにゃの場外死を実装。
次あたりは、とげとげを実装しようかと。

急斜面でしゃがむとはじき出されるのどうにかしたい。

動体同士の当たり判定は難しい。
Unityなどの本格的な物理演算でさえ、高速移動すれば簡単に当たり判定図形を突き抜けてしまう。
ふにゃさんでは、ウナギカズラでこの問題が顕在化した。
続投させるなら対策は必須だろう。
もし、片方が静止していると見なせるようにしたなら…？

テストデータの不備が見つかって修正。
あと、斜面のテストをもっとできるようにマップの調整も。

幾何学的なところで解決を見たが、実装が大変そうだ。

MainMapObjectは何かと複雑なので、ちょいと幾何学的なところを整理中。

針は、伸びる。

PlateCollider用の属性実装。
MainMapObjectは何かと複雑だ。

当たったときの反応はMapObjectごとよりColliderごとのほうがいいだろうということで、Collider側にListenerを設置。
PlateCollider(板)にも属性があったほうがいいだろうということで、CollidableSegmentの置き換えを目指して実装中だけど、ちょっと微妙な感じ。
とりあえず、最初に共通当たり判定を適用するのは、代表的な板であるLineMapObjectと、全ての中心であるMainMapObjectにしようと思います。

パフォーマンス関係でどんな処理にするのが速いかいろいろ計測。
やっぱ6-FPS出したいですしね。
構造体に関しては、ベンチマークプログラムをGitHubに公開しておきました。
StructBench

MapObjectの削除を実装。
削除した結果を見た目に反映はしないし、削除機能が発動する機会も今のところないけど。

判定図形の登録・解除はMapObjectが行う。
そのために、Mapは登録・解除が想定されるタイミングでMapObjectに対してCollisionManagerを渡す。
そういえば判定図形の解除の前提となるMapObjectの削除を実装していなかった。
これはゲームとして成り立たせる場合必須の機能だ。

共通当たり判定をとりあえず作ったはいいが判定図形の登録を考えていなかった。

共通当たり判定は一度シンプル(だけど非効率的)な方法で実装してみよう。
効率化はそのあとだ。

板と針に相当する部分実装。
板側は、何パターンか用意できるように想定。
頻出するであろうタイルグリッドタイプに特殊実装を入れたい。

テストのカバレッジ調べてみたら、92%ぐらいになっていました。
しかしこれは、テスト対象としたクラスだけを見てのものなので、そもそもテスト対象になってすらいないものは計算に含まれていません。
そう考えると結構テストしてないのでは…？

遊びを作る方面での進捗はゼロだけど、コミットしまくっといた。

コミットせずに開発してたらなんかごちゃごちゃしてきた。

当たり判定周りをちまちまと開発中…。

共通当たり判定のための判定図形リストはマップ側にまとめて持つ。
マップはマップオブジェクトに対し、判定図形の登録削除インターフェースを提供する。
マップが当たり判定を行うと、マップオブジェクトが判定図形の情報を得る。
判定図形はマップオブジェクトの都合で追加の情報を持つことができ、例えば、ほっぺに当たったとか、おでこに当たったとかを判断して制御できる。
こんな感じか。

試しに抽象クラスにしてみたところ、どうにもうまくいかない。
インターフェースのプロパティと抽象プロパティの扱いが異なっていて、抽象プロパティだと基底クラスで読み取りのみとすると派生クラスで書き込み可能にすることができない。
基底クラスの段階では、読み取り機能だけ保証して、書き込みは派生クラスの方針に任せるようにしたいのだ。
そもそも、強制しなければならない共通実装とは具体的に何だったのだろうか？