複数の Database を使用する

複数の Database を使用するとき

次のいずれかの特徴を持つ、複数の異なるキャラクタのタイプがある場合にのみ、複数の Database を使用する必要があります。

幅や高さなどの物理的プロポーションが大きく異なる。このような物理的プロポーションは静的 NavData の生成の際に使用され、地形のどのエリアにキャラクタが立つことができるかを決定します。たとえば、狭い廊下または天井の低い部屋は人間のキャラクタは歩ける地形になりますが、巨人のキャラクタは歩くことができません。
移動能力が大幅に異なる。移動能力は静的 NavData の生成の際に使用され、キャラクタがある位置から別の位置に移動できるかどうかを決定します。たとえば、生成プロセスでは最大勾配角度(GenerationParameters::m_slopeMax 値によって設定)を考慮して、キャラクタが通常の歩行の動きでどの程度までの急勾配を移動できるかを決定します。たとえば、切り立った山腹では、巨大蜘蛛や山羊なら難なく横移動できるのに人間にはそれが不可能な場合があります。

このように、2 つのタイプのキャラクタが移動できる地形のエリアに違いがあることは、2 つの NavData のセットを使用するのに十分な違いとなるため、実行時にゲーム内で 2 つの Database を使用して異なる NavData のセットを管理することが推奨されます。

Database を共有するタイミング

Gameware Navigation を使用する際は通常、地形用に生成する静的 NavData が最もランタイムメモリを消費します。そのため、不要な重複を回避するために、可能なとき、つまりキャラクタ間の違いが小さく実行時に顕著に奇妙な動作が発生しないときには、同じ NavData をキャラクタが共有するようにする場合があります。

1 つの Database を複数の異なるキャラクタのタイプで共有する場合は、最も大きなキャラクタの半径と高さを使用してデータを生成する方が安全です。これは次の人間と巨人のケースを考えるとすぐに分かります。

人間の寸法を使用してデータを生成すると、NavMesh の境界は静的ジオメトリからほぼ人間の半径分離れた距離にできます。そのため実行時には、巨人は自身の半径よりも静的ジオメトリに近い場所を通過するパスをプランする場合があり、衝突が発生することがあります。
巨人の寸法を使用してデータを生成する場合は、NavMesh の境界は静的ジオメトリからほぼ巨人の半径分離れた距離にできるため、両方のキャラクタにとってパスファインディングおよびパスフォローイングを使用する際に安全です。ただし、この場合は小さなキャラクタが、上に示す狭い通路や小さな隠れ場所など、通常は移動できるような地形の一部のエリアにアクセスできなくなることがあります。

このような場合は、NavData を共有してランタイムメモリを節約することと、各キャラクタの NavData をキャラクタの正確な寸法に合わせてパスファインディングおよびパスフォローイングのリアルさを向上することとの間にトレードオフの関係があります。最終的にはゲームでどちらを優先するかで決定してください。

複数の Database を設定する

1 つの World に複数の Database を設定することは、すべての工程を複数回繰り返す必要があることを除けば、概念的には 1 つの Database を設定することと同じです。

レベルにそれぞれが独自の設定パラメータを持つ複数の NavData のセットを生成します。
World を作成するときに、キャラクタのタイプごとに 1 つの Database を作成します。
ゲームに NavData のセクタをロードする必要があるたびに、キャラクタのタイプごとに個別の NavData オブジェクトを作成します。
キャラクタのタイプのデータを保持する Database にそれぞれの NavData オブジェクトを追加します。
注:最適なパフォーマンスのために、すべての非同期 NavData 追加要求および削除要求を同じフレームにグループ化するようにします。

実際に異なる唯一の点は、アセットのパイプラインにチャレンジを追加して、各キャラクタのタイプの NavData を適切な Database に追加したことを確認することです。

NavData の互換性

Database には、データセットの一貫性を保証し、別のキャラクタに対して生成された NavData をロードできないようにするためのメカニズムが提供されています。Database がNavData をロードした後は、既存の NavData と同じ設定パラメータを持つ追加の NavData が生成されない限り、追加の NavData をロードしません。

Database に NavData オブジェクトを追加する前に、Database::IsCompatibleWith() を呼び出して NavData オブジェクトを渡すことで既に存在するデータと追加するデータが一致するかどうかをテストできます。このメソッドが false を返した場合には、その Database へのこの NavData の追加に失敗します。

データベースのバインド

デフォルトでは、Bot や障害などの新しい WorldElement をワールドに追加すると常に、そのオブジェクトはワールド内のすべてのデータベースで空間化されます。これにより新しいオブジェクトはすべてのデータベースで同じ方法で考慮されるようになります。例:

すべてのデータベース内のすべての Bot で使用されるダイナミック回避コンピュータが、すべての新しい Bot および動的な障害を考慮します。
NavMesh を動的に修正するために設定される新しい TagVolume および障害により、すべてのデータベース内の NavMesh が修正されます。
すべてのデータベースに対する空間クエリがこれらのオブジェクトをすべて取得します。たとえば、インタレストポイントを収集するためにSpatializedPointCollectorInAABBQuery を実行すると、どのデータベースに対してクエリを実行したかにかかわらず、ワールドに追加されたすべてのインタレストポイントが取得されます。

ただし、場合によっては、このデフォルトの動作を使用したくなく、代わりに、新しいオブジェクトに適用されるデータベースを制限したい場合もあるかもしれません。例:

巨人キャラクタのダイナミック回避で人間を無視させたい。
新しい TagVolume が限られた Database のセットでのみ地形にタグを付けるようにしたい。たとえば、浸水したエリアを表す TagVolume を人間にのみ適用し、巨人には適用しない場合があります。
Database に応じて異なる結果がクエリから得られるようにしたい。たとえば、巨人キャラクタに関連するインタレストポイントのセットが人間に関連するインタレストポイントのセットと異なる場合があります。

Bot、BoxObstacle、CylinderObstacle、TagVolume、または PointOfInterest を作成するたびに、どの Database が新しいオブジェクトを考慮するかを指定することができます。

これらの種類のオブジェクトの初期化に使用する設定オブジェクトには m_databaseBinding メンバがあり、DatabaseBinding クラスのインスタンスを保持します。オブジェクトを初期化する前に、新しい DatabaseBinding を作成し、選択した Database に対するポインタを設定し、m_databaseBinding メンバを設定して DatabaseBinding を指定することができます。例:

Kaim::BotInitConfig botInitConfig;
...
m_databaseBinding = *KY_NEW Kaim::DatabaseBinding;
m_databaseBinding->AddDataBase(world->GetDatabase(0));
m_databaseBinding->AddDataBase(world->GetDatabase(2));
botInitConfig.m_databaseBinding = m_databaseBinding;

m_navBot->Init(botInitConfig);