ゲームのボリュームの経路計画

ゲームのボリュームをどのようにパス計画しますか？

たとえば、トンネルと洞窟がある1 kmの立方体。また、地形は破壊可能です。

ウォーキングモードとフライングモードがあります。

フェーズに分けます。オープンスペースのボリュームを作成します。動的破壊を考慮に入れたパスを見つけます。

パフォーマンスは大きな懸念事項であり、短時間で使用されるパスを見つける機能です。

具体例：地中の何かを効率的に掘る。

地面は破壊可能です。「洞窟」はエリアを掘るのが簡単です。鉱業は飛行のようなものです。センサーで見る必要があります。データセットは巨大です。ターゲットへの輸送経路を構築する必要があります。マルチエージェントの場合があります。

動的パスファインディングを合理的に実行するには、D *（動的A *）のように、これに特に適したアルゴリズムが必要です。

これ以外にも、階層パスファインディングを実行する方法を見つけることができる場合があります。このようにして、低解像度ではより単純なパス、高解像度ではより複雑なサブパスが得られます。高解像度のパスサブグラフを低解像度のマスターグラフに置き換えることで、希望する解像度にパスを作成できます。

別のサブリージョンに入るまで最小限のパスファインディングを実行し、そのリージョンのサブディビジョンレベルでより詳細なパスファインディングを実行できるため、低解像度のパスファインディングは明らかに優れています。

3Dスペースのトンネリングを実行するために使用される実際のアルゴリズムに関して、これで直面する最大の潜在的な問題は、別のパッセージ（グラフセグメント）を渡らないと抜け出せない3Dの「行き止まり」エリアに入ることです。ここで、平面グラフの埋め込みに関する私の最近の独白を参照してください。

破壊可能な地形が巨大なマルチレベル環境への大きな変化を意味する場合、これは特にウォーキングユニットにとっては非常に困難です。飛行ユニットと歩行ユニットを最初から分割して、別々のグラフにすることをお勧めします。

ウォーキングユニットの決定的な解決策を知っているとは言えません。エージェントの量、潜在的な地形の変化、およびキューブノードの解像度に応じて、D *を使用する場合と使用しない場合があります。本質的に、D *はブルートフォースA *です。Nickが示唆したように、一歩先にブルートフォースを強制すると、多くの「行き止まり」が生じる可能性があります。パス全体がないと、次のノードが正しいかどうかをすぐに判断できないためです。また、パスキャッシュとその部分的な無効化について考える必要があるため、エージェントごとに絶え間なく総当たりする必要はありません。全体として、それは簡単なことではなく、CPUが非常に重くなる可能性があります。

代わりにA *を使用すると、最も簡単なケースは、地形の破壊を最小限に制限し、「粗い」A *のような階層的なパスファインディングと、何らかの形のローカル回避を回避することです。これはオプションではないと思います。そのため、キューブの地面と壁をナビゲーションメッシュに変換してから、部分ごとに変更してみてください。もちろんNavmeshの計算は高速ではありませんが、地形の変化時に前述のメッシュの完全な再計算を回避するために、さまざまな最適化の余地があります。一般的な考え方は、ローカルメッシュの更新を実行することです。これにより、地形破壊が発生したときに、ナビゲーションメッシュの影響を受ける領域のみが変更されます。これは、ボロノイ図の構築の適応を使用して行うことができますが、「解決された領域」ではありません。navmeshの再計算を高速化する必要があるため、これも簡単ではありません。

航空ユニットのグラフははるかに単純です。基本的には、すべての「空域」を見つけてグラフに変換する必要があります。洞窟は動的であるため、最も明白な選択は、このグラフを立方体の八分木に基づくことです。ノードを計算するための基礎としてoctreeリーフセントロイド（リーフキューブの中央のポイント）を使用し、明らかに無効な位置にあるすべてのセントロイドをフィルターで除外します。結果の重心をチェックして、近所の人からアクセスできないものをすべて削除します。これは非常に高速になるため、主要な懸念事項は地上パスファインディング内に留まります。

ボクセルゲームSDKの一部として、3Dグリッドでのパスファインディングのオープンソース実装があります。これは、Minecraftスタイルの環境とボクセル地形を正確に対象としたA *アルゴリズムの実装です。

他の人が提案したような動的アルゴリズムではないので、私はあなたを助けることはできません。それはあなたの世界が本当にどれだけダイナミックであるかによると思います。現在は数ボクセルのパスを見つけるのに数秒かかるため、いくつかのパフォーマンスの改善を使用することもできますが、ダウンサンプリングされたボリュームのバージョンで実行できる場合があります（ダウンサンプリング中に有効であることに注意してください）パスが作成/失われる場合があります）。

http://www.youtube.com/watch?v=C8y0OzL0zpM（これは私のゲームではありません）で動作を確認し、http：//www.thermite3d.orgからソースを取得できます。

あなたが世界がすでに個別のブロックから構築されているなら、ナビゲーションの基礎としてそれらを使用することは理にかなっています。

パスファインダーは簡単で高速なパスファインダーです。世界の変化をたどり、それに対応する道は、本当の美しさです。

考えられる解決策を絞り込むのに役立つ質問がいくつかあります。-シミュレーションしようとしているNPCの種類は何ですか。-どのくらいの経路を検索していますか？-どのくらい正確な経路が必要ですか？

パスが短く、「ステアリングより優れている」品質で問題がない場合は、ローカルグリッド[1]が適しています。彼らは超高速です、あなたはそれを2Dと3Dの両方で機能させることができます。ボリュームデータから直接ローカルグリッドデータを取得できるため、ナビゲーショングラフは動的な変更と簡単に同期し続ける必要があります。

ローカルグリッドの問題は、ローカルグリッドよりも大きいローカルミニマがある場合、エージェントがスタックする可能性があることです。極小値を検出した場所にパンくずを追加するなどのトリックを実行して、検索時にそれらの場所を避けようとすることが可能です。

長いパスが必要な場合は、ある種の階層スキームをお勧めします。HPA *は、グリッドワールド内にスパースノードを作成する方法を提供します。ローカルグリッドは、高レベルのノード間のパス検索を解決できます。世界に変更を加えるときは、粗いノードもローカルに変更する必要があります。ノードを使用して、ゲームワールドの動的な変化を検出し、パスを再計画することもできます。

動的な世界がある場合、パスファインディングは統計になります。エージェントがその方法を見つけた場合、それ以上の保証はありません。世界の変化を追跡することは非常に困難であり、何かがうまくいかない場合の再計画は停滞しています。

エスキルはLove MMOでこのアイデアに乗り、彼の経路ファインダーはユーティリティ関数を使用したランダムサンプリングです（彼のアクション選択もそうです:)）。それがあなたのゲームスタイルに合うなら、私は最初にそれをすることを勧めます。

[1] http://digestingduck.blogspot.com/2010/03/local-navigation-grids.html

ナビゲーションメッシュを採用したい場合、またはプラットフォームだけでなく垂直方向の世界が特に騒々しい場合、または飛行モードがジャンプやホバリングだけではない場合は、ナビゲーションボリュームを使用できます。

迂回は、ナビゲーションメッシュをライブで更新できるパス検索用のライブラリです。私はそれを使用したことがありません、それがあなたの規模でどのように機能するかわかりません。階層システムは良い考えのようです。

あなたが自分で書くことを考えているときに良い読書は、対称性の破れの最近の研究です。よく検討する価値があります！

戦争の霧がパスファインディングの決定に影響を与えるべきかどうかを考慮しなければなりません。新しいエリアに移動するように求められた場合、ユニットは障害物に遭遇するまで直線的に移動する必要がある場合もあれば、マップの知識が十分にあるルートを作成する必要がある場合もあります。それはゲームの選択です。

楽しい読み物：パスファインディングの修正