Изометрический движок своими руками
 

Настала необходимость обзавестись изометрическим движком, и вот, решила написать его самостоятельно.
Но тему завела уже не с пустыми руками:
http://mydemy.narod.ru/zfw_iso/index.html
Сейчас дело обстоит так (там кстати есть два бага).

То есть движок сейчас - гексагональный и изометрический.
Формулы писала сама. Отсюда и сомнения...
(картинки стырены, но ничего коммерческого или хоть немного официального я с ними делать не буду,
как сделаю замену - сотру со всех локальных папок :))
Алгоритм просчета пути - А*.

Сцена грузится следующим образом.
Создаются слои (спрайты, возможно, уместнее было бы использовать другие объекты из ветки DisplayObject):
- некликабельный, для загрузки фона,
- слой с объектами
На слой с объектами крепятся "гексы" - это пустые спрайты (см. выше), размещенные на точке (0,0).
Почему на начале координат?
Ну, я уже было написала алгоритм сортировки, но задумалась, а почему бы не сделать ячейки-гексы, отсортированные, как надо, на которые мы будем крепить объекты, соответственно, автоматически находящие свое место в сортировке. (Если криво объяснила, могу переформулировать)
Реальные координаты объекта высчитываются отдельно, и спрайт вставляется в гекс с ними (ведь 0 + координата = координата).
Сейчас я вижу проблему этого подхода... Но пока не решилась возвращать сортировку.

Еще я засомневалась и насчет гексов... Первая проблема на данный момент (помимо багов, которые просто не пофиксены в этой версии) - нормальный просчет гекса, на который кликнули. Нет, ну я даже высчитала формулы прямых, образовывающих верхний и нижний углы гекса. Исходя из этого, мы можем высчитать, лежат ли (mouseX, mouseY) выше/ниже, и, соответственно, более точно рассчитать, по какому гексу кликнули мышкой... Но что-то многовато действий, для простой проверки клика...
Почему я вообще выбрала гексы? Ну, они необычные... Да, при движении вертикально вверх, персонаж люто, простите, "виляет попой". Но направления движения в остальном какие-то... естественные, и все не такое рубленное, что ли. Может, это просто мой женский мозг взбунтовался против очевидно более простого решения...
А еще гексами можно образовать сетку, не наклоненную под углом 45 градусов, а прямоугольную, как сам экран. И не надо придумывать, чем занимать углы, или как объяснять "туман войны".

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

У меня было так: Был класс "арена" расширяющий Sprite, на нем . К классу "Арена" подвязываешь и если в процедуре тип таргета равен типу ячейки - значит в таргете (не в курент_таргете) твоя ячейка.

Не поделишься строчками, как ты двигаешь мобов с А*?

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

Я бы делал на ромбах. Гексы неудобны для подготовки графики ну и вообще не люблю я их)
Вот тут старый список готовых движков.

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

За ссылку спасибо. Большинство из них смотрела уже не по разу, но как-то не нашла ничего по душе

Возможно ли использовать ваш движок на условиях Royalty Free с обязательным указанием источника/автора (переходом по ссылке)?

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

При таком подходе у вас будут приличные проблемы с производительностью, как только количество объектов станет хоть сколько-нибудь значимым. И решить их при такой архитектуре будет проблематично. Я бы отделил отображение карты от расчетов и сортировок и не зацикливался на DisplayObject.
Не обязательно ходить строго по хексам (если это не обусловлено геймплеем), главное придти из точки A в точку B.

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

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

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