Изометрическая местность

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

Допустим, я делаю холм на плитке (10,5). Это будет означать, что плитка (10,5) будет иметь тип угла_1, плитка (11,5) будет иметь тип угла_2, плитка (10,6) будет иметь тип угла_3, а плитка (11,6) будет иметь тип угла_4. Это создаст пик в середине четырех плиток.

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


person Michael Borrego    schedule 20.07.2015    source источник
comment
рассмотрите возможность задать здесь gamedev.stackexchange.com его stackoverflow специально для разработчиков игр.   -  person Ronen Ness    schedule 20.07.2015
comment
Я бы создал ваш холм (выровненный по ячейкам mxn в виде воксельной карты и получил/отрисовал плитки непосредственно из нее. Трудно продумать все комбинации таким образом, чтобы у вас было достаточно плиток для управления плавным холмом или переходом определенным образом. не беспокойтесь обо всех комбинациях, набор плиток будет огромным и неудобным для пользователя.   -  person Spektre    schedule 05.04.2016


Ответы (1)


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

Допустим, у вас есть 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).

person Eike Decker    schedule 29.10.2015