Создание стен в играх на основе плитки: чего мне не хватает?

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

Важно: персонаж МОЖЕТ стоять на плитке со стенами независимо от их формы.

Общее для всех трех вариантов: карта тайлов будет «храниться» в одномерном контейнере на основе std :: vector (или аналогичного). Причины этого (удивительно) объясняются в ответах на другой вопрос.

Контейнерные классы в играх на основе тайлов.

Вернуться к стенам.

А) Простой подход.

Здесь нет ничего особенного. Каждый контейнер-мозаика может содержать не только символы, но и один или несколько объектов стены, которые прикреплены к краю внутри плитки.

Плюсы: простота реализации, ничего не менять в двигателе. Минусы: две вещи. Один - это может быть только у меня в голове, но некоторые комбинации выглядят просто безобразно. Второе - такой подход позволяет сделать двойную стену из двух соседних плиток. Строительство будет важной частью игры, а двойные стены позволяют строителям, возможно, отказаться от улучшения материала стен с помощью игровых средств и просто добиться увеличения срока службы за счет удвоения существующей стены. Это не желательно. Конечно, я мог бы включить процедуру, которая запрещает двойное ограждение, но к нему будет плохо относиться.

Б) Умный (?) Подход.

Вместо того, чтобы дать игрокам двойную стенку всей карты, я собираюсь победить их. Каждая стена имеет две половинки, которые прикреплены к краю плитки изнутри. Таким образом, чтобы создать единый «Стенной блок», мне нужно создать два объекта Half-Wall в двух смежных плитках.

Плюсы: это симметрично !!! Кроме того, не требуется значительного изменения текущих характеристик двигателя. Минусы: больше хлопот, больше предметов и, конечно же, «шапки». Как вы можете видеть на картинке, угол в основном будет плакать за объект «шапка». Я на самом деле круто с этим, это не так сложно добавить. Привет, у меня уже есть план для тонких колонн, сделанных из четырех соединенных колпачков. Милая. Тем не менее, у меня есть некоторые опасения по поводу возможных проблем поля зрения и прямой видимости.

В) вариант капитального ремонта.

Или я мог бы просто создать границы и углы как отдельные контейнеры для игровых объектов. Просто так.

Плюсы: даже не уверен. Ну, это просто. Определенно. Минусы: это потребует капитального ремонта. К счастью, не кода, а менталитета игровой механики - это точно. Преимущества не так очевидны. Кроме того, этот подход требует гораздо больше контейнеров, чем два предыдущих. Индексирование математики также будет немного болезненным.

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

Я бы использовал ваш метод "B".

Чтобы избежать необходимости использования «колпачков», просто вытяните каждую стенку «на 1/2 толщины стенки» в обоих направлениях. Это создаст перекрывающиеся стены там, где они встречаются, но ваши диаграммы уже показывают, что это не проблема.

Таким образом, в методе «B», рис. 3, горизонтальная стена будет немного расширяться влево, а вертикальная стена будет немного расширяться.

[Я новичок здесь, только что зарегистрировался. Я что-то упустил, так как не вижу кнопку «Добавить комментарий» в исходном сообщении. Это привилегия людей с более высокой репутацией? Или я упускаю из виду очевидное? Извините, что добавил это как «ответ».]

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

Плюсы: Расчеты и размещения тривиальны, столкновения тривиальны, где все расчеты и столкновения основаны только на координатах размещения стен.

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

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

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

Извините, но третий способ - это способ думать, ну, у вас уже есть возможность сделать это, так что давайте двигаться дальше и думать о двух других!

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

Похоже, это 2D-игра сверху вниз, где стены имеют «ширину», поэтому им нужен этот угол (ваш объект «шапка»). Это исключительно «графика», поэтому я бы остановился на некотором:

2D-карта с плитками (т.е. тип плитки и т. Д.).

2D карта с 2 стенами, напр. снизу и справа (левая стена будет «правой стеной» в плитке слева от этой).

+ Логика, которая рисует все стены и «шапки» и т. д.

Таким образом, разделяя логику и графику. Вы можете сделать «интерфейс», заботящийся о таких вещах, как SetWall (ThisTile, LEFT, NOWALL) -> установить правую стену плитки слева от ThisTile на «NOWALL» ...

Может быть, это кажется размытым, но дело в том, что вы всегда должны пытаться иметь с одной стороны логику (фактические данные, без избыточности), а с другой стороны - «рисование данных», которое вычисляет, есть ли необходимость в «ограничении» ' так далее.

++