Столкновение окружностей

[Alex_S]

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

[-De-]

Возьмите уже физ. движок. Иначе это значит писать свой.
На геймдеве есть вполне статьи, которые описывают как физ. движок устроен, если что.
http://www.gamedev.ru/code/terms/?physics

[ashIndie]

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

Добавлено через 1 минуту
-De-, а как физический движок решит проблему?....именно эту, на словах как вы себе этот алгоритм представляете?...щас разбираюсь с nape. в принципе и на нем можно было бы сделать, да и побыстрее он будет.

[anmelegov]

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

[ashIndie]

обход препятстыий есть, но он ситауционный. тоесть юнит не рассчитывает весь путь,а движется пока не столкнется с препятствием, тогда начинает искать пути для обхода. подсмотрел на xitri.com. Но это не идеальный конечно алгоритм. Нужно сделать A*, но он мне не до конца понятен. Правда я мало с ним разбирался, но хочется четкого понимания, прежде чем всю основу игры переделывать под него. В нем бы все проблемы решились. Поиск оптимального пути, обход препятствий и других юнитов путем присвоения клеткам сложностинаверное тут вопрос лишь в одном. Надо это сделать и все.

[-De-]

Ну как, возьмет и решит, солвер конкретно занимается разрешанием столкновений кучи тел (задачка как их там всех получше растолкать - весьма сложная). Не видел nape, в бокс 2д ставишь побольше дампинг и достаточной силой тягаешь юниты куда надо. Кучу кружков/зомби, толпящихся, пытающихся набижать на героя очень даже представляю.

А* работает так: на каждом шаге ищем точку на уже пройденном пути к цели такую, чтобы если из этой точки получится по "прямой" (т.е. без препятствий) прийти к цели, то полученный путь будет минимальным. И из неё двигаемся по возможности по направлению к цели.
В случае динамических препятствий веселуха обеспечена)

[ashIndie]

-De-, да я предполагаю что нагрузка будет серьезная, если будет юнитов 100.
по идее и щас у меня она большая, потому что каждый юнит думает и рассчитывает путь. Надо попробовать сделать на nape и сравнить производительность, хотя я и щас понимаю, что она увеличится.
Просто я как-то сразу не подумал использовать для игры с видом сверху физический движок, как то он у меня не ассоциировался с таким жанром.

[stweet]

Сообщение от ashIndie

-De-, да я предполагаю что нагрузка будет серьезная, если будет юнитов 100.
по идее и щас у меня она большая, потому что каждый юнит думает и рассчитывает путь. Надо попробовать сделать на nape и сравнить производительность, хотя я и щас понимаю, что она увеличится.
Просто я как-то сразу не подумал использовать для игры с видом сверху физический движок, как то он у меня не ассоциировался с таким жанром.

В таких случаях поступают малость иначе. Вам бы саму задачу реализовать, не важно(без разницы) быстро ли медленно будит работать решение. А вот когда реализуете оптимизировать будит проще уже готовое решение не же ли оптимизировать на ходу! Алгоритм А* не так уж и сложен в понимании и по отзывам это самый шустрый, им пользуются почти все игроделы сих жанров.

Самый оптимальный вариант работать с вложенной (2 3 n...)-х мерной сеткой, т.е. если 2 объекта находятся одновременно в одной зоне(на одной глубине) то включаем обработку глубже, в зависимости от глубины, где глубина это и есть ваши сетки. На последней сетке ячейки можно делать как раз размером с критической точкой столкновения.

Что про динамические объекты, тут то же не так сложно. Есть такое понятие "отклонение от траектории". Т.е. когда путь найден, но в пути (по мере достижения цели) попадаются объекты то целевую точку меняем на ту что безопасная от объекта и уже от неё высчитываем новый путь. Оптимизация в такой логике будит "сохранение путей".

Тут по сути даже саму сетку диких размеров делать не нужно, у вас же юнит не забегает за приделы экрана, а значит сетки хватит по размеру вьювера, просто её двигаем вместе с вьювером.

Есть ещё понятие дистанционной сетки т.е. юниты просчитывают свои сетки но в приделах некой дистанции, это что то похоже на то что описали выше с примером 2DBox.