Путешествуйте с одного уровня на другой

Цели

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

Как я собираюсь это сделать?

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

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

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

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

Для простоты я попробую сгенерировать все уровни в начале игры и сохранить где-нибудь в памяти. Даже в конце игры я не думаю, что игрок будет иметь дело с более чем ~ 40 уровнями за проход, поэтому пока я просто сохраню уровни, указанные в каком-то объекте, и когда игрок перейдет на новый уровень if поместит модель нового уровня в ссылку на модель, используемую для всех остальных механик.

Прежде всего, давайте создадим несколько спрайтов-заполнителей.

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

И вот так. наверху то же самое, только перевернутый по горизонтали.

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

если вы боретесь с фреймворком, фреймворк обычно побеждает

Поговорим о моем системном дизайне. Я нарисовал диаграмму, более или менее показывающую, как моя игра работает до сих пор.

У меня есть эти 4 менеджера, которые хранят определенные вещи в памяти и ссылаются на префабы, создают экземпляры объектов и вызывают методы в других модулях, а также делают всевозможные вещи.

С такой скоростью моя игра быстро превратится в хаотичную сеть ссылок.

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

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

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

Я изменил всю свою систему, чтобы она больше соответствовала этим принципам.

Я избавлю вас от подробностей и покажу схему моей новой системы.

Обобщить; Мой менеджер сетки теперь создает объект уровня. Каждой генерируемой плитке он присваивает свой уровень. Каждый объект уровня является непосредственным родителем всего в нем.

У каждого объекта также есть скрипт props, который просто отслеживает некоторые переменные, которые мне нужны. Большинство реквизитов моих сборных элементов просто отслеживают свое положение в модели, но реквизиты персонажей и уровней немного толще. У каждого уровня также есть своя модель level_model и свои тайлы вверх и вниз (так как они особенные).

Каждая плитка вверх и вниз отслеживает уровень, на который она выплевывается.

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

Я удалил своего боевого менеджера, и мой персонаж справился с этим, так как это были ненужные сложности.

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

Это огромное улучшение, и это необходимо сделать.

Теперь, когда рефакторинг завершен, вернемся к уровню перехода.

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

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

Я закодировал это, и вот оно в действии:

Я очень доволен дизайном и рефакторингом, потому что это позволит мне загружать сразу несколько уровней и изменять их состояние, даже когда игрок не находится на уровне (например, когда монстры перемещаются)

До скорого.