Исправление багов я начал от сложных и большик к маленьким и простым.
Думаю, что всем понятно - исправить поиск пути на большие расстояния сложнее, чем добавить управление на qweasdzxc.
Увы, но с поиском пути я обмишурился.
Оказалось, что изначально моя логика содержала фатальную ошибку. (если интересно, потом могу расписать, может пригодится).
Но есть у меня вот такая идея:
Обычно существа идут в точку где стоит игрок, чтобы дать ему по щщам, в прочие точки.
Только в первом случае нам важна супер точность.
К счастью, промахнуться тут невозможно мы просто проверяем ближайшие 8 клетк карты.
Наибольшие проблемы с производительностью возникают, когда нам нужно просчитать длинный путь, например в лабиринте.
Особенно если существ много. Конечна, сделанная мною система "буйков" на карте (классика экономии текущих расчётов за счёт предварительных, позволяет избегать расчётов на гигантские расстояния).
Однако, однако!
Преположим, нам передвинуть пяток существ всего-то на пять клеток, но для этого им придётся сделать хороший крюк.
К сожалению, пускать эти расчёты во время хода существ слишком накладно. Нам же нужно как можно быстрее, вернуть ход игроку.
А что есть такие "длинные" расчёты делать во время хода игрока и даже тогда, когда программа ходит за других существ?
Что если запускать поиск пути для неписей в этот момент?
Не для всех, а только для тех, чья цель дальше, скажем 3х или чуть более клеток.
Ведь у необходимости искать "дальний" путь в том, что нам не нужна идеальная точность.
ТЕ как сейчас происходит поиск пути в Фаллен?
Создаётся событие иди в x, y (Z скрыто и из вычислений исключено).
Потом, когда запускается процесс обработки событий, программа, последовательно перебирает все события и производит поиск пути в основном потоке, для каждого события.
Так вот, о чём это я, ах да. Предоложим, мы выдали существу задачу, иди в x,y и создали событие.
Что мешает нам сразу передать это событие в обработку методу (потоку), который передаст вычисления в отдельный поток и запишет уже заранее готовые результаты в соответствующее событие.
Данный поток будет постоянно крутиться, ожидая данных от основного потока и приведёт к тому, что основной поток вообще не будет занят вычислениями пути.
Один нубский вопрос, это постоянная передача данных о том, какие события нужно обрабатывать.
Но, думаю, что я не первый, кто задаётся таким вопросом.
Имхо, самый простой вариант, генерить пакеты задач и запускать их в нескольких потоках.
Но если кто работал в этом направлении, буду рад послушать совет.
