Помогите с созданием прототипа плиточного мира

[Котяра]

В том то и дело, что вы подготовили картинки не в ромбовидной форме.
как вы будете создавать анимированного персонажа? домик? деревце?
Я написал выше, что использовать 3D только для изометрии - бредовая идея.
Альтернативщики, кстати, так и начинали) Где изометрическая игра? Есть только 3D движок - хороший, но изначально цель была несколько другая..

[AlexDesinger]

как вы будете создавать анимированного персонажа? домик? деревце?
Я написал выше, что использовать 3D только для изометрии - бредовая идея.

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

[denver]

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

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

Предусловия (возможно повторюсь с выше написанными постами):
1. Все объекты на карте таскабелны и кликабельны в любой момент (таскабельность уже реализована в демке приложеной в раннем посте)
2. Статические объекты могут иметь габариты >= 1x1 клетку
3. Свободно гуляющие объекты имеют строгий габарит = 1х1 клетку (для простоты)
4. Плитка с которой связан хотя бы один объект считается занятой/непроходимой
5. У каждого объекта помещаемого на карту есть следующие свойства:
col, row - колонка и строка где находится 0-вая клетка объекта
cols, rows - габариты объекта (например 2 колонки х 1 строка)
6. Игровое поле 20х20 клеток

Мое решение:
1. Инит карты (создание плиточного поля и пр. подготовишки)
2. Добавляем статические объекты (которые не будут двигаться самопроизвольно)
3. Добавляем свободно гуляющие объекты (человечков)
3.1. Создаем человечка (далее Ч)
3.2. Определяем массив свободных плиток
3.3. Рандомно выбираем 2-е свободные плитки как начало (Н) и конец (К) маршрута по которому у нас пойдет Ч
3.4. Связываем Ч с плиткой Н и выводим Ч на экран в сооотв. с коодинатой плитки Н
3.5. По волновому алгоритму определяем путь от плитки Н до плитки К
3.6. Закидываем Ч и путь движения в "твинер" который будет двигать Ч по полю
3.7. goto 3.1.
4. Запускаем "твинер" который двигает человечков по полю.
Для перемещения объектов использовал либу Tweener, которая тупо двигает по x,y.
Предварительно путь у каждого Ч "нормализуется", т.е. выделяются точки пути: начальная, конечная и промежуточные точки где меняется направление
Эта "нормализация" нужна для плавного движения объекта от одной точки маршрута до другой.
"Твинер" после окончания движения формирует новый путь и запускает Ч по новому пути начиная с точки окончания предидущего пути.

Постоянно выполняющиеся циклы:
1. сортировка объектов по глубине (период .5 сек)
2. слежение за x,y-координатами гуляющих Ч для проставления у них свойств col и row (см. Предусловия) (период .5 сек)

Ухх скока буков написал. И так собственно проблема...
Нужно исключить случаи когда путь Ч в один момент времени пересекался бы с путем другого Ч.
По логике когда такое произойдет один из Ч должен обойти другого или у одного из них должен сгенерироваться новый путь начиная с точки "столкновения"
Как то путанно я неверно выразился

[Котяра]

тут у вас понамешано проблем в кучу.
что немного не верно:

1. сортировка объектов по глубине (период .5 сек)
2. слежение за x,y-координатами гуляющих Ч для проставления у них свойств col и row (см. Предусловия) (период .5 сек)

сортировку я бы вынес в метод рендера , причём проводил бы ёё только если положение сортируемых объектов изменилось (x,y - вернее col,row)

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

на самом деле это не самая простая задача - поищите алгоритмы d-star (динамический a*)
можно пойти таким способом:
находим путь от A[0,0] до B[10,10] (массивы клеток) по любому методу поиска пути - я предпочитаю a-star.
в момент движения ( переход из [1,1] в [1,2], например, оцениваем на проходимость клетку [1,2] - если непроходима перестраиваем путь до B c учётом занятой клетки. могут быть проблемы если путь не найден - тогда стоим на месте, но при следующем такте считаем еще раз.

[Adrior]

Кстати, неужели нет готового движка для таких игр? Тот же город во Вконтакте, уверен, слизан откуда-то под чистую.

[denver]

to Котяра

сортировку я бы вынес в метод рендера , причём проводил бы ёё только если положение сортируемых объектов изменилось (x,y - вернее col,row)

т.к. по карте всегда что то движется то рендер получается нужно делать постоянно.

на самом деле это не самая простая задача - поищите алгоритмы d-star (динамический a*)

А чем плох в этом случае волновой алгоритм? Мне кажется по времени поиска волновой ощутимо быстрее и проще в реализации.
В принципе мой вариант

один из Ч должен обойти другого или у одного из них должен сгенерироваться новый путь начиная с точки "столкновения"

похож на твой

оцениваем на проходимость клетку [1,2] - если непроходима перестраиваем путь до B

Добавлено через 2 минуты
to Adrior
Возможно такой движек (бесплатный) и есть, но мне на глаза пока еще не попался.
В общем я хочу его мяса. Если найдешь приглашай на "ужин"

Добавлено через 7 минут
to Котяра
Не встречал ли ты реализацию D*-алгоритма? Думаю стоит попробовать, авось и лучче чем волновой заработает в моём изменяющемся мире

Добавлено через 55 минут
Статистики для....
Замерил время вычисления пути по волновому алгоритму:
кол-во замеров: 83
максимальное время: 731 ms
минимальное: 17 ms
среднее: 75 ms
Основное количество замеров уложилось до 60 ms и лишь всего 5 зашкалило (731, 678, 649, 627, 542)

[Котяра]

Сообщение от denver

т.к. по карте всегда что то движется то рендер получается нужно делать постоянно.

вообще обычно округляют по row/col
т.е. если еще не перешёл в новое состояние row/col - считаем что он не двигался

Сообщение от denver

Статистики для....
Замерил время вычисления пути по волновому алгоритму:

надо с чем-то сравнивать..
вот возьмите, например, готовый a-star example и вставьте в него свой волновой - и сравните..

а вообще задача сильно зависит от ландшафта и динамичности изменения проходимостей.
если стенки небольшие ( не больше 2-3-4-5-.. n клеток) то может подойти поиск по кратчайшему расстоянию с запоминанием некоторого количества предыдущих путей)
т.е. всегда считаем только следующий шаг с учётом текущих проходимостей - можно при критической ситуации (зацикливание пути) вызывать "дорогой" поиск a*.
плюсы: скорость работы, хорошо подходит для динамической карты проходимости - преследования цели, обход других участников движения.
минусы:необходимо вводить критерии критической ситуации, большая зависимость от ландшафта и динамических препятствий - неверный поиск оптимальных путей.
на самом деле не всегда нужен точный путь и часто вполне достаточно направления.

[denver]

Во вложении флешка для сравнения алгоритмов A* и волнового.
При установки флажка "Wave" будет применен волновой.
Где то быстрее A* а где то волновой.
В данном тесте я беру во внимание два типа плиток "wall" и "grass".
Если тип = "grass" то плитка проходима, иначе не проходима.

[denver]

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

[Котяра]

Сообщение от denver

Во вложении флешка для сравнения алгоритмов A* и волнового.
При установки флажка "Wave" будет применен волновой.
Где то быстрее A* а где то волновой.
В данном тесте я беру во внимание два типа плиток "wall" и "grass".
Если тип = "grass" то плитка проходима, иначе не проходима.

Ваш волновой не учитывает диагональные перемещения. а вообще хорошо сделать 100-1000 расчётов пути на один шаг для подсчета времени - точность увеличить.