farseer / box2dのような2D物理エンジン内でAIパスをどのようにフォローしますか?


12

私は、Farseerのような適切な剛体物理エンジンに取り組んでいる2Dトップダウンゲームを動かしている最中です。これまで、必要に応じて自分の物理コードをハッキングしていました。

ここで物事を行う適切な方法を学ぼうとしています。

AIを物理エンジン内で剛体にした後、設定されたパスをAIに追従させる適切な方法は何ですか?

AIに追従する必要があるナビゲーションノードのパスがある場合、以前は次のタイムステップでの次の位置を計算し、その位置に手動で設定することで、パスに沿って手動で移動します。

しかし、今ではそれらは剛体であり、衝突や、それらにぶつかってそれらをパスから外す可能性のある力の影響を受けます。

だから、AIを動かすために、私は今、それらに衝動/力を適用すべきだと思いますか?フレームごとに手動で位置を設定する必要はもうありません。

だから私は決定論的世界からAIを強制的に非決定的世界に強制的に追いかける必要があると考えていますそれらを動かすために。

そうですか?それは他の人がそれを行う方法ですか?

これは、AIが正確な道を歩いていないので、AIが風景の隅に引っかかるのを避ける方法についてのいくつかの質問を提起します。

または、何らかの方法で2つを混合し、AIの位置を手動で設定して固定パスをたどり、簡単に制御できる特定の状況でのみ他の力に反応させる方が良いでしょうか?

アドバイスをありがとう。


1
+1これについても非常に興味があります。
デヴィッドゴーベイア

回答:


7

ステアリング動作は、通常は物理エンジンに適用できる「ステアリング力」を返すように実装されるため、物理エンジンと組み合わせて非常にうまく機能します。

ユニットをパスに追従させるには、Seekを使用してパスノードからパスノードに移動し(オーバーシュートを回避するようにしてください)、パスの最後のノードで到着を使用します。

行き詰まることについての懸念については、力を使用した経路追跡のモデリングは実際には非常に正確である必要があります。オブジェクトが他のオブジェクトと衝突した場合、オブジェクトがパスから外れることもありますが、更新のたびに操舵力を計算するため、オブジェクトはすぐに再び軌道に乗るはずです。衝突後のパスからの逸脱が潜在的に大きくなる可能性がある場合は、衝突が発生するたびに最後の位置を記憶し、オブジェクトをその最後の位置に戻してから通常のルートを続行することをお勧めします。


すばらしい記事、共有してくれてありがとう。私の一日を救った。
リカルドサンチェスサエズ

0

私はあなたが正しい軌道に乗っていると言うでしょう、あなたはこの記事を見たいと思うかもしれません:

http://www.policyalmanac.org/games/aStarTutorial.htm

A *アルゴリズムを使用した基本的な衝突回避と経路探索について説明します。

編集:

オブジェクトを正しい方向に推進する最善の方法が本当に必要な場合は、パス検索アルゴリズムを使用して見つけた最適なパスの方向を指す力(MovementForceなど)を使用する必要があります。選択


この記事がこの質問に関連しているとは思わない。OPは、2つの場所間の最適なパスを見つける方法ではなく、物理シミュレーションのコンテキスト内で、アクターが既に計算したパスをたどる方法を求めています。
デヴィッドゴーベイア

まあ、もう一度読んだとき、あなたの
意見がわかり

:)わかりやすいようにタイトルも変更しました。パスを見つけるのではなく、パスのフォローに明確に興味があります。
TerryB

0

@davidluzgouveiaが匿名の投稿にコメントしたことから判断して、プロジェクトを立ち上げます。ただし、パスの追跡とパスの検索は非常に異なります。経路発見は、匿名で投稿されたものの詳細であり、経路発見についてはダイクストラのアルゴリズムを調べます。パスを追跡するために、選択した物理エンジンを完全に使用します。私がそれを設定する方法は、ユニットクラスが移動するそれぞれの場所が2Dオフセットを介してパスサブクラスに設定されることです。はい、それらは3Dではなく2Dです。

3Dの説明: 各ユニットには、地形およびワールドオブジェクトとの衝突専用に設定されたメインコライダーが1つしかありません。カプセル形状で、プログラム的に言えば半径と高さがあります。モデルの中心に構築されており、モデルの前面と上部を超えて拡張する必要があります。しかし、常に地面からどれだけ離れているかについての表面オフセットと、一度にわずかに跳ね上がる前にどれだけ滑らせることができるかというフロートもあります。これは、地形の衝突の問題に対してなんらかの修正を適用しているようですが、理由があります。

とにかく、このカプセルオブジェクトに力を加えて、常に地面の上でホバリングし続ける必要があります。それはそれがそれ以上高くなることができないと言うことではなく、単にそれが低くなることができないということではありません。ホバリングする必要がある理由は(私の場合)、剛体とラグドール物理エンジンでは、ユニットの脚が手続き的にアニメーション化されるためです。したがって、カプセルに単純な力を加えることで、私のエンティティの脚は自分自身で再配置されます。また、個別の重力アプリケーションもあります!これにより、キャラクターが傾斜している場合、片方の足がもう片方の足よりも低い高度になります。

これは、まさにその方法です。あなたがそれを求めていることから判断すると。いくつかの機能を省略したい場合は、特にRTSまたはFPSであり、ユニットフィートが表示されたりケアされたりしない場合は特に問題ありません。しかし、一般的に、ユニットには、キャラクターの動きとほぼ排他的に機能する1つのMAINコリジョンオブジェクトが必要です。

具体的には、2D: エンジンがユニットを動かすために動かすための主要なポイント、または何らかの基準が必要です。各ユニットに、移動する必要がある場所がいくつかあるパスサブクラスを指定し、レベルコードで指定することができます(たとえば、location1(x、y)location2(x、y)など)。 「作業しているゲームの種類がわからない)は、おそらくレベル内の場所を指定し、各ユニットがレベルで指定された順序でそれらを処理し、各場所に到達した後、希望の場所に置き換えます次のものが必要です。

すべてのユニットが同じ場所に行く必要はないことを意味するので、各ユニットの最初の場所に場所のリストを持っているなど、それを修正できる方法はたくさんあります。ただし、同じ方法で、レベルコードでもこれを行うことができます(unit1.location1(x、y)unit1.location2(x、y)grunt.l1(x、y)knight.loc3(x、y)なんでも)

ほんの少しのアイデア!3Dバージョンは、関連性がはるかに低いものの、読むことをお勧めします。

編集:私はこれを読む可能性のある人に両方を提供することにしました(そうです)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.