Pathfinding: мозаичная навигационная сетка

Я разрабатываю RTS на основе тайлов в реальном времени. Это пример карты:

карта

Эта карта состоит из 4 регионов по 256 плиток в каждой. Синие плитки представляют собой препятствия. Юниты могут двигаться в стандартных восьми направлениях. Юниты привязаны к плиткам; одна плитка может содержать одну единицу.

Вот некоторые примеры идеальных путей, которые я ищу. Типичные вещи A *:

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

Мой вопрос: применима ли навигационная сетка к RTS на основе тайлов? Я видел только навигационные карты, используемые в играх, где юниты движутся свободно и не привязаны к сетке тайлов. Как будет выглядеть навигационная сетка на этой конкретной карте? Пример изображения будет отличным.

path-finding rts navmesh

— mario_sunny
источник

Что бы это ни стоило, я вспоминаю, что слышал, что некоторая «странность» Starcraft I была вызвана поздним решением переключиться с 2d на изометрическую 3d - весь код пути был написан с ожиданием 2d ландшафта!

— Raven Dreamer

Да, навигационные сетки все еще применимы к играм на основе тайлов. Хотя в первую очередь они будут использоваться в качестве оптимизации. Например, я преобразовал нижний левый угол вашего изображения в сетку навигации:

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

В этом случае каждый зеленый квадрат будет навигационным узлом. Как вы можете видеть, это резко уменьшает количество узлов, которые A * должен обрабатывать. Затем юниты могут просто пройти к центру каждого из этих узлов.

Генерация этих узлов является другой проблемой. Это может быть сложно решить, как сформировать узлы. На сайте есть несколько вопросов, где вы можете найти идеи о том, как вы хотели бы реализовать это:

Разделение многоугольника на блоки разного размера

Идентификация четырехугольных паттернов в двумерном массиве

/programming/20220215/minimum-number-of-rectangles-in-shape-made-from-rectangles

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

— MichaelHouse
источник

Мне трудно понять, как это превосходит чистый А *. Как бы, например, ваша навигационная система оптимизировала вычисление поиска пути для зеленого пути в исходном ответе?

— mario_sunny

Зеленый путь имеет 15 узлов, путь сетки - 5. Это даже не включает количество тупиков, которые необходимо проанализировать при поиске этого пути. Смысл навигационной сетки не обязательно заключается в создании наиболее прямых маршрутов, а в том, чтобы уменьшить количество узлов, через которые A * должен искать, таким образом, резко увеличивая скорость A *. Существуют стратегии размещения узлов в вашей навигационной сетке, которые могут найти баланс между прямыми путями и меньшим количеством узлов (например, узлов в каждом углу всех препятствий). Есть также оптимизации, которые могут быть выполнены на готовом пути.

— MichaelHouse

Я начинаю понимать. Будет ли зеленый путь выглядеть иначе с оптимизацией navmesh? Похоже, вы подразумеваете, что отряд переместится в центр каждого прямоугольника на пути к конечной точке. Вы предлагаете, что оптимизация после A * сократит путь?

— mario_sunny

Да, если бы вы использовали центр каждого узла, путь выглядел бы по-другому. Однако вы можете решить использовать что-то, кроме центра (например, вы можете использовать углы каждого узла). Или вы можете сделать так, чтобы ваши узлы были не больше четырех квадратов (делая меньше узлов, но заставляя узлы следовать геометрии ближе). Или вы можете выполнить некоторые оптимизации на пути, чтобы быть более прямым после того, как вы его найдете. Вы даже можете использовать nav-mesh в качестве первого прохода, а затем использовать A * для прохождения через каждый узел (что позволяет вам «проходить по ходу», пока юнит движется, распределяя влияние на производительность во времени).

— MichaelHouse