2Dプラットフォームゲームで、プレーヤーが傾斜した地面をスムーズに動くようにする方法は？

2Dプラットフォームゲーム用の物理エンジンを開発しています。衝突検出に分離軸定理を使用しています。地面は、プレーヤーを軸に合わせた境界ボックスとして、方向付けられた境界ボックスから構築されます。（具体的には、SATを使用してOBBのスイープ衝突検出を実行する「Realtime Collision Detection」という本のアルゴリズムを使用しています）。動的オブジェクトが環境に侵入しないように、衝突応答でかなり小さな（ゼロに近い）復元係数を使用しています。

エンジンはほとんど正常に動作しますが、発生する可能性のあるいくつかのエッジケースについて心配しているだけです。たとえば、図では、A、B、Cが地面です。プレーヤーはBに沿ってAに向かって左に向かっています。不正確なため、プレーヤーボックスはボックスBのわずかに下にある可能性があります。したがって、Aに到達すると、プレーヤーの左下隅がAの右側と衝突する可能性がありますが、これは望ましくありません（プレーヤーがAの上部をスムーズに移動するためです）。プレイヤーがボックスCの上にいて、Bに向かって左に移動すると、同様の問題が発生するようです-プレイヤーの左下隅が上下にスライドする代わりに、Bの最も極端なポイントがプレイヤーの左側と衝突する可能性がありますBの上

Box2Dは、エッジ形状の接続情報を保存することでこの問題を処理しているように見えますが、この情報を使用して問題を解決する方法がよくわかりません。

どんな提案も大歓迎です。

プラットフォームと物理学

これらのエッジケースは多数あります。楽しい楽しいプラットフォーマーは、物理的に正確な方法で動作しません。マリオのような「完璧な」プラットフォーマーの長年の後にプレイヤーが期待する制御と動作は、Box2Dや他の物理エンジンで得られるような一般的なテクニックでは実装が非常に困難です。ほとんどの優秀なプラットフォーマーは、プレーヤーコントローラーで一般的な物理学や衝突応答を使用しません。

ハルを生成

あなたの特定の質問に関して、最良の解決策はあなたの根拠として箱を使うのをやめることです。一連の接続されたラインセグメント（船体）を使用します。これにより、衝突検出エンジンは、実際に歩行可能な表面のみに焦点を合わせ、ABとBCの間に存在する「偽の」エッジを見ることができなくなります。それが実際、Box2Dの機能です。シェイプは、外表面を生成するために使用され、外表面は互いにリンクされて船体を形成します。

これは、タイルベースのゲームでも、フロアとして機能する他のAABBオブジェクトの隣に2つのAABBオブジェクトがある状況でも必要です。衝突エンジンはこれらの垂直エッジをピックアップし、プレイヤーにそれらをキャッチさせます。ハックがありますが、問題を解決することはできません。解決策は、完全な2Dボックスではなく、表面を表す単一の線分セグメントを持つことです。

ポリゴンを相互にクリップし、クリップポイントをエッジリストに結合することにより、一般的なケースでハルを生成できます。

傾斜面

例には勾配が含まれており、反発やその他の物理的特性に言及しているため、すぐに気付く他のいくつかの問題を指摘します。これは、一般的な衝突検出と応答がプラットフォーマーにうまく機能しない理由をさらに示しています。まず、傾斜したプラットフォームに立ち、ジャンプしてから着陸します。着陸時にキャラクターが少し「スライド」することに気付くでしょう。問題は、あなたが生成している接触法線が通常、傾斜した表面から外に向いていることです。次に、衝突を解決するときに、プレーヤーはその方向に押し出されます。キャラクターが真っ直ぐに倒れたとしても、着地時に彼は少し右に押し上げられ、スライドになります。これは、相対速度を考慮することでハッキングできますが、

気付く2番目の問題は、修正するのがはるかに難しいことですが、ランプを急いで走ろうとするとどうなりますか。プレイヤーは、ランプを「ホップ」します。これは、今日のほとんどのAAAゲームでも非常に顕著です。馬鹿げているように見えるだけでなく、ジャンプするためにプレイヤーが地面に足を踏み入れる必要がある場合、プレイヤーはランプのほんの一部の間にランプに接触するだけなので、ランプを走って途中でジャンプするのが難しくなりますそれを下るのに費やした時間。より簡単な修正方法は、プレーヤーが移動するときにレイキャストをいくつか行い、プレーヤーがジャンプしておらず、かつて地面にいた場合は、プレーヤーの位置を最も近いサーフェス（プレーヤーに非常に近い場合）にスナップします。

また、プレイヤーが通常の剛体であるかのように、プレイヤーの速度、摩擦、反発をモデル化しようとすると、ランプを走るときにプレイヤーが空中に飛び出すことがあります。プレーヤーの動きは、落下/ジャンプしない限り、水平方向の動きに制限する必要があります。もちろん、古い黄金時代のプラットフォーマーをプレイする場合、プレイヤーの水平方向の速度は、水平面と傾斜面の間でしばしば一定であることに気付くかもしれません。これは、坂を上り下りするときにも考慮する必要があります。

最終的には、他の奇妙なコーナーケースもいくつか発生します。優れたプラットフォーマーを作成しようとしている場合、一般的な物理学と衝突応答アルゴリズムに依存するのではなく、物理学とは別にプラットフォーマープレーヤーコントローラーを実装し、必要な動きと制御動作をハードコードするのが最善です。

両方の問題は、衝突応答の目的で、丸みを帯びた角（数値誤差と同様の半径）を持っているかのようにボックスを処理することで解決できると思います。これにより、AとB、およびBとCの間の会議コーナーの効果的な結合表面がより滑らかになります。

したがって、左に移動するPLAYERがAの角に当たると、コリジョン法線は純粋に右方向ではなく斜めになり、左から上への動きを継続できます。

しかし、プラットフォーマーの物理学について私が知っていることを検討する上でのより典型的な解決策は、プレイヤーをより丸みのある形状にし、地形をそのままにすることです。特に、プレイヤーの形状をカプセルにすることを検討してください（真ん中の円（2D）/球（3D））—衝突法線は自然にほぼ垂直になり、キャッチの問題がなくなります。

OBB専用のコリジョンアルゴリズムを使用していると言いますが、OBB-OBBコリジョンを検出した後、OBB内に完全に収まる形状に対してさらにテストを実行できる必要があります。