Pull to refresh

Comments 13

Главный минус квадратных тайлов вылезает когда начинаешь их использовать в пошаговом режиме. Кол-во ходов до угла занимает в два раза больше чем до боковой границы. Но если разрешить диагональное перемещение, то наоборот, занимает столько же ходов сколько и до границы. В этом плане шестиугольная сетка более сбалансирована.

В D&D 3.5e, кажется, сетка на поле была квадратной, а перемещение в рамках хода считалось по евклидовой геометрии. То есть по диагонали — 1.41 возможных перемещений за ход, три клетки вперёд и две влево — sqrt(3+2) очков перемещений, а в полёте нужна ещё и вертикальная составляющая.


В шестиугольную играть проще и интереснее всего этого матана, да. :)

Достаточно принять стоимость движения не 1, а 2, тогда по диагонали будет 3 — проблема решена, причем количество направлений 8 — больше чем у хексов и нет зигзагов при движении по одной из перпендикулярных осей.

Это проблема при перемещении на одну клетку за ход.


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

у шестиугольной проблемы с архитектурой. Здание на квадратные клетки ложится лучше. Представьте что будет на шестиугольной сетке, если попытаться спрятаться за косяком двери.
ИМХО наилучшее решение квадратная сетка, но перемещения считать от начальной до конечной клетки, а не последовательно между всеми клетками.(ну и включая промежуточные клетки когда это нужно для обхода препятствий) Примерно так, как сделано на боевой карте MoO2. Или новых(2012+) игр серии x-com.

А как сделать цилиндрическую проекцию как в civ2, может напишете такую статью? Очень интересно как такое делается.

Единственное что для этого надо сделать — это соединить начало и конец карты, т.е. сделать доступным переход из крайней точки в нулевую. А текстуру карты зациклить при ее перемещении.

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

А зачем рисовать тайлы через код именно в Godot, если уже есть готовые инструменты?
Тем более, что такой подход усложняет жизнь получение коллизий.

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

Кстати, в статье не упомянут Tiled Map Editor — крайне полезный инструмент рисования карт как в изометрии, так и плоских.

Нет, этот код на гитхаб не загружал, не посчитал, так сказать, достойным :)

Sign up to leave a comment.

Articles