Комментарии 18
Как же вы вовремя =) Как раз на каникулах хотел в этой теме разобраться. Спасибо огромное
0
А когда следующая? :-)
0
В таком случае набором действий нашего моба может быть прибавление вектора, поворачивающего его в какую-нибудь сторону от препятствия, со скоростью, пропорциональной расстоянию до преграды (float DistanceToBarrier())
А вот здесь про полярные координаты как раз и надо. Функция atan2(x, y) вам в помощь.
+1
Спасибо, путние статьи:) Как раз повторю курс геометрии за 10й класс:))
0
Маловато!!!.. Маловато будет!!!
Все примеры рассчитаны на танк который прет прямо без цели, и даже как я понял WayPoint уже не координаты а векторы откланения, но что делать если мы движемся из пункта А в пункт Б? (напомню, что тут как раз вычитание вектора А из Б)
Все примеры рассчитаны на танк который прет прямо без цели, и даже как я понял WayPoint уже не координаты а векторы откланения, но что делать если мы движемся из пункта А в пункт Б? (напомню, что тут как раз вычитание вектора А из Б)
0
и вот еще тут (см. «Целевые способы»)
если к примеру шаг у нас = 0.3f а до точки дистанция 0.5f то чистого равенства не случится и попрет наш персонаж в бескрайние просторы 3д пространства.
if(x==Points[Position].x && y==Points[Position].y) {//если мы на месте
если к примеру шаг у нас = 0.3f а до точки дистанция 0.5f то чистого равенства не случится и попрет наш персонаж в бескрайние просторы 3д пространства.
0
Код приведен для примера, точность просчета «достижения цели» может задаваться разными способами. В некоторых случаях применима формула, но только если мы двигаемся от меньшего значения к большему:
Иногда нужно добавить доверительную зону, то есть «мы дошли если наши координаты совпадают с точностью +-ЗОНА»
Много вариантов такой оптимизации и устранения потенциальных багов. Я не стал об этом писать, потому что цель статьи создать образное представление о способах передвижения.
if(x<Points[Position].x && y<Points[Position].y)
Иногда нужно добавить доверительную зону, то есть «мы дошли если наши координаты совпадают с точностью +-ЗОНА»
if((x>Points[Position].x-ZONE && x<Points[Position].x+ZONE) &&
(y>Points[Position].y-ZONE && y<Points[Position].y+ZONE))
Много вариантов такой оптимизации и устранения потенциальных багов. Я не стал об этом писать, потому что цель статьи создать образное представление о способах передвижения.
0
Я специально сделал акцент на этом — суть статей рассказать как заставить двигаться «танк» по уже имеющемуся пути. Вопросы поиска пути, выбора алгоритмов обхода препятствий и т.д. я не брал. Для всех примеров нужно принять одно допущение — танк уже знает куда ему ехать. И тогда примеры покажут как это ему сделать.
0
Первая часть статьи, имхо, совершенно некорректна с т.з. терминологии. Вектор с т.з. математики несет в себе не только направление, но и скорость(модуль вектора). В первой же части статьи речь идет вообще не о векторах, а о банальном передвижении по плоскости используя значения dx, dy. И только ко второй части статьи автор исправляется и приводит терминологию в соответствие с наукой )
ЗЫ. Ну и вообще статья про движении некоего сферического объекта в вакууме…
ЗЫ. Ну и вообще статья про движении некоего сферического объекта в вакууме…
+1
Если погрузиться в терминологию, то вы правы. Вектор действительно несет в себе и направление и скорость (длина вектора), и значит вся первая часть статьи как раз правильна по терминологии — ибо там я использовал как раз термин «вектор» в правильном значении. В дальнейшем, с введением дополнительной переменной, вектор потерял свою функцию, оставив за собой лишь право указывать направление (нормализованный вектор), а значит там он стал недо-вектор, с чисто математической точки зрения. Но и это не совсем верно — так как у него все еще осталась длина, которая всегда равна единице (+ в вычислении новой скорости она так же использовалась), только она не используется для задания перемещений. Так что не будем вдаваться в тонкости терминологии — я думаю суть ясна и для понимания способов передвижения этого может быть достаточно.
0
Да я к тому, что у вас в первой части статьи модуль вектора используется в значении «шаг перемещения объекта», а не в значении «скорость»(или «импульс»). Что может и верно для игрушек типа TowerDefence, где перемещения объектов не учитывают его параметры(массу хотя бы), но не подойдет для физически приближенной к реальности игры. Короче не хватает в начале статьи дисклеймера о том, для какого типа объектов и в какой игровой реальности это все написано. Ибо тут нету ни физики, ни пасфайндинга, ни определения столкновений… только лишь метод складывания координат, когда уже все остальное известно и просчитано. По идее, если человек уже учел физику движений, поиск пути, столкновения, то сложить пару координат ему проблемы не составит?)
0
Статьи рассчитаны на новичков, которые еще только начинают свой путь реализации первого игрового ИИ. Чтобы они не закончили свою деятельность на первых же минутах кодинга я написал эти статьи. Те, кто уже знает все вышеизложенное, и даже больше, не станут читать, и уж тем более комментировать статьи. Есть множество специальных топиков по поискам пути, реализаций физики и т.д. Там они и проявляют свою активность. Лично я, начиная делать ИИ столкнулся с выбором — «плиточный vs векторный vs смешанный» способ реализации. Может кому-то поможет.
0
Не могли бы вы показать, где можно прочитать про расчет коллизий, которые случились за промежуток времени t в случае векторного перемещения? А то я даже гуглу не могу сформулировать внятный запрос.
Из того, до чего я додумался — только «растяжение» AABB по вектору. (как и куда тянуть — не додумался :) )
Из того, до чего я додумался — только «растяжение» AABB по вектору. (как и куда тянуть — не додумался :) )
0
Джоб Макар — Секреты разработки игр в Macromedia Flash MX — 2004г. Книга есть в свободном доступе в интернете. Там целая глава посвящена вопросам обнаружения столкновений — с.85-136
И кстати метод растяжения один из наиболее известных, когда объект как бы вытягивают по направлению его движения, создавая вытянутую копию его, с которой и проверяют столкновения.
И кстати метод растяжения один из наиболее известных, когда объект как бы вытягивают по направлению его движения, создавая вытянутую копию его, с которой и проверяют столкновения.
+1
Спасибо! Качаю. :)
В общем случае, все решилось просто: победить свою лень и правильно составить поисковый запрос.
Первая итерация дала название техник для расчета коллизий для быстродвижущихся объектов:
— swept-collision tests (wikipedia)
— multisampling.
Если со второй все более-менее понятно, то первая техника это именно то самое «растяжение» объекта вдоль вектора движения. Как это реализовать для простейшей геометрии рассказано, например, тут: http://www.gamasutra.com/view/feature/3383/simple_intersection_tests_for_games.php.
В общем случае, все решилось просто: победить свою лень и правильно составить поисковый запрос.
Первая итерация дала название техник для расчета коллизий для быстродвижущихся объектов:
— swept-collision tests (wikipedia)
— multisampling.
Если со второй все более-менее понятно, то первая техника это именно то самое «растяжение» объекта вдоль вектора движения. Как это реализовать для простейшей геометрии рассказано, например, тут: http://www.gamasutra.com/view/feature/3383/simple_intersection_tests_for_games.php.
0
Рейкастинг (ray-casting) можно было бы осветить малость, именно его зачастую используют для обнаружения препятствий в векторном мире
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Способы передвижения компьютерных персонажей (часть 2)