Стратегии борьбы с толпой в местах удушья

Я недавно переключил свой игровой движок с рулевого поведения на импульсное движение с надлежащим временным разрешением столкновений. Это решило очень много проблем (больше не туннелирование, ура) и сделало симуляцию намного более стабильной. Однако со стабильностью возникла новая проблема.

Три шара начали свое путешествие в нижней части изображения, их цель была там, где остановился розовый шар. По пути красные и зеленые шарики застряли в узкой точке в стене.

Раньше я мог полагаться на ошибки с плавающей запятой и общую нестабильность поведения руля, чтобы зелёные и красные шары давили друг на друга, пока им не удалось пройти через точку дросселирования. Теперь при правильном разрешении столкновения силы, действующие на шары, взаимно компенсируют друг друга, в результате чего шары остаются совершенно неподвижными.

Какие методы обычно используются для разрешения таких ситуаций? Возможно, какая-то система очередей с приоритетом будет работать, хотя я вижу, что она становится сложной, когда мне нужно выбрать приоритет между более чем двумя объектами.

collision-resolution Fibbles
источник

Я также разочарован управлением рулевой толпой. Не могли бы вы добавить несколько ссылок о "импульсном движении" в вопросе?

Кромстер

Импульс - это просто сила * время. Я пытался сказать, что я перешел к физической модели, использующей непрерывное, а не дискретное обнаружение столкновений. Поведение рулевого управления на самом деле не уважает такие вещи, как законы движения Ньютона, оно было разработано, чтобы имитировать стаи птиц, а не имитировать физику. У меня на самом деле нет ссылок Gamedev для движения, это просто физика в старшей школе. Тем не менее, книга Кристера Эриксона «Обнаружение столкновений в реальном времени» в значительной степени является игрой для непрерывного обнаружения столкновений.

Fibbles

Ответы:

Присвойте каждому подвижному объекту уникальный индекс и запретите объекту с более высоким индексом перемещать агента с более низким индексом. Это позволит «старым» объектам подталкивать «более новые» объекты, но не наоборот, и это требует меньше затрат, чем организация очередей. По сути, индекс действует как приоритет движения.

Pikalek
источник

Я реализовал это, и это работает в том, что юниты больше не застревают, хотя я должен сказать, что это не всегда красиво. Некоторые предостережения: используйте индекс только для определения приоритета для движущихся объектов одинаковой массы, крупные объекты должны естественным образом отталкивать маленькие объекты. Используйте индекс только для определения приоритета для объектов в одной команде. Вражеский объект не должен действовать как неподвижная стена для объекта игрока просто потому, что он был создан первым и, следовательно, имеет больший приоритет.

Fibbles

Я не считал массу или команду; ваши настройки кажутся логичным способом исправления моего ответа.

Пикалек

добавить время к поиску пути

вот статья, в которой говорится о кубе времени: http://www0.cs.ucl.ac.uk/staff/D.Silver/web/Applications_files/coop-path-AIWisdom.pdf

и вот реализация Objective-C: http://allseeing-i.com/ASIPathFinder

Rakka Rage
источник

Я читал и реализовал это раньше. Даже с несколькими потоками это не очень полезно в моей ситуации. В игре RTS могут быть сотни движущихся юнитов и сеток, которые больше чем 500 квадратов в сторону. Затраты на вычисление путей на основе времени для каждой единицы слишком велики. Просто добавлю, я не говорю, что ответ rakkarage неправильный, это очень аккуратный алгоритм. Я просто говорю, что ситуации, в которых это полезно, ограничены его сложностью.

Fibbles

Я просто перезапускаю весь свой алгоритм поиска пути каждый ход, вместо того, чтобы полностью понимать и реализовывать это, но я полагаю, что мне, возможно, придется в конечном итоге

Rakka Rage

На самом деле, я не думаю, что вы должны это исправить. Если (я могу предположить) стрелки указывают на векторы силы, приложенные к любой сфере, в любом месте сетки (возможно, интерполированные «билинейно» или аналогично, или как-то более «аналогично», чем просто 0/1), то тогда поведение является физически правильным, и вы должны поздравить себя с хорошим решением.

Эти две сферы находятся в хорошем равновесии, поскольку они сидят там и ненавидят друг друга. По-видимому, если они перемещаются немного вправо, «стрелка силы» вправо воздействует на сферу правой стороны немного больше (и наоборот на сферу левой стороны; немного меньше), и поэтому они возвращаются к равновесию. Так и должно быть.

Имхо, то, что должно быть исправлено - это стена, или размеры сферы, или что-то еще среди самих строительных камней. Вы создали невозможное, и правильное поведение в этой ситуации, соответственно, зашло в тупик (извините за неправильное использование слов, надеюсь, вы все равно их получите :-)).

Возможно, вместо этого отключите ближайшие стрелки влево / вправо или расположите их другим способом, который не является симметричным и не способствует сбалансированности ?

Я думаю, что это было бы плохим решением, искусственно исправить это ... стало бы слишком рано.

Штормград
источник

Это не отвечает на вопрос. Я понимаю вашу мотивацию, но в конечном итоге вопрос заключается в том, как справиться с ситуацией. Мы не знаем намерений геймплея, поэтому судить, является ли это проблемой или нет, зависит от Fibbles. Смена стены может изменить назначение дроссельной заслонки. Вопрос является действительной проблемой, которая может быть решена.

Felsir

Мой ответ в основном: (пере) расположите силы или переставьте что-то еще в сценарии, но не разбирайте решатель физики (« Имхо, что должно быть исправлено, так это стена, или размеры сферы, или что-то еще среди строительных камней»). сами. "). Вопрос в том, какие методы обычно используются для разрешения таких ситуаций? Я думаю, что мой A - это «широко используемый метод» и решение проблемы. Например, онлайн-игры в мини-гольф (о которых Q очень напоминает) действительно душат шары, если окружающая среда требует этого. Неустойчивая физика - плохой путь, имо.

Штормград

Я согласен, что решатель физики должен оставаться в такте. Вопрос состоит в том, что сферы должны искать цель, в основном, как изменить поведение агентов (таким образом, не физику или структуру уровней). Изменение макета уровня может решить эту проблему, но это может привести к другому макету. Таким образом, вопрос отличается от приведенного вами примера мини-гольфа, поскольку в данном случае вопрос заключается в том, чтобы конкретно избежать тупика.

Felsir

Как видите, я также предлагаю перераспределить силы в ответе. Кажется, после этого мало что осталось :-).

Штормград

Перестановка стен или изменение размеров сферы не жизнеспособны в моем случае, хотя это может быть в других. Скриншот взят из режима отладки движка RTS. Есть много разных размеров юнитов, и стены могут быть размещены по желанию игрока. Стрелки, которые вы видите, генерируются моим алгоритмом Fast Flow Fields. Это нормализованные векторы, которые используются для влияния на направление движения подвижных узлов. Невозможно изменить длину векторов, поскольку все подвижные элементы в группе совместно используют одно и то же поле потока.

Fibbles