Показать сообщение отдельно
Непрочитано 25.12.2013, 07:53   #13
Аватар для rage
Герой

По умолчанию Re: Патчфинд 3.0

Цитата:
Сообщение от Pointer*Rage Посмотреть сообщение
Как раз именно этот вариант будет выгоден, в отличие от Вашего, где бессмысленно и беспощадно, мы, условно, чекаем путь каждый тик.
Ну да, конечно. Проверить NSWE у уже выбранной клетки несравнимо более затратная операция, чем накладывать графы, вычислять пересечения, хранить списки и бегать по ним с нотифями, да еще все это в многопоточной среде. К тому же если посмотреть как игроки бегают, они кликают по 10 кликов в сек. А если это режим фаллоу так ваще сказка, сколько раз в сек мы путь перестраиваем...

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

Цитата:
Сообщение от Pointer*Rage Посмотреть сообщение
Эта вся информация у нас опять же есть. Если мы наложим граф проходимости на граф расположения игровых объектов, то получим... Я это уже все описывал в первом посте, под названием "коллизии".
ок, вы хотите сказать, что эта операция дешевле чем чекнуть NSWE у клетки?

Цитата:
Сообщение от Pointer*Rage Посмотреть сообщение
В каком месте у нас возникнет оверхед? На хранение доп. ссылок точек, которые изменили свое состояние? Не смешите, Вы сами знаете сколько занимает в памяти, ссылка, а не объект. На хренение самого метода в области перма? - Вообще бред, пара килобайт не добавит оверхеда, в данном случае, это не микроконтроллер в условиях ограниченных ресурсов.


В данном случае, это эвристика, рекомендую более плотно ознакомиться с понятием "эвристический поиск пути".
Именно на хранение списков и бегание по этим спискам в конкурентной среде.

Подписание пути на уведомление должна быть синхронизированная операция, что уже не дешево. Список должен быть потокобезопасным, а это значит, что либо итерироваться по нему нужно будет из синхроблока либо копировать используя какойнить CopyOnWriteArrayList. Опять же, не дешевые операции. Учитывая то, что построенные пути живут не долго, в среднем пару сек. Все это видится мне крайне сомнительным.

В прочем не исключаю возможность эффективной работы данного алгоритма, это легко проверить. Есть уже реализация? Можно было бы сравнить производительность.
rage вне форума Ответить с цитированием