Comments 18
Как же вы вовремя =) Как раз на каникулах хотел в этой теме разобраться. Спасибо огромное
А когда следующая? :-)
В таком случае набором действий нашего моба может быть прибавление вектора, поворачивающего его в какую-нибудь сторону от препятствия, со скоростью, пропорциональной расстоянию до преграды (float DistanceToBarrier())
А вот здесь про полярные координаты как раз и надо. Функция atan2(x, y) вам в помощь.
Спасибо, путние статьи:) Как раз повторю курс геометрии за 10й класс:))
Маловато!!!.. Маловато будет!!!
Все примеры рассчитаны на танк который прет прямо без цели, и даже как я понял WayPoint уже не координаты а векторы откланения, но что делать если мы движемся из пункта А в пункт Б? (напомню, что тут как раз вычитание вектора А из Б)
Все примеры рассчитаны на танк который прет прямо без цели, и даже как я понял WayPoint уже не координаты а векторы откланения, но что делать если мы движемся из пункта А в пункт Б? (напомню, что тут как раз вычитание вектора А из Б)
и вот еще тут (см. «Целевые способы»)
если к примеру шаг у нас = 0.3f а до точки дистанция 0.5f то чистого равенства не случится и попрет наш персонаж в бескрайние просторы 3д пространства.
if(x==Points[Position].x && y==Points[Position].y) {//если мы на месте
если к примеру шаг у нас = 0.3f а до точки дистанция 0.5f то чистого равенства не случится и попрет наш персонаж в бескрайние просторы 3д пространства.
Код приведен для примера, точность просчета «достижения цели» может задаваться разными способами. В некоторых случаях применима формула, но только если мы двигаемся от меньшего значения к большему:
Иногда нужно добавить доверительную зону, то есть «мы дошли если наши координаты совпадают с точностью +-ЗОНА»
Много вариантов такой оптимизации и устранения потенциальных багов. Я не стал об этом писать, потому что цель статьи создать образное представление о способах передвижения.
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))Много вариантов такой оптимизации и устранения потенциальных багов. Я не стал об этом писать, потому что цель статьи создать образное представление о способах передвижения.
Я специально сделал акцент на этом — суть статей рассказать как заставить двигаться «танк» по уже имеющемуся пути. Вопросы поиска пути, выбора алгоритмов обхода препятствий и т.д. я не брал. Для всех примеров нужно принять одно допущение — танк уже знает куда ему ехать. И тогда примеры покажут как это ему сделать.
Первая часть статьи, имхо, совершенно некорректна с т.з. терминологии. Вектор с т.з. математики несет в себе не только направление, но и скорость(модуль вектора). В первой же части статьи речь идет вообще не о векторах, а о банальном передвижении по плоскости используя значения dx, dy. И только ко второй части статьи автор исправляется и приводит терминологию в соответствие с наукой )
ЗЫ. Ну и вообще статья про движении некоего сферического объекта в вакууме…
ЗЫ. Ну и вообще статья про движении некоего сферического объекта в вакууме…
Если погрузиться в терминологию, то вы правы. Вектор действительно несет в себе и направление и скорость (длина вектора), и значит вся первая часть статьи как раз правильна по терминологии — ибо там я использовал как раз термин «вектор» в правильном значении. В дальнейшем, с введением дополнительной переменной, вектор потерял свою функцию, оставив за собой лишь право указывать направление (нормализованный вектор), а значит там он стал недо-вектор, с чисто математической точки зрения. Но и это не совсем верно — так как у него все еще осталась длина, которая всегда равна единице (+ в вычислении новой скорости она так же использовалась), только она не используется для задания перемещений. Так что не будем вдаваться в тонкости терминологии — я думаю суть ясна и для понимания способов передвижения этого может быть достаточно.
Да я к тому, что у вас в первой части статьи модуль вектора используется в значении «шаг перемещения объекта», а не в значении «скорость»(или «импульс»). Что может и верно для игрушек типа TowerDefence, где перемещения объектов не учитывают его параметры(массу хотя бы), но не подойдет для физически приближенной к реальности игры. Короче не хватает в начале статьи дисклеймера о том, для какого типа объектов и в какой игровой реальности это все написано. Ибо тут нету ни физики, ни пасфайндинга, ни определения столкновений… только лишь метод складывания координат, когда уже все остальное известно и просчитано. По идее, если человек уже учел физику движений, поиск пути, столкновения, то сложить пару координат ему проблемы не составит?)
Статьи рассчитаны на новичков, которые еще только начинают свой путь реализации первого игрового ИИ. Чтобы они не закончили свою деятельность на первых же минутах кодинга я написал эти статьи. Те, кто уже знает все вышеизложенное, и даже больше, не станут читать, и уж тем более комментировать статьи. Есть множество специальных топиков по поискам пути, реализаций физики и т.д. Там они и проявляют свою активность. Лично я, начиная делать ИИ столкнулся с выбором — «плиточный vs векторный vs смешанный» способ реализации. Может кому-то поможет.
Не могли бы вы показать, где можно прочитать про расчет коллизий, которые случились за промежуток времени t в случае векторного перемещения? А то я даже гуглу не могу сформулировать внятный запрос.
Из того, до чего я додумался — только «растяжение» AABB по вектору. (как и куда тянуть — не додумался :) )
Из того, до чего я додумался — только «растяжение» AABB по вектору. (как и куда тянуть — не додумался :) )
Джоб Макар — Секреты разработки игр в Macromedia Flash MX — 2004г. Книга есть в свободном доступе в интернете. Там целая глава посвящена вопросам обнаружения столкновений — с.85-136
И кстати метод растяжения один из наиболее известных, когда объект как бы вытягивают по направлению его движения, создавая вытянутую копию его, с которой и проверяют столкновения.
И кстати метод растяжения один из наиболее известных, когда объект как бы вытягивают по направлению его движения, создавая вытянутую копию его, с которой и проверяют столкновения.
Спасибо! Качаю. :)
В общем случае, все решилось просто: победить свою лень и правильно составить поисковый запрос.
Первая итерация дала название техник для расчета коллизий для быстродвижущихся объектов:
— 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.
Рейкастинг (ray-casting) можно было бы осветить малость, именно его зачастую используют для обнаружения препятствий в векторном мире
Sign up to leave a comment.
Способы передвижения компьютерных персонажей (часть 2)