Заранее извиняюсь, за столь долгий ответ, сессия, работа и другие заботы
Цитата:
Сообщение от rage
Ну да, конечно. Проверить NSWE у уже выбранной клетки несравнимо более затратная операция, чем накладывать графы, вычислять пересечения, хранить списки и бегать по ним с нотифями, да еще все это в многопоточной среде. К тому же если посмотреть как игроки бегают, они кликают по 10 кликов в сек. А если это режим фаллоу так ваще сказка, сколько раз в сек мы путь перестраиваем...
|
Что мешает не перестраивать полностью путь, если новая точка назначения рядом с предыдущей? Достаточно просто достроить путь и прогнать сглаживание, причем можно делать его только в два прохода, ибо основной путь уже сглажен.
Для стрелок вообще должны предлагаться другие алгоритмы поиска пути, то что мы имеем сейчас никуда не годиться.
Цитата:
Сообщение от rage
К тому же сколько клеток попадают в двери относительного общего количества клеток? Сколько путей пролегает через двери относительно общего количества построенных путей? Дело конечно ваше, но я бы посмотрел на такой двиг в плане быстродействия |
Проверить ссылку на нулевой адрес памяти конечно очень затратная операция, много больше, чем вытаскивать двери из таблицы региона, а потом еще и искать нужную
Цитата:
Сообщение от rage
ок, вы хотите сказать, что эта операция дешевле чем чекнуть NSWE у клетки?
|
Мы не просто чекаем NSWE у клетки, а строим прямую с проверкой NSWE у всех ее точек. И да, проверить нулевую ссылку, а потом булеан значение двери будет таки медленее, но не сильно, в любом случае мы всего лишь потратим на один такт больше, что в данном случае бесконечно малая нагрузка
Цитата:
Сообщение от rage
Именно на хранение списков и бегание по этим спискам в конкурентной среде.
Подписание пути на уведомление должна быть синхронизированная операция, что уже не дешево. Список должен быть потокобезопасным, а это значит, что либо итерироваться по нему нужно будет из синхроблока либо копировать используя какойнить CopyOnWriteArrayList. Опять же, не дешевые операции. Учитывая то, что построенные пути живут не долго, в среднем пару сек. Все это видится мне крайне сомнительным.
|
Маловероятно, что в одной точке будет более 5-ти событий одновременно.
Зачем нам глобальные нотификаторы?
Нам нужны только для точек, не более.
Цитата:
Сообщение от rage
В прочем не исключаю возможность эффективной работы данного алгоритма, это легко проверить. Есть уже реализация? Можно было бы сравнить производительность.
|
К сожалению сейчас нет времени работать над прототипом, возможно реализую ближайшие месяца, как будет время, тогда уже можно будет говорить о практической эффективности, ну а пока будем рассуждать только по теоритической части
Цитата:
|
Еще один минус "уведомлений" о закрытие двери и т.д. это то, что нам нужно знать закрыта конкретная клетка для прохода или нет непосредственно в момент когда мы на нее хотим переместиться. Так как за то время пока мы добежим до двери она может и открыться. И следовательно, уведомления которые пришли раньше просто бесполезны.
|
Да, такая проблема есть, по идее нужно реализовать жесткую остановку задачи "перепоиска" пути, при этом сохранять старый путь.