Тайлы с атрибутами

Коллеги, нужна помощь, но скорее в алгоритме, нежели в программировании.
Дано: Пишу игровой движок, где все графика состоит из сетки, каждая ячейка это свой тайл - картинка в виде песка, горы, травы, воды и т.д. По ней перемещаются объекты - танки, машины, солдаты...
Задача: Как реализовать атрибуты в каждой из клеток? ну то есть чтобы можно было задавать, можно ли вступать на клетку или нет, можно ли строить и т.п.

пример на картинке: разные тайлы с разными атрибутами: 1,2,3,4
П.С. заодно пишу редактор карты, где далее дизайнер мог бы не просто нарисовать карту из тайлов, но и выставить атрибуты.

Спасибо.

0

Сообщение от Russel327 Задача: Как реализовать атрибуты в каждой из клеток? ну то есть чтобы можно было задавать, можно ли вступать на клетку или нет, можно ли строить и т.п.

Если это тайлсет, то побитово на каждый тайл. Грубо говоря каждый тайл должен
соответствовать например машинному слову (если вам хватит битов на каждое свойство).
Если свойству нужно больше бита, то просто выделяем нужное кол-во бит в структуре под него.
При загрузке в карту соотв. тайлам значений, это должно быть задублировано в структуре
карты, не ссылочно, а напрямую. И тут важна одна деталь. В этой UDT первый байт должен
так или иначе указывать на наличие юнита в этой клетке(лучше сразу тип объекта в тайле),
чтобы при его наличии как раз загружать все остальные значения. Эта система абсолютно
рабочая и я могу за это поручиться.

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

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

Если у вас нет ни ТЗ ни документации - будет жопа 100%, документируйте каждую писюльку,
все юниты, каждое свойство, все строения и каждое их свойство, нужно определить взаимодействия
между всеми объектами, взаимодействия с тайлами карты любого свойства и т.д..
Документированию подлежит абсолютно всё, слои карты. Причём желательно избегать сложных
словесных оборотов, допустим если харвестер собирает какой-то ресурс, нужно разбить его
действия на однотипные (event 1: стоит ждёт, event 2: тип движение\подтип поворот,
event 3: тип движение\подтип движение, event 4: сбор ресурса, event 5: указание на поиск маршрута и т.д.)
Это всё очень утрированно, название этому - каскадная триггерная логика, программируется непросто,
но по итогу конечно фигня(не работа, а пушечное мясо), основной завтык гарантированно будет в другом.
Думаю вы догадываетесь где.

Сообщение от Russel327 Пишу игровой движок

На каком ЯП? И размер карты? Сразу скажу возможно это в принципе или нет.

0

Quiet Snow, пишу, к бы ни странно, на qb64. Спасибо за ответ. Постараюсь вникнуть

0

как-то компилировал helloword в qb64. выяснилось, что процесс поджирает память. то ли утечка, то ли. троян, то ли еще что-то. забраковал и удалил и никому не советую

0

Quiet Snow, хотя, зачем я пытаюсь делать вид, что что-нибудь понял. Ничего не понял ((

0

Сообщение от Russel327 Quiet Snow, пишу, к бы ни странно, на qb64

RTS, RPG? Что есть из написанного? Аналог чего предполагается? Размер карты не просто так спросил.

В своё время много лет потратил на реверс D2K. Потом просто собрал все наработки в редактор
и ещё несколько утилит. Человеку(проф. тестировщику), который занимался картами редактор
понравился(он в общем то и формировал требования), карт где-то 30 он на нём сделал, сам я
им пользовался только для редактирования ресурсов карты, на FED2K до сих пор нет ничего подобного,
единственные люди, которые смогли осилить полный рендер карты - OpenRA, но двиг там печальный(кстати
на .NET с соотв. тормозами , оригинал напомню отлично работал на 200-х MMX-ах).
У амеров крупное, гордое и слепое(сильное и независимое) коммьюнити. Хотя надо отдать должное,
MVI - монстр и ещё один чел умудрился генератор карт написать, хуже по алгоритму чем я предположил,
но написал, всё равно красавец, я этот алгоритм отмёл сразу, а более кошерный не осилил(здоровье
просело и бросил), там была недетерминировщина и неподъёмное кол-во аналитики.
Ещё было дофига разных тулз, и формировщик тайлблоков, редактор тайлатров, генератор концептов карт,
редактор смещений юнитов(для центровки), скриншотер карт и что-то ещё по мелочи писал консольное
по ТЗ, когда коллеге ещё всё это было интересно. Редактор смещений недавно одному челу переделал
в редактор анимации по запросу, не за так конечно))) У него свой проект на Unity, а сообщество D2K
к сожалению сдохло в 2009-2011-х когда разбежался duneforum. 245 билдов D2K Hardcore сделали,
с 2009 года как раз, 9 лет считай.
Так весело конечвно было. Сейчас уже этим не занимаюсь(другие задачи), надо будет оформить
несколько утилит, выложить и больше не возвращаться к этой теме. Но если есть конкретные вопросы
спрашивай. Не то что прям чем-то сильно смогу помочь, но если будет не трудоёмко направлю в нужное
русло. Всё таки один человек - мало для таких дел, это говорю без всяких понтов и приколов.

0

Если в вашем языке поддерживаются перечисления, то можно сделать так:

И так далее.

Теперь в самом тайле нужно указать его тип:

Сами тайлы можно хранить в виде массива:


Если не поддерживаются, то в структуре Tile для поля TileType указываете тип данных Integer.

(Код указан для FreeBASIC)

1

Спасибо! а вывод на экран? или можно я вам в личку напишу насчет этого?

0

Выбирайте нужный тип квадратика и рисуйте:

1

Сообщение от Замабувараев Выбирайте нужный тип квадратика и рисуйте

Тип тайла нужен не для того, чтобы рисовать каждый отдельно. Для отрисовки это не важно,
это важно для движения объектов по карте и учёта при расстановки объектов в редакторе.
Потому что тайлов в тайлсете может быть под тысячу, документировать каждый - это жесть,
они выводятся в двойном цикле просто из массива карты. Вшивать каждый в код - означает
ограничить последующее создание тайлсетов. Ограничения нужны только частичные в местах,
где стопроцентно должно быть что-то одно и работать одинаково(например сам добываемый
ресурс или иные специфические вещи), а также слои FOW.
И например TileTypes.Ground-ом может быть(обычно так и есть) вполне не один тайл.
Ограничивать же определённым количеством и тем паче конкретной областью простой "пейзаж"
смысла нет, для целей определения этих параметров используют т.н. тайлатры(отдельные файлы,
либо зашиваемые в сам файл тайлсета - атрибуты, по которым программа сможет понять что
это конкретно за тайл и каковы его свойства, куда его можно поставить и что по нему может
бегать и ездить).
Отрисовка это чаще процедура DrawMap, которая выводит несколько слоёв спрайтов.
Предварительно рассчитав границы. И тут есть два варианта, делать клиппинг и не делать,
если мы работаем без внутриэкранного клиппинга, тогда по бокам ставятся бордюры
шириной с тайл(которые могут быть заменены чем-то, что рисуется сверху, например
элементами интерфейса), иначе же либо ставиться хардварное отсечение, либо рендер идёт
непосредственно в спрайт. Каждый вариант - это разные вычисления.

1