Стратегії боротьби з натовпами в точках задушення


9

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

Проблема зіткнення дверей.

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

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

Які методи зазвичай використовуються для вирішення таких ситуацій? Можливо, якась система черги черговості працювала б, хоча я можу бачити, що вона стає складною, коли мені потрібно визначити пріоритет між більш ніж двома об’єктами.


Я також розчарований в управлінні натовпом. Чи можете ви додайте до запитання кілька посилань про "рух на основі імпульсу"?
Кромстер

Імпульс - це просто сила * час. Що я намагався сказати, це те, що я перейшов до фізично заснованої моделі з використанням безперервного, а не дискретного виявлення зіткнень. Керівна поведінка насправді не поважає такі речі, як закони руху Ньютона, вони були створені для імітації зграй птахів, а не для фізичного моделювання. Я не маю жодних гамедевих зв’язків для руху, це насправді просто середня фізика. Однак книга Крістера Ерікісона в режимі реального часу зіткнення зіткнення в значній мірі - це біблія ігор для постійного виявлення зіткнень.
Fibbles

Відповіді:


3

Призначте кожному рухомому об’єкту унікальний індекс і забороніть об'єкту з більш високим індексом переміщувати агент з нижчим індексом. Це дозволить "старішим" об'єктам підсунути "новіші", але не навпаки, і менш накладні, ніж у черзі. По суті, індекс виступає як пріоритет руху.


1
Я реалізував це, і це працює в тому, що підрозділи більше не зациклюються, хоча мушу сказати, що це не завжди прекрасно. Деякі застереження: використовуйте індекс лише для визначення пріоритету для рухомих об’єктів однакової маси, великі об'єкти повинні виштовхувати малі об'єкти природним шляхом. Використовуйте індекс лише для визначення пріоритету для об'єктів однієї команди. Ворожий об'єкт не повинен бути здатним виконувати роль непорушної стіни для об’єкта гравця просто тому, що він був породжений першим і тому має більший пріоритет.
Фіблз

Я не вважав масою чи командою; ваші налаштування здаються логічним способом виправити мою відповідь.
Пікалек

2

додайте час на пошук шляху

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

введіть тут опис зображення

і ось впровадження Objective-C: http://allseeing-i.com/ASIPathFinder

введіть тут опис зображення


1
Я читав і реалізував це раніше. Навіть з кількома нитками це не дуже корисно в моїй ситуації. У грі на RTS може бути сотні рухомих одиниць і карт-сіток, розміром яких більше 500 квадратів. Накладні витрати для обчислення часових шляхів для кожної одиниці занадто великі. Просто додам, я не кажу, що відповідь rakkarage невірний, це дуже акуратний алгоритм. Я просто кажу, що ситуації, в яких це корисно, обмежені його складністю.
Фіблз

я просто запускаю весь алгоритм пошуку всього шляху кожного кроку замість того, щоб повністю розуміти і реалізовувати це, але я думаю, що мені, можливо, доведеться в кінцевому підсумку
Rakka Rage

0

Насправді, я не думаю, що ви повинні це виправити. Якщо (я можу здогадатися) стрілки вказують вектори сили, застосовані до будь-якої сфери, у будь-якому положенні в сітці (ймовірно, інтерпольовані "дволінійно" або аналогічно, або якось більше "аналог", ніж просто 0/1), то тоді поведінка фізично правильна, і вам слід привітати себе за гарне поводження.

Дві сфери в хорошому балансі, оскільки вони сидять там і ненавидять один одного. Мабуть, якщо вони рухаються трохи вправо, "стрілка сили" вправо впливає на праву бічну сферу трохи більше (і навпаки, на ліву бічну сферу; трохи менше), і тому вони рухаються назад до рівноваги. Ось так і має бути.

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

Можливо, замість цього вимкніть найближчі ліві / праві стрілки сили або розташуйте їх іншим способом, який не є симетричним і не спонукає до балансу ?

Я думаю, що було б погано виправити штучно це виправити ... надто рано було б волохатим.


Це не відповідає на запитання. Я розумію вашу мотивацію, але в кінцевому підсумку питання полягає в тому, як поводитися з ситуацією. Ми не знаємо намірів ігрового процесу, тому судити про те, чи це проблема чи ні, залежить від Fibbles. Зміна стіни може змінити цільове призначення. Питання є дійсною проблемою, яку можна вирішити.
Фельсір

Моя відповідь в основному: (пере) розташувати сили або перестроїти щось інше за сценарієм, але не перебирайте фізичний вирішувач (" Імхо, що слід виправити - це стіна, розміри сфери чи щось інше серед кам'яних каменів" самі. "). Питання " Які методи зазвичай використовуються для вирішення таких ситуацій?" Я думаю, що мій А - це "звичайно використовуваний метод" і дуже вирішення проблеми. Наприклад, онлайн-ігри з міні-гольфами (на які Q нагадує дуже багато) задушують кулі, якщо навколишнє середовище вимагає цього. Помилкова фізика - це поганий шлях, іммо.
Stormwind

Я згоден, що вирішувач фізики повинен залишатися в такті. Питання стверджує, що сфери повинні шукати ціль, в основному, як змінити поведінку агентів (таким чином, не фізика або рівень рівня). Якщо змінити макет рівня, це може вирішити цю ситуацію, але вона може з'явитися в іншій схемі. Отже, питання відрізняється від прикладу міні-гольфа, який ви наводите, оскільки в цьому випадку питання полягає в тому, щоб конкретно уникнути тупикової ситуації.
Фельсір

Як бачите, я також пропоную переставити сили у відповідь. Здається, після цього трохи залишилося :-).
Stormwind

Перестановка стін або зміна розмірів сфери в моєму випадку не під силу, хоча це може бути і в інших. Скріншот - з режиму налагодження двигуна RTS. Існує багато різних розмірів одиниць, і стіни можуть бути розміщені за бажанням гравця. Стрілки, які ви бачите, генеруються моїм алгоритмом "Швидкі потоки полів". Вони є нормалізованими векторами, які використовуються для впливу на напрямок руху рухомих агрегатів. Змінити довжину векторів неможливо, оскільки всі рухомі одиниці в групі мають одне і те ж поле потоку.
Фіблз
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.