パス ファインディングとパス フォローイング

ステージ 1. 最初のパスを取得する

パス フォローイング システムの最初のステップでは、開始地点(通常は Bot の現在の位置)を必要なターゲットに接続する最初のパスを NavData で計算します。この最初のパスは、Path クラスのインスタンス、つまりエッジで接続されたノードで構成されている静的な固定構造によって表されます。

たとえば、下のイメージでは、黄色の Bot は屋根の上の目的地までのパスを計画しています。このパスは地面に沿って NavMesh を通過し、地面から屋根に繋がる NavGraph エッジに追従して、NavGraph エッジの端から目的地の屋根の上にある最後のセグメントに到達します。

デフォルトでは、各 Bot は Path を計算できるクエリーへアクセスできます。NavigationProfile を呼び出したオブジェクトから取得します。新しいパスを計算するときは、Bot API を使用してパスの計算を要求します。すると、Bot が次の更新時にクエリを非同期的に実行します。

Bot にパスを計算させるには、いくつかの異なる方法があります。また、Bot に事前計算したパスを提供することもできます。詳細は、「静的パスを取得する」を参照してください。

ステージ 2. LivePath を作成する

Bot が正常に Path を計算した場合、または独自の Path を挿入した場合、パス フォローイング システムが新しいパスを分析し、それを基に LivePath という新しい構造体を作成します。LivePath は動的な構造体であり、パスに関するコンテキスト情報を提供するいくつかの重要項目と、Bot のパス フォローイング プロセスの状態を保持しています。そしてこれにはパスに関する情報をいつでも調べることができる PathEvents のリストも含まれています。これらの PathEvents を使用して、進行方向にある様々な地形タイプのトランジション、スマート オブジェクト、または立ち入ることができない領域などを、パスに沿ってスキャンすることができます。

たとえば、下のイメージでは、LivePath 内のトランジション イベント(パスが異なる NavTag のエリアを横断するたび、および NavGraph エッジの開始点と終了点)をフラグでマークしています。

これらの PathEvents の詳細とその操作方法については、「PathEvent を監視する」を参照してください。

ステージ 3. LivePath に追従する

フレームごとに、Bot は現在のフレームでどのような移動を行うべきかを決定するために Trajectory オブジェクトを呼び出します。Trajectory は Bot とそのパスの現在の状況を評価する役割を持ち、衝突を起こす可能性のある移動する障害物などのその他の影響を考慮します。これらの要素とキャラクタの移動をコントロールする設定パラメータのセットに基づいて、現在のフレームで実行するキャラクタの推奨速度を生成します。

デフォルトでは、Bots は Trajectory クラスのインスタンスで使用するように設定されています。この Trajectory の実装は、最終速度の計算に 2 つの異なる方法のいずれかを使用することができます。

• ShortcutTrajectory オブジェクトにより計算される、直線のショートカットに基づいた方法を使用することができます。ShortcutTrajectory は、可視状態でキャラクタの現在の位置の少し先(デフォルトでは最大 10 メートル先)にあるパス上のターゲット ポイントを選択し、そのターゲット ポイントに直線で向かう速度を生成します。ターゲット ポイントに近づくにつれて、パスに沿ってさらに進んだ、可視状態の新しい場所にターゲットを定期的に更新します。

  たとえば、下のイメージでは、Bot はコーナーに近づきつつ、LivePath に沿った最後の可視ポイントを目指し続けます。Bot がコーナーに十分に近づいて LivePath がさらに見えるようになると、Bot はターゲット ポイントをパスに沿って可能な限り遠くへ進めます。

  

  この方法により、キャラクタにはそのキャラクタの初期のパス内にある通過した急激なターンをスキップするための比較的単純で高パフォーマンスな方法が提供されます。ただし、この方法では新しいショートカットが使用できるようになったときにキャラクタが速度と向いている方向を突然変更することができるようになっています。

• SplineTrajectory オブジェクトにより計算される、チャネルとスプラインに基づいた方法を使用することができます。この方法は、チャネルに基づきます。チャネルとは、パスと同時に計算される初期パスの周囲のナビゲート可能な空間を表すものです。SplineTrajectory は近づいているチャネルの境界の設定を確認し、キャラクタの軌道をその境界内に維持するスプラインを計算します。

  たとえば、下のイメージでは、チャネルの境界がオレンジで表示されています。境界は障害物の間の狭いギャップに押し込められて接近しているのに注意してください。また、NavGraph を追従するパスのセグメントにチャネルが無いことにも注意してください。最初のチャネルは NavGraph エッジの開始地点で終了し、2 つ目のチャネルが屋根の上で開始されます。上記のショートカットの例と同様に、Bot はパスに沿って進みながら新しいスプライン(赤で表示)を定期的に計算します。

  

  この方法では、初期パスの周囲の使用可能な空間を多く使用する曲線的な軌道が生成される傾向がありますが、代償としてパス ファインディング フェーズ(チャネル データを生成するため)とパス フォローイング フェーズの両方で CPU 使用率が少し高くなります。

Bot の初期化時にどちらの軌道モードを使用するかを決定し、初期化後はいつでもオンザフライで変更できます。「パス フォローイングをカスタマイズする」を参照してください。

Trajectory が任意の指定されたフレームで現在どちらの方法を使用しているかにかかわらず、次の条件が適用されます。

• Bot が NavMesh の有効なエリアにある間、移動する障害物や他の Bot などの近くのオブジェクトとの衝突を避ける軌道を生成するために、軌道パスはダイナミック回避システムを使用することができます。回避コンピュータが移動の方向と Bot の速さのいずれか、または両方を調整する場合があります。
• Bot が NavGraph を横切る間、軌道はダイナミック回避を使用せず、NavGraph の次の頂点にまっすぐ進む速度を常に生成します。

軌道とダイナミック回避システムに関連するクラスには、各キャラクタ用に調整できるさまざまな設定パラメータが含まれています。「パス フォローイングをカスタマイズする」を参照してください。

ステージ 4. 結果を取得して適用する

各フレームでパス フォローイング システムの最終的な結果を取得するには、次の例に示すように、BotOutput にアクセスする必要があります。

m_velocity = m_navBot->GetBotOutput().m_outputVelocity();

この速度をゲームのキャラクタに適用するのは開発者の責任になります。また、アニメーションまたは物理システムによって示唆される追加コンストレイントに従います。

Gameware Navigation は、ゲームでのゲーム エンティティの移動および誘導方法を決めることはありません。キャラクタを完全にアニメーションだけで動したり、完全に物理で動かしたりすることができます。Bot が自身を自動的に移動させないのは、このためです。開発者がパス フォローイング システムによって生成された提案速度を解釈し、必要に応じて調整し、キャラクタに適用する位置と速度の実際の変更を Bot に通知します。

パス フォローイング システムは、キャラクタが常に予測する位置にあるとは想定しません。ゲーム エンティティが予測に反して移動する理由はいくつかあります。

• 離散速度移動モデルは、推奨速度に厳密に従えないことがあります。
• 物理的な衝突、回避、またはその他のゲームプレイ固有のイベントは、キャラクタをコースから押し出す場合があります。

パス フォローイング システムによって計算された提案速度と実際の位置/速度にわずかな違いがあっても、またキャラクタをコースから押し出すゲーム イベントがあっても、ほとんどの場合、Bot はパスを透過的にたどり続けることができます。

ただし、キャラクタが崖から突き落とされるなど、ゲームで大きな違いが生じる可能性がある場合は、各フレームでパスに沿ったキャラクタの進行の有効性をテストすることをお勧めします。また、パス上のキャラクタの位置がアクセス不能になり、新しい位置を特定できない場合は、目的地への新しいパスを再計算することをお勧めします。「パス フォローイングをモニタする」を参照してください。

モニタリング

キャラクタがパスをたどるようになったので、さまざまな種類のイベントに応答する必要があります。応答するイベントを監視し、イベント発生時に適切に処理するのは開発者の責任です。

詳細な説明については、「パス フォローイングをモニタする」を参照してください。