Варианты навигации по hex grid

[Germenzi]

Причины, по которым я думаю лучше объединить все вместе:

• Если делать класс навигации отдельно, у него так и так должна быть ссылка на HexGrid, что бы понимать какой тайл где.
• Использование навигации через отдельный класс всегда требует отдельного экземпляра, а это лишние строки кода, зависимости и все такое, проще обращаться к сетке через сцену.
• Достаточно туманное разделение методов. Грань между "нужно только для навигации" и "нужно и для сетки" весьма размыта.

Но во имя объективности отмечу плюсы:

• Возможность создать несколько разных карт со своими особенностями, базирующихся на одной сетке.
• Более простой способ хранения и передачи карты

Как вариант могу предложить статический класс, который содержит методы построения графа по сетке и возвращает объект Astar2D, а затем тайлмап не используется вовсе. Этот способ мне кажется наиболее подходящим, и вот почему:

• Возможности модификации запредельны
• Максимально простая интерпретация объекта в любом месте движка, ведь это встроенный тип

Но также могу отметить один существенный недостаток - непонятки с индексами узлов графа. Поиск пути нам в любом случае придется искать между двумя точками, а не индексами. Как вариант, использовать Astar2D.get_closest_point(), тогда можно просто пихать Astar2D.get_available_point_id () в индексы. Однако это скорее костыль, т.к. этот метод возвращает точку всегда, даже если ее нет на сетке. Либо как то стандартизировать получение индексов из координат.

Итого имеем три варианта:

1. Объединить навигацию и сетку в одну ноду (самый обычный способ).
2. Развести навигацию и сетку по двум самописным классам (неудобный и кривой способ).
3. Создать статический класс с различными парсерами сетки (самый удобный и простой, но сложен в создании)

В общем надо чего то придумать. Второй вариант мне кажется самым неперспективным. Первый вариант - удобным и простым в использовании и написании, третий - быстрым и надежным.

[Germenzi]

Только что потестив понял, что Astar2D.get_closest_point() при построении графа на шестиугольной сетке дает точное преобразование хексов, однако он не реагирует на препятствия, по понятным причинам (точки на препятствиях тупо отсутствуют). Как вариант, добавлять точки на препятствиях, только ни с кем не соединять, или помечать их как disabled.

Либо сделать слой-маску для преобразования координат. В любом случае получаем удобный способ и без возни с индексами, и с удобным преобразованием координат, причем точным и реагирующим на все изменения.

[alex7850]

Как вариант могу предложить статический класс, который содержит методы построения графа по сетке и возвращает объект Astar2D, а затем тайлмап не используется вовсе. Этот способ мне кажется наиболее подходящим, и вот почему

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

get_closest_point()

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

[Germenzi]

Сложным считаю скорее в использовании, т.к. все взаимодействие с сеткой происходит в ее локальных координатах и обойтись только объектом Astar2D не получиться. В создании он как раз таки самый простой, тут моя оговорка. Хотя, использовать экранные координаты можно только на клиенте, а серверу отдавать данные в целочисленных координатах сетки. Я не знаю как там все устроено, но думаю так вполне можно.

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

В общем, я попробую разные варианты, не только третий.

[Germenzi]

Нормальную версию парсера уже залил, карту 100х100 парсит примерно за 360мс. Чтобы понимать разницу, предыдущий с картой 10х10 справлялся примерно за 900мс, в общем теперь все ок.

Что насчет api. Сделать статический класс конечно можно, но это все таки глупость, ведь индексы точек в навигаторе зависят от конкретного тайлмапа, да и мы скорее всего будем обращаться к нему через его локальные координаты, так что отдельно вынести удобный api просто никак, все равно нужен объект HexGrid.

Поэтому я объединил парсер, hex grid и навигатор в один класс. При необходимости, объект Astar2D можно просто достать из тайлмапа как поле.