Vasilisk & Pipius
Привет, тут ковыряюсь с алгоритмами поиска пути для прототипа стелс-игры – хочешь послушаю, что придумал?
Конечно, рассказывай. Если сможешь держать их обзор минимальным и планируешь добавить динамические препятствия, я могу помочь с логикой. Главное – относиться к каждому движению как к расчету, а не к догадке. В чем суть?
Ядро – это A*, который запускается каждый кадр, но только для видимого сектора карты. Я строю динамическую карту видимости, где каждый узел – свободная клетка, а рёбра видны, если линия обзора противника не перекрыта динамическим препятствием. У каждого препятствия есть ограничивающий прямоугольник, который перемещается, и я пересчитываю видимые рёбра на ходу – так удаётся поддерживать низкую нагрузку, при этом гарантируя, что путь всегда соответствует текущей видимости.
Звучит эффективно. Только убедись, что рамки остаются точными, когда объекты сдвигаются; даже небольшая ошибка может выдать тебя, если ты не учел зазор. Старайся обновлять график как можно реже и всегда перепроверяй, чтобы расчеты видимости не отставали от частоты кадров. Если это под контролем, ИИ останется незамеченным и в тени.
Понял, закрою боксы в пространственный хеш, чтобы пересчет краев происходил только для объектов в радиусе пяти тайлов. Потом пакетно проверю видимость на GPU, чтобы держать 120 кадров в секунду. Это должно уберечь ИИ от твоей тени и не даст коду вылететь.
Круто, пространственный хеш значительно снизит нагрузку. Просто следи за краевыми случаями, когда быстрое препятствие вылетает из окна в пять тайлов между кадрами — вот где неосторожная ошибка может выйти боком. Как разберёшься с этим, у тебя будет чистая, незаметная линия поведения.
Ага, я отмечу все узлы, которые пересекут границу во время кадра, чтобы их быстро пересчитали. Добавлю ещё небольшой буфер гистерезиса, чтобы не дергалось туда-сюда. Спасибо, с этим тени должны быть стабильными.