AIやプレーヤーと比較して、マルチプレーヤーサーバーにキャッシュする必要があるデータは何ですか？

任意の数のプレイヤーと任意の数の敵がいる完全にネットワーク駆動の仮想の場所で、スムーズなAIシミュレーションを最適化するには、どのデータをサーバーのメモリにキャッシュする必要がありますか？

説明しようとすると、プレーヤーAがプレーヤーBからE、および敵AからGを見たとします。これらの各プレーヤーはプレーヤーAを見ますが、必ずしもお互いではありません。同じことが敵にも当てはまります。この質問をトップダウンの観点から考えてください。

多くの場合、たとえば、プレーヤーが銃を撃ったとき、サーバーは音を放射状の「信号」として処理します。この信号は、他のすべてのエンティティが到達し、「聞いて」反応します。

各AIエージェントの予算が非常に少ない場合、関係のないプレーヤーや敵を多く含む可能性のあるエリア全体でこれらの検索を常に行うことは問題のようです。

すべてのエンティティは、認識範囲から出入りするものをすべてキャッシュする必要がありますか？そのようなキャッシュでメモリをあふれさせることなく、近くのエンティティをトレースする優れた方法はありますか？

前の問題がうまく機能すると仮定した後に発生する可能性のある他のAI関連の問題はどうですか？何百もの敵、群れがある環境について話している。

これには複数の方法がありますが、それらは、相互作用が大量に発生する場所や人口が非常に多い場所に依存します。

残念ながら、シミュレーションの精度を維持したい場合は、すべてのアクターによって生成されたほとんどのイベントを処理し、通知が必要なすべて/ほとんどのアクターを見つける必要があります。

安いエリアの衝突

認識領域の問題に関しては、単純な衝突検出を使用して解決できます。

2Dの世界では、円での衝突検出は「安価」です。たとえば、点が円の中にあるかどうかを検出する操作は、2つの減算、2つの乗算、および加算のみを必要とします。面積の平方半径を保存して直接平方距離と比較できるため、平方根を計算する必要はありません。

3Dワールドで2Dサークルを使用する場合、基本的には円柱として機能します。高さがあまり重要でない場合は、エリアを作成する便利な方法になります。

イベント指向の半径

イベント（消防、動きなど）の量が少ない場合は、各イベントの影響を受ける各アクターを検出してみることができます。あなたのイベントはエリア（彼らが聞くことができる場所）を生成します。

これは実装が最も簡単な方法であり、気づきの範囲外の俳優から発射された弾丸/発射物の影響を拾うことができるため、最も柔軟性があります。

一方、イベントの量が増えると、エリアスキャンをトリガーするイベントの数を減らすか、イベントごとにスキャンされるアクターの数を減らす必要があります。

->すべてのイベントが一緒に登録されて一括で処理される小さな（イベント）ゾーンを作成することもできます（つまり、2つの弾丸の影響と1つのゾーンで発生する足跡は1つのスキャンのみを使用し、影響を受けるすべてのエンティティに送信されます）。<-

アクター向けのエリア

「認識領域」の原則を使用できます。IEアクターが別のアクターのアウェアネスエリア（サークル）と衝突する場合、衝突するアクターを潜在的に相互作用しているアクターのリストに追加するだけです。エンジンの構築方法に応じて、リスト内のアクターから発生するサウンドメッセージやその他のイベントを登録できます。

視覚的な接触を確認するために、登録済みの俳優のリストでのみ視覚スキャンを行うこともできます。

ティックごとに認識領域の変化を確認する必要はありません。たとえば、5から30ティックごとにそれを時々行うことができます。

リストが増え始めたら、それらを最大サイズに制限できます。ただし、リストに追加/交換するアクターを優先する必要があります。

混合アプローチ

両方のアプローチを組み合わせることができます。足跡、エンジンノーズなどのイベントのアウェアネスエリアにアクターを登録できます。また、その他のイベント（発射体の衝撃、爆発など）は、その重要度に基づいてスキャンをトリガーできます。弾丸の衝撃よりも手榴弾の爆発が聞こえる可能性がはるかに高いため、手榴弾の爆発は弾丸の衝撃よりも広範囲のスキャンをトリガーする必要があります。

最初にイベント半径の実装を開始することをお勧めします。これが機能し、この方法の精度を増減できるようになったら、アクター認識領域の実装を開始できます。このようにして、いくつかのイベントを2番目のシステムに移動し始めることができます。

コンテキストプール

すべてのアクターにすべてのイベントを通知する必要があるわけではありません。たとえば、対空砲塔は、弾丸の衝撃とその周囲の足跡について通知を受ける必要はありません。一部のユニットでは、地上ユニットの存在を無視することもできます。

このような特殊なケースが多数見つかった場合は、さまざまな認識領域のプールを作成できます。俳優は、複数のプールでアウェアネスエリアをアクティブにすることができます。たとえば、地上ユニットは地上ユニットにのみ反応し、一部のミサイルやレーザー装備ユニットは航空ユニットにも反応するようにすることができます。爆発以外の地上への影響について航空機に通知する必要はありません...

もちろん、プールに対して複数の「リスト」を作成する必要はありません。単純にビットマスクを使用して、各俳優/エリアに適切なマスクを設定できます。このようにして、単純に、または距離をチェックする前にフィルタリングできます。

集計

各アウェアネスエリアのリストが大きくなり、メモリが不足している場合は、敵のグループ（チーム、チーム、小隊、群れ、群れ...）のアウェアネスエリアを、それらが互いに近接している限り、集約できます。このようにして、チーム全体がイベントまたは他のアクター/グループがその認識エリアに入るのを登録できます。

基本的にグループエンティティは、グループのすべてのメンバーがプールから削除されている間、すべてのスキャンの代理/プロキシになります。

この原則は、車両内のすべてのユニットにも適用できます。

近接アクティベーション

サーバーにボットが実際に過剰に配置されている場合（そして、ボットをすべて存続させる必要がある場合）、特別な「各プレーヤーの周囲のアクティブ化領域」内のボットに対してのみ、認識/ AIをアクティブ化できます。このようにして、1つ以上のアクティブ化領域内のボット（またはグループ）は、自身とその認識領域を（衝突プール内で）アクティブ化し続けます。それ以外の場合、その認識エリアはアクティブエリアのプールから削除されます。

これらの「アクティブ化領域」が「認識領域」をスキャンする頻度は、プレーヤーの速度によって異なります。より高速で移動するプレイヤーは、ゾーンをキャンプしているプレイヤーよりも多くのアクティベーションをトリガーします（ローミングボットをアクティブにし、そのエリアを離れるボットを非アクティブにするために必要です）。

また、プレイヤーが乗り物に乗っている場合はプレイヤーのアクティベーションエリアを無効にし、乗り物がいない場合はアクティベーションエリアを車両に割り当てることができます。このようにして、同じ車両で移動する10人のプレイヤーが10個のアクティベーションエリアを持つ必要はありません。

委任

詐欺師や他のトラブルメーカーを恐れない場合は、イベント検出の一部をクライアントアプリケーションに委任できます。

サーバーは定期的に近くのアクター（ボットとプレイヤー）のリストを送信でき、クライアントアプリによって通知されます。クライアントアプリケーションは、プレーヤーによって生成されたすべてのイベントのスキャンとイベント検出を行う必要があります。たとえば、ショット、弾丸の衝撃、足音について通知する俳優のリストを送信できます。

これはオプションです。作成しているゲームの種類によっては有効になる場合があります。これは理論上の考え方であり、委任されたクライアント（ボットサーバーまたはセキュリティで保護されたクライアント）を完全に制御できるようになるまで、これを行うことはお勧めしません。

これがお役に立てば幸いです。