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


18

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

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

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

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


一般的な物理エンジンは、効果や落下ボックスなどに最適ですが、回答セクションで説明されているように、キャラクターの物理には適していません。キャラクターの「静的な」物理学を作成することを検討してください。そうすれば、100%制御でき、残りは適切にシミュレートされたダイナミクスを使用できます。
ドミ14

回答:


14

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

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

ハルを生成

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

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

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

傾斜面

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

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

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

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


お返事をありがとうございます。地面を表すボックスを線に減らすことを検討していましたが、実際にはそれだけで問題が解決するとは思いません。たとえば、グラウンドボックスがラインになり、プレーヤーがラインCに立ってBに向かって左に移動している場合、不正確なためにプレーヤーボックスがラインCのわずかに下にある可能性があります。その後、プレーヤーボックスの左端可能性はまだ衝突ラインBと原因を持つことは望ましくない衝突、
ニックKovacの

これを防ぐ他のメカニズムがない限り。Box2Dがボックスの代わりに線を使用して問題を解決するのではなく、Box2Dがチェーン形状を使用し、線セグメント間の接続情報を使用して衝突の発生を防ぎます。現時点での主な問題は、これが正確にどのように行われるかについての詳細がよくわからないことです。
ニックコバック

ジェネリック物理エンジンからアイデアを取得し、それらをプラットフォームゲームに適用することに関する問題について、他のいくつかの本当に良い点を挙げました。あなたが議論したアイデアを実装する同様のエンジンを見てきました(坂道の衝突法線を修正し、プレイヤーを坂道に吸い込む)ので、少なくともそれらの問題はかなり簡単に解決できます。私にとっての最大のこだわりは、数値誤差に関連したトリッキーなエッジケースです。
ニックコバック

@Kovsa:繰り返しますが、これらの特定のエラーは、そもそも衝突の一部ではないはずのエッジを取り除くと消えます。エッジをつなぎ合わせて、途切れない形状を形成します。レベルを設計するとき、サーフェスに小さな隙間がないように頂点をスナップすることもお勧めします。3Dメッシュエディタでレベルを設計する方法と実際には違いはありません。
ショーンミドルディッチ

うーん...私は従うとは思わない。ダイアグラムでは、エッジをつなぎ合わせて連続した形状を作成すると、ボックスA、B、Cの上部の3つの線分で構成される形状が得られます。単一の形状ですが、ラインA、次にB、次にCに対して個別に衝突検出を実行する必要がありますか?ボックスとこの結合されたシェイプとの間の衝突を検出できるアルゴリズムを意味していませんか?一連のエッジが凹状になる可能性があるため、SATではないと仮定していますか?
ニックコバック

5

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

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


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

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


うーん、面白いアイデア...それをどのように実装しますか?ただし、ボックスを使用することの単純さに反します:(私はそれが最終的な解決策の一般的な問題であるように思われることに同意しますが、それについての報道を本当に見つけることはできません...行われていることを除いて。。BOX2Dに私はうまくいけば、より多くの洞察を得るために彼らのフォーラムで同様の質問投稿
ニックKovacの

実装の詳細はありません。申し訳ありませんが、この種の物理エンジンコードの専門家ではありません。しかし、ファッジファクターに基づいていないソリューションについては、より良いアイデアがありました。編集を参照してください。
ケビンリード

1
丸みを帯びた形状を使用しても機能しますが、数学的にはより複雑であり、プラットフォーマーにとって最適ではない動作になる可能性があることに注意してください。プレイヤーは、棚の上に立っているキャラクターをほぼピクセル単位で完全に制御できることを期待しています。たとえば、丸い形状は多かれ少なかれ不可能になり、キャラクターは予想外に棚から滑り落ちます。
ショーンミドルディッチ

レッジ:D'oh!OK、私が考えていたほど単純ではありません。
ケビンリード

ええ、それについて考えた後、カプセルアプローチはおそらく2Dプラットフォーマーよりも3Dゲームにより適しているようです。ピクセルの完全な制御を持つことは、私にとって間違いなく優先事項です(古い2Dプラットフォーマーすべてでそうだったように)。しかし、ボックスを使用できるソリューションが必要です!
ニックコバック
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.