2015-07-20 7 views
0

Я пытаюсь создать изометрический редактор ландшафта. Моя проблема не в том, чтобы делать изометрическую графику или рендеринг, а это связано с индексацией плиток.Изометрическая местность

Предположим, что я делаю холм на плитки (10,5). Это будет означать, что плитка (10,5) будет иметь тип corner_1, плитка (11,5) будет corner_2, плитка (10,6) будет corner_3, а плитка (11,6) будет равна corner_4. Это создаст пик в середине четырех фрагментов.

На первый взгляд кажется простым, но есть так много возможностей. Если у нас есть два холма, которые пересекают друг друга, нам нужны перевернутые угловые плитки. Если бы у нас была диагональная гора, окружающие плитки нужно было бы превратить в диагональные перевернутые угловые плитки. Я уже создал большинство изображений для плитки http://opengameart.org/content/simple-iso-city-work-in-progress. Мой вопрос в том, есть ли уже набор «правил», за которыми я могу следить за тем, как ландшафт изменяет себя вокруг окружающего ландшафта? Или мне нужно самому разобрать каждую комбинацию плиток?

+0

рассмотрите вопрос о том, как http://gamedev.stackexchange.com/ его stackoverflow специально для игры dev. –

+0

@Ness Хорошо, спасибо. –

+0

Я бы создал ваш холм (выровненный с ячейками 'm'x'n' как карта вокселей и получающий/отрисовку плиток прямо из него. Трудно продумать все комбинации таким образом, чтобы у вас было достаточно плиток для управления гладким холмом или переход определенным образом не беспокоят всех комбинаций, набор плиток будет огромным, а пользователь недружелюбен. – Spektre

ответ

0

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

Скажем, у вас есть 4 соседи и два типа плитки (0 и 1), тогда число комбинаций равно 16: каждая соседняя ячейка может иметь либо тот же тип поля, что и центральный (тип 1), или другой тип (0).

 
Center type | north | east | west | east 
    1  | 0 | 0 | 0 | 0 
    1  | 1 | 0 | 0 | 0 
    1  | 0 | 1 | 0 | 0 
    1  | 1 | 1 | 0 | 0 
    1  | 0 | 0 | 1 | 0 
(...) 
    1  | 0 | 0 | 1 | 1 
    1  | 1 | 0 | 1 | 1 
    1  | 0 | 1 | 1 | 1 
    1  | 1 | 1 | 1 | 1 

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

Если у вас больше типов плитки для объединения (пустыня/трава/камень), количество комбинаций тогда (количество типов)^(соседний счет), поэтому для 3 типов плитки и четырех соседних ячеек вы будете имеют 3 * 3 * 3 * 3 = 81 случай. Если у вас разные уровни высоты (скажем, 2), вы в основном удвоите количество типов, поэтому это будет 6 * 6 * 6 * 6 = 1296.

Вы, вероятно, не хотите этого делать (вручную). Вы можете подумать о моделировании и текстурировании плиток в 3d и визуализировать их на атласе и сделать некоторую фильтрацию постэффектов (цветовая палитра) для стиля вашей игры. Объем данных не так уж плох для такой пиксельной игры. Текстура будет довольно огромной, но я считаю, что игры от ~ 2000 действительно делали это время от времени. (Если размер вашей плитки составляет 32x24 и у вас 1296 плиток, вам понадобится около миллиона пикселей для пространства, которое может содержать до 1024x1024 текстуры).