поиск пути с препятствиями в игре типа Warcraft 3

Рассмотрим поиск A * на карте на основе тайлов. Прямой код будет следующим: если внутри этой ячейки есть блок, то он недоступен, это нормально.

Но есть проблема с разрешением карты. Когда я смотрю в Warcraft 3, там монстры и структуры имеют разный радиус, и вы можете идти очень близко, что больше похоже на вектор, как это было реализовано?

Кроме того, каково стандартное решение для включения обнаружения столкновения движущихся препятствий с алгоритмом нахождения пути, как Warcraft 3?

Я не могу точно сказать, какой подход использовали разработчики WC3, но он выглядит почти как Hierarchical Annotated A *. Радиус блока, определенный в WC3Editor, использовался как есть для масштабирования 3d-модели, но фактический размер блока для поиска пути был дискретным, возможно, что-то вроде unitSize = (int) (unitRadius / 10). Это не было векторным, это точно.

Допустим, есть много узлов пути, составляющих сетку узлов высокого разрешения. Простой юнит, такой как упырь, имеет размер 2, поэтому, чтобы разместить его где-то в сетке, нам нужно 4 узла свободного пути рядом друг с другом. Герой рыцаря смерти немного больше, имеет размер 3 и занимает 9 узлов пути. Теперь мы помещаем 2 зиккурата вместе, оставляя пространство шириной в 2 узла, и отправляем гуля и рыцаря смерти на другой стороне. Упырь сможет проходить между двумя зиккуратами, а рыцарю смерти придется передвигаться. Как это можно определить?

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

Для более подробной информации вы можете проверить эту статью:

http://harablog.wordpress.com/2009/01/29/clearance-based-pathfinding/

Он будет использовать тесселяцию для создания областей навигации AKA. Эта статья объясняет концепцию с полными диаграммами.

Вы по-прежнему можете поддерживать A * в качестве подхода к поиску пути, однако ваша сеть больше не является сеткой (4-связным графом), а графом, представляющим произвольную связь между полигональными областями. Таким образом, вам придется адаптировать свой алгоритм для соответствия.