チョークポイントで群衆に対処するための戦略

最近、ゲームエンジンをステアリング動作からインパルスベースの動きに切り替え、適切な時間ベースの衝突解決を行いました。これにより、非常に多くの問題が解決され（トンネリングが不要になりました）、シミュレーションが大幅に安定しました。しかし、安定性には新たな問題が生じています。

3つのボールは画像の下部近くで移動を開始しました。ターゲットはピンク色のボールが止まったところです。途中、赤と緑のボールが壁のチョークポイントに引っかかっています。

以前は、浮動小数点エラーとステアリング動作の一般的な不安定性を利用して、緑と赤のボールがチョークポイントを通り抜けるまで互いに揺さぶることができました。これで、適切な衝突解決により、ボールに作用する力が互いに相殺され、その結果、ボールは完全に静止したままになります。

そのような状況を解決するために一般的に使用される方法は何ですか？おそらく、ある種の優先度キューシステムが機能しますが、2つ以上のオブジェクト間の優先度を決定する必要があると、システムが複雑になることがわかります。

collision-resolution

— 小石
ソース

また、群集管理のステアリングにも失望しています。質問に「インパルスベースの動き」に関するリンクをいくつか追加していただけませんか。

— Kromster、2016年

衝動はただの力*時間です。私が言おうとしていたのは、離散的ではなく連続的な衝突検出を使用する物理ベースのモデルに移行したということです。ステアリング動作は、ニュートンの運動の法則のようなものを実際には尊重しません。それらは、物理シミュレーションではなく、鳥の群れを模倣するように設計されました。私は実際に運動のためのgamedevリンクを持っていません、それは本当にただ高校の物理学です。ただし、Christer Ericsonの著書であるReal Time Collision Detectionは、継続的な衝突検出のゲーム開発者です。

— フィブルズ2016年

回答:

各移動可能なオブジェクトに一意のインデックスを割り当て、インデックスの高いオブジェクトがインデックスの低いエージェントを移動できないようにします。これにより、「古い」オブジェクトは「新しい」オブジェクトをナッジできますが、その逆はできず、キューイングよりオーバーヘッドが少なくなります。基本的に、インデックスは移動の優先順位として機能します。

— ピカレク
ソース

私はこれを実装し、そのユニットで動かなくなることはなくなりましたが、常にきれいであるとは限りません。いくつかの注意点：インデックスを使用して、同じ質量の移動オブジェクトの優先順位を決定するだけです。大きなオブジェクトは、小さなオブジェクトを邪魔にならないように押し出すべきです。インデックスを使用して、同じチームのオブジェクトの優先順位を決定します。敵オブジェクトは、最初にスポーンされたために優先順位が高いという理由だけで、プレーヤーオブジェクトに対して不動の壁として機能することはできません。

— Fibbles

私は質量やチームを考慮していませんでした。あなたの微調整は私の答えにパッチを当てる論理的な方法のようです。

— ピカレク2016年

経路探索に時間を追加する

ここにそのタイムキューブについて述べた論文があります：http : //www0.cs.ucl.ac.uk/staff/D.Silver/web/Applications_files/coop-path-AIWisdom.pdf

そして、これがObjective-Cの実装です：http : //allseeing-i.com/ASIPathFinder

— ラッカレイジ
ソース

これについては以前に読んで実装しました。複数のスレッドがあっても、私の状況ではあまり役に立ちません。RTSゲームでは、1辺が500マスを超える数百の移動単位とマップグリッドが存在する可能性があります。各ユニットの時間ベースのパスを計算するためのオーバーヘッドが高すぎます。付け加えると、私はラッカレッジの答えが間違っていると言っているのではなく、それは非常にきちんとしたアルゴリズムです。それが役に立つ状況は、その複雑さによって制限されているというだけです。

— フィブルズ

これを完全に理解して実装するのではなく、毎ターン経路探索アルゴリズム全体を再実行しますが、最終的には必要になるかもしれません

— Rakka Rage

実は直さないと思います。（私が推測するかもしれませんが）矢印がグリッドの任意の位置で球に適用された力ベクトルを示している場合（おそらく「双線形」または同様に、または何らかの理由で0/1であるよりも「アナログ」で補間されます）、動作は物理的に正しく、適切に動作するソリューションがあることを祝福する必要があります。

2つの球体は、そこに座ってお互いを憎むので、バランスが取れています。どうやら、彼らが少し右に移動する場合、右への「力の矢印」は右側の球に少し影響し（左側の球ではその逆、少し少ない）、したがってバランスに戻ります。これはあるべき姿です。

Imho、修正する必要があるのは、壁、球のサイズ、またはビルドストーン自体の間の何かです。あなたは不可能を作り出しました、そしてその状況での正しい振る舞いはそれに応じてデッドロックです（言葉を誤用して申し訳ありませんが、とにかくそれらを手に入れたいと思います:-)）。

おそらく代わりに、最も近い左/右の力の矢印を無効にするか、対称的ではなくバランスを取ることを奨励しない他の方法でそれらを配置しますか？

私はそれを人為的に修正するのは悪い修正だと思います...早すぎる毛むくじゃらになるでしょう。

— 嵐の風
ソース

これは質問の答えにはなりません。あなたの動機を理解しましたが、結局のところ、問題はどのように状況に対処するかです。私たちはゲームプレイの意図を知らないので、これが問題であるかどうかの判断はフィブルズ次第です。壁を変更すると、チョークポイントの目的が変わる場合があります。質問は解決できる有効な問題です。

— Felsir、

私の答えは基本的に：シナリオで力を（再）配置するか、何か他のものを再配置しますが、物理ソルバーをスクランブルしません（「Imho、修正する必要があるのは、壁、球のサイズ、またはビルドストーン間の何かです。自分自身。「）。問題は、「そのような状況を解決するために一般的にどのような方法が使用されているか」です。私のAは非常に「一般的に使用されている方法」であり、問題の解決策であると思います。たとえば、オンラインミニゴルフゲーム（Qがよく行うことを思い出させます）は、環境がそれを起こすように要求している場合、ボールをチョークします。不安定な物理学は悪い方法です、イモ。

— Stormwind 2016年

物理ソルバーはそのままでよいことに同意します。質問は、球体がターゲットを探すべきだと述べています。基本的に、エージェントの動作を変更する方法です（したがって、物理やレベルレイアウトは変更しません）。レベルのレイアウトを変更すると、この問題が解決する場合がありますが、別のレイアウトに切り替わる必要があります。したがって、この問題は具体的にデッドロックを回避することであるため、この質問は、提供するミニゴルフの例とは異なります。

— Felsir 2016年

あなたが見るように、私は答えで力を再配置することも提案します。その後少し残っているようです:-)。

— Stormwind 2016年

壁を再配置したり、球のサイズを変更したりすることは、他のケースではあるかもしれませんが、私の場合は実行できません。スクリーンショットは、RTSエンジンのデバッグモードのものです。多くの異なるユニットサイズがあり、壁はプレイヤーが自由に配置できます。表示される矢印は、私の高速フローフィールドアルゴリズムによって生成されます。これらは、可動ユニットの移動方向に影響を与えるために使用される正規化されたベクトルです。グループ内のすべての可動ユニットが同じフローフィールドを共有するため、ベクトルの長さを変更することはできません。

— フィブルズ