Unity Как сделать расширяемую архитектуру fps character

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Привет Хабр

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

Статья не несет рекомендаций. В данной статье не будет кода!


На данный момент персонаж имеет следующие механики:

Движение;

Прыжок;

Взбирание по лестнице;

Получение урона;

Вращение камеры игрока.

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

Далее реализуем прыжок. И тут появляется зависимость. Прыжок можно будет совершить много раз. Чтобы этого не было, можно реализовать логику проверки на землю.

Её можно реализовать в скрипте Jump. Что не очень хорошо. Поэтому снова создаем новый компонент (скрипт) Ground. Скрипт получения урона и вращения камеры так же создаем отдельно.

Далее идет логика взбирания по лестнице. Снова возникает проблема. Вовремя взбирания по лестнице мы не должны иметь возможность прыгать и двигаться влево вправо. А движение вперёд-назад должно поменяться на движение вверх-вниз.

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

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

Если ни чего больше не добавлять, тогда всё будет работать хорошо, а архитектура выглядит просто и понятно.

И всё-таки

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

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

Идея данной архитектуры следующая.  Так как в Unity на объекте игрок, на данный момент есть много скриптов, которые содержат только логику без вызова, (это всё кроме playerMovement) я решил углубить их. А на поверхности оставить только скрипты инициализации игрока, расчета логики и реализации самих действий.

Теперь она выглядит следующим образом.

Entry Point Точка входа, для сохранения порядка: сбора компонентов, создание сущностей и их инициализации.

Player model хранит всё данные в одном места для удобства их изменения в Unity.

Player Update выполняет всё расчеты

Player Late Update выполняет действия по типу повернуть камеру, переместить игрока.

Player Take Damage отвечает за получаемый урон. Он реализует интерфейс нанесения урона.

Скриптов после такой реконструкции стало раза в 2 больше. А с точки зрения логики ни чего нового не появилось. Пока я только создал пустые классы и потихоньку начинаю их связывать. Параллельно смотрю о возможных проблемах в будущем:

  • Update и Late Update разрастутся до 100 и более строк. На данный момент они содержат меньше 50 строк.  Какие выходы я здесь вижу:

    1. В последствии делить Update и late Update. Что в результате опять создаст кучу скриптов компонентов на объекте в Unity.

    2. Выделять новые сущности в Update и late Update.

  • В Unity теперь всё выглядит довольно легко и просто. А вот внутри появилось много скриптов прослоек. Что мешает увидеть саму логику движения, например. С этим скорее всего я ничего не смогу сделать.

  • Так же возникает проблема вызова логик. Пока, я сделал скрипт Components, который собирает ссылки на созданные скрипты(компоненты), а затем через Components вызываю необходимые компоненты. Что означает, то что он тоже будет в будущем раздут. Пример на скриншоте. Решение такое же, что для Update и Late Update. Делить скрипт на составляющие.

Итог

Пока буду продолжать реализовать этот вариант архитектуры. А может найду какое другое решение.

Источник: https://habr.com/ru/articles/746404/


Интересные статьи

Интересные статьи

Представьте задачу, что вам нужно изменять состояние однотипных компонентов, затрагивающих только один из них. Нечто очень похожее можно реализовать с использованием контекста React. Но в этом случае ...
Мы продолжаем цикл статей про безболезненный переход на UNIGINE с зарубежных движков: в третьем выпуске рассмотрим миграцию с Unity с точки зрения программиста.Под катом: написание игровой логики, зап...
Всем привет. Сегодня публикуем вторую часть текстовой расшифровки интенсива, который был проведен в преддверии старта курса "Game QA Engineer. С первой частью можно ознакомиться по ссылке.Интенсив про...
И ещё четыре инсайта от человека, который больше 17 лет мыслит с помощью блога в ЖЖ и благодаря этому получает феноменальные результаты. Читать далее ...
Привет всем! На связи Дима, бэкенд разработчик, который недавно обнаружил, что его резюме больше не работает и доллáры перестали литься рекой на банковский счет. Каким-то загадочн...