Полезное

Мы Вконтакте

Discord канал

#
След.
Модератор: icms
Аватара пользователя
Пользователь
Сообщения: 62
icms писал(а):
Полностью согласен с предыдущим комментарием. Осталось выяснить какой формы и какого размера преграды. antokog а дайте нам схематическое изображение вашего уровня(естественно его части) но масштабы что бы были реальными.

Уровень состоит из таких тайл сетов (около 10 на 1 уровень) на 1 плитке помещается 2 нпс в ширину и 2 в высоту. Конечно им не нужно ходить по всей карте, но на половину или треть одного тайл сета надо. Совсем лабиринта не будет, но приблизительно такие штуки проходить надо:

ИзображениеИзображение
ИзображениеИзображение
Аватара пользователя
Пользователь
Сообщения: 469
Если мы идём в сторону максимального облегчения и препятствия у нас вот эти серые блоки. То самый простой способ это дать этим препятствиям верхнюю и нижнюю точки обхода. Т.е. какой принцип: лайнтрейс - цели нет- есть препятствие, обращаемся к нему берём точку обхода в зависимости от направления на цель т.е. верх или низ. Облетаем. Можно немного усложнить , но оптимизировать: если на пути несколько блоков, просчитывать обход по обоим точкам и выбирать кротчайший путь. Насчёт кастов и каждого кадра, каст не прожорливая функция , а вот делать это в тике точно не нужно. Всё зависит от скорости объекта и размера блока. Пример - если скорость равна 3 размера в секунду а ширина блока 1 блок соответственно для ровного облёта хватит всего 6 раз в секунду(и то можно всего 3) нахождение цели сложение 2х скоростей и деление на размер. Можно использовать сплайны для плавности. Можно конечно использовать математику предложенную выше, но если можно сделать проще зачем мудрить, тем более с математикой нужно ещё учитывать размер мухи, чего помоему в расчёте небыло.
_________________
Project SKIT
Аватара пользователя
Пользователь
Сообщения: 589
icms писал(а):
тем более с математикой нужно ещё учитывать размер мухи, чего помоему в расчёте небыло.


Как это не было?

Цитата:
Вторые стороны - это радиус капсулы персонажа, которого нужно нам обойти. Обычно берется больше.


Берется больше с учетом размеры мухи, которая обходит. Т.е прибавляешь радиус мухи которая обходит.

antokog писал(а):
Уровень состоит из таких тайл сетов (около 10 на 1 уровень) на 1 плитке помещается 2 нпс в ширину и 2 в высоту.


Если из таких состоит в таком положении. Не под углом. Посчитать четыре waypoints, которые находятся по углам прямоугольника не сложно.
Напиши алгоритм поиска наименьшего и наибольшего значения координат всех точек прямоугольника.
От меньшего значения вычитай размеры мухи, а к большему прибавляй размеры мухи. Плюс с запасом ещё бери процентов на 30.
Аватара пользователя
Пользователь
Сообщения: 4069
я бы трэйсы во все стороны пулял, как в циклах так и нет, мой алгоритм выглядел бы примерно так, но раза в 3-4 сложнее(что бы учесть все детали и оптимизировать), желтые и оранжевые трэйсы это те что в циклах, зеленый точки это вэйпоинтсы.
Такое количество итераций выполнится за тик вообще без какого либо ущерба(проводить функцию повторно по мере достижения мухи последнего вэйпоинтса в массиве или в другой ситуации), так же бы раз в секунду я бы кидал линию по направлению к персонажу, что бы знать когда выходить на финишную прямую.

https://picua.org/images/2020/08/04/180 ... 303130.png

p.s. в 99% случаев у меня каст делается один раз на бегин плээ, затем есть - ссылка, и да бокстрэйсы сфер трэйсы использовать здесь удобнее, но в принципе все также как и с лайнтрэйсами, здесь будет в основном математика 3 класса, главное понимать что такое форвард вектор и ап вектор, и как их складывать и как прибавлять к ним.
А если нацелится на облет препятствий просто через вверх или низ, без построения пути на 5 и более точек , это все будет намного проще.
Аватара пользователя
Пользователь
Сообщения: 62
Prytaleks писал(а):
я бы трэйсы во все стороны пулял, как в циклах так и нет, мой алгоритм выглядел бы примерно так, но раза в 3-4 сложнее(что бы учесть все детали и оптимизировать), желтые и оранжевые трэйсы это те что в циклах, зеленый точки это вэйпоинтсы.
Такое количество итераций выполнится за тик вообще без какого либо ущерба(проводить функцию повторно по мере достижения мухи последнего вэйпоинтса в массиве или в другой ситуации), так же бы раз в секунду я бы кидал линию по направлению к персонажу, что бы знать когда выходить на финишную прямую.

https://picua.org/images/2020/08/04/180 ... 303130.png

p.s. в 99% случаев у меня каст делается один раз на бегин плээ, затем есть - ссылка, и да бокстрэйсы сфер трэйсы использовать здесь удобнее, но в принципе все также как и с лайнтрэйсами, здесь будет в основном математика 3 класса, главное понимать что такое форвард вектор и ап вектор, и как их складывать и как прибавлять к ним.
А если нацелится на облет препятствий просто через вверх или низ, без построения пути на 5 и более точек , это все будет намного проще.


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

ИзображениеИзображение

Обход:

ИзображениеИзображение

ИзображениеИзображение

ИзображениеИзображение

AngleArray:

ИзображениеИзображение
Аватара пользователя
Пользователь
Сообщения: 4069
если не можешь исправить сделай по другому, массив с углами не нужен для этой задачи, delay часто источник багов.
Мой код бы выглядел совсем иначе(да и чей угодно).
Когда встречаются две мухи, одна продолжает тоже движение, другая обходит через верх или низ.
Аватара пользователя
Пользователь
Сообщения: 589
Я не пытался разобраться в твоем коде.
Но я подумал. А почему они сталкиваются ?
У тебя нет проверки перед тем как начать движение, не занят ли путь другой мухой?

Например, в той же игре Dune. Стоит поставить препятствие на пути юнита, как он тут же разворачивается и ищет другой путь.
Аватара пользователя
Пользователь
Сообщения: 62
Agny писал(а):
Я не пытался разобраться в твоем коде.
Но я подумал. А почему они сталкиваются ?
У тебя нет проверки перед тем как начать движение, не занят ли путь другой мухой?

Например, в той же игре Dune. Стоит поставить препятствие на пути юнита, как он тут же разворачивается и ищет другой путь.

Они могут сталкиваться когда гоняются за игроком. То есть когда они рядом и резко меняют направление движения, они могут врезаться и такая проверка тут не поможет...
А так они обходят друг друга
Аватара пользователя
Пользователь
Сообщения: 62
Prytaleks писал(а):
если не можешь исправить сделай по другому, массив с углами не нужен для этой задачи, delay часто источник багов.
Мой код бы выглядел совсем иначе(да и чей угодно).
Когда встречаются две мухи, одна продолжает тоже движение, другая обходит через верх или низ.

А если без массива, то как?
Аватара пользователя
Пользователь
Сообщения: 4069
если коротко, у меня бы был массив с точками, для движения, которые создавался бы и изменялся динамически, и еслибы мне не нужно было движения по кривой, делал бы без сплайна.
как? - ну здесь вероятно на всю ночь работы, вот так.


Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9

UEngine.ru © 2017
Все права защищены. При копировании материалов с сайта, ссылка на первоисточник обязательна.
Яндекс.Метрика
Главная страница