Мне нужно о луче знать много (AI)

[set440]

Мне нужно много знать о луче...

В общем, я процитирую, то что уже где-то говорил:

Возникло какое-то абсурдное представлении об одной из функций
искусственного интеллекта в шутерах: поиск укрытия.

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

Как-бы представление этого процесса пришло в голову само, когда я узнал о
том, что физический движок может пускать лучи (рейкастинг, рейтрэйсинг... как оно правильно называется?),
тоесть если из камеры пускать лучи на супостатов, и параллельно кастовать
циклически луч, по всему видимому, как луч развёртки телевизора, но с
низким разрешением, и искать препятствия (небольшие меши вроде бетонных блоков), то можно врагов
запрограммировать уходить в укрытия, аналогично, враги тоже могут
кастовать лучи, для надёжности.
Если физический движок PhysX способен реалистично обрабатывать разрушение
огромной пирамиды из ящиков, то что ему стоит кастовать много лучей?

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


Судя по всему тут нужны знания тригонометрии.

[Левш@]

Если физический движок PhysX способен реалистично обрабатывать разрушение
огромной пирамиды из ящиков, то что ему стоит кастовать много лучей? Я близок к истине?

А ты попробуй. Когда я использовал рейкаст в АИ приблизительно для похожих целей.
У меня уже 5 субьектов начали вызывать тормоза, машина тогда была не самая слабая.
Я конечно тогда не имел опыта оптимизации, и пускал лучи в Update и все одновременно, но тем не менее всего 5 скриптов конкретно тормознули комп.
Сейчас я бы конечно не стал так делать, тут нужен непременно рандом для каждого субьекта и низкая (но, самодостаточная частота) ) рейкаста.
В последствии, применяя рандом я смог получить уже 50 анмированных обьектов с АИ в кадре без ощутимых тормозов, и это далеко не предел.

[set440]

Левш@ ,

А каково же оптимальное решение с лучами и AI?

[seaman]

Ну вообще-то вот в Gears of War система укрытий сделана на основе Waypoints. При построении уровня указываешь места, где можно прятаться аналогично обычным Waypoints. Ну и указываешь некие характеристики этого укрытия. Вполне может быть, что Raycast как-то и используется, т.к. НПС понимают, что укрытие низкое (например) и приседают. Но во всяком случае это значительно проще, чем в реалтайм автоматом искать где можно укрыться...

[Левш@]

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

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

каково же оптимальное решение с лучами и AI?

Ну я не пророк и не столп (тут по круче меня прогеры сидят), в принципе свои мысли я изложил:

нужен непременно рандом для каждого субьекта и низкая (но, самодостаточная частота) ) рейкаста.

[Belfegnar_]

Пускать лучи по всему видимому? По-моему довольно сомнительная выгода при больших затратах. Лучше потратить эти флопсы на какую-нибудь другую часть аи))
Все зависит от того, каким образом у вас реализовано представление мира ботом. У бота тут преимущество перед игроком - ему не обязательно "видеть" мир как игроку, чтобы иметь информацию о нем, об окружающий объектах.
Ну а поиск укрытия как вариант: на бота триггер-сферу, которая заносит в список объекты на нужном расстоянии(радиус сферы) вокруг бота (или просто список объектов на локации). Первый этап - выбор наиболее близкого к боту объекта из списка. Второй этап - допустим, для каждого объекта заданы точки укрытия, и если это, например, куб - то четыре точки по граням, выбираем ту, которая наиболее удаленная от противника. К ней и прокладываем путь.
Естественно, все это не в Update (или FixedUpdate): просто метод FindCover(), запускающийся соответствующим состоянием автомата, либо оператором планировщика.

[Syberex]

Ну вообще-то вот в Gears of War система укрытий сделана на основе Waypoints.

Сделано так видимо потому, что в зоне обычно есть направление движения для игрока, соответственно для вражеских-юнитов игрок впереди в большинстве случаев, тогда можно и указать выгодные позиции, где от предполагаемого размещения игрока можно укрыться.
В случае, когда враждующие юниты в зоне перемещаются и располагаются спонтанно, все становиться намного хуже и уже будет сложно для проектировщика заложить много таких мест, в которых тогда требуется указывать в каких направлениях они могут быть укрытием. Но не исключается возможность совсем, например можно указывать выгодные позиции, защищающие с 2 или 3 сторон сразу.

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

Возможно оптимальным моментом будет совмещение нескольких подходов, например:
- просматриваем есть ли в определенном радиусе выгодные позиции,
- есть ли предсказанные позиции для укрытия,
- задействуем триггер-сферу,
- задействуем трассировку лучом рандомно влево/вправо (под 45 градусов? от направления движения ...)

[set440]

Спасибо, начну всё переваривать.

Что если пускать луч основываясь на плоскости экрана, скажем, через каждые 20 пикселов[1], как я и описал, как луч развёртки телевизора, но с частотой в 2 FPS и не спешить "проглотить" все точки за пару миллисекунд, а пользоваться временем между кадрами?

В моём случае (1440x900) разрешение матрицы сканирования составляет 72x45, не исключено, что в близких расстояниях в обзор матрицы попадётся препятствие, ну в смысле какой-нибудь коллайдер.

От этого больше больше вреда чем пользы?

*[1](наверно нужно учитывать поправку на разрешение экрана)

Я рассмотрю все варианты, попытаюсь по всякому, но интересен именно этот метод... может можно создать подобный метод, но упростить модель, ну скажем, исключить ландшафт из обработки, не-статичные объекты, и ещё что-то?..

[DbIMok]

если пускать луч основываясь на плоскости экрана

так бот то не в плоскости, а в 3D мире

разрешение матрицы сканирования составляет 72x45

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

[set440]

Ладно, я понял, тут надо основываться на FOV и как-то сообразить, можно-ли кастовать не луч, а отрезок. 2 FPS должно хватить, учитывая, что я собираюсь использовать его параллельно с другими методами... боту не надо искать укрытие больше двух раз в секунду.
Суть в том, чтобы за 2 кадра луча обнаружить и ботов и препятствия, а потом боты должны спрятаться от лучей.

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

[Левш@]

ну скажем, исключить ландшафт из обработки, не-статичные объекты, и ещё что-то?..

Cамо собой,
1. все ненужное исключить.
2. сканировать обьекты выборочно. Например все потенциальные укрытия выделить в отдельный слой и искать только их.
3. из них выделить только ближние (на заданном расстоянии).
4. можно сначала накрыть радиус сфере коллайдером, определить что попалось внутри из нужного слоя и сканировать только эти обьекты.
5. найдя 2-3 пригодных для укрытий обьектов, рандомом выбирать и использовать.

[set440]

Спасибо всем за данную информацию!

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

У меня есть некоторые... догадки... опять.


Надо к FPC прикрепить сферу-триггер, достаточно большую, на неё будут
реагировать юниты.
В области прицела, в горизонтальной плоскости трассировать луч
(желательно, чтобы это был отрезок, а не луч -- может на
производительность повлияет)
В Half-Life 2 насколько мне помнится юниты приседали за укрытия, но стоило
отвести немного прицел, как вставали и тут-же стреляли, а если навести
прицел, то снова прятались, значит, чтоб реализовать подобное нужно
трассировать луч от юнита к игроку и измерять между прицельным лучом угол,
если он больше чем [...] то юнит встаёт из укрытия.
Можно создать 2 вида укрытий: основное и резервное -- когда позиция
основного укрытия невыгодна, то скрипт использует резервное.

Привязывать каждого юнита к отдельно взятому укрытию -- всё равно, что
создавать "сферического коня в вакууме", это не будет выглядеть
правдоподобно.
Поскольку каждый юнит в игре и укрытие -- это отдельный объект, то
реализовать к каждому юниту обращение из одного скрипта врядли
получится... гораздо эффективнее юнитов расплодить как префабы объекта
заскриптованного одним скриптом, из которого к юниту обращаться "this"[1],
аналогично поступить и с укрытиями, а связь осуществлять обращаясь из
скрипта юнита к скрипту укрытия, потому-как они существуют в единственном
числе.
Думаю, скрипт для укрытия понадобится для того, чтоб сообщать, что оно уже
занято.

Я во всём этом не уверен, это только догадки... Искусственный интеллект
одна из самых сложных систем игр, со всем остальным я справлюсь, но без AI
игра не будет представлять никакой ценности, -- в тетрисе,
крестиках-ноликах, шахматах есть логика, но она мне непостижима, здесь же
я могу строить предположения и догадки хотя-бы.

В общем я дотошный.

*[1] Теперь я думаю, что к скрипту экземпляров обращаться как к конкретному объекту не получится, гораздо лучше, чтоб экземпляры общались через глобальный скрипт, который будет хранить массивы о состояниях объектов и планировать.


Я понимаю, без понимания процесса всё это звучит как бред, но чесслово, -- если я не реализую АИ то сойду с ума просто.

[seaman]

В Half-Life 2 насколько мне помнится юниты приседали за укрытия, но стоило
отвести немного прицел, как вставали и тут-же стреляли, а если навести
прицел, то снова прятались, значит, чтоб реализовать подобное нужно
трассировать луч от юнита к игроку и измерять между прицельным лучом угол,
если он больше чем [...] то юнит встаёт из укрытия.

Думаю проще трассировать наоборот от игрока к НПС...

По второму длинному высказыванию повторюсь - есть WayPoint отмеченные как укрытия.Есть скрипт, который знает все такие WayPoint. Выбирается из этого списка укрытий наиболее близкие к НПС, проверяется закроет ли это укрытие НПС от игрока (достаточно одного луча!) - если нет - берем следующее укрытие... Находим ближнее, которое закроет. Есть PathFinding. С его помощью строим путь к укрытию. Бежим. Периодически проверяем все снова...

Улучшение. Перед проверкой закроет ли укрытие НПС от игрока нужно проверить - видит ли НПС это укрытие (тоже один луч!). Иначе НПС может побежать невесть куда...

[set440]

seaman, да, думаю, это оптимальное решение, ведь всё-равно универсальный АИ под все локации создать не получится, они ведь разные.
Думаю процесс разработки такого АИ неотрывно следует за левел-дизайном.

Мне на форуме тут досталась масса информации, думаю, следует обращаться к документации.