Когда начать?
Как и любой хороший разработчик, я начал гуглить
Я начал играть с Unity около 2 лет назад, и с самого начала программирование казалось немного странным и неорганизованным.
Я инженер-программист, и разработка программного обеспечения — моя повседневная работа. Я учусь или работаю в этой области уже 8 лет, и когда я начинаю новый проект, первое, что я делаю, это настраиваю архитектуру.
Вот тут-то и возникли проблемы с Unity: я не знал, с чего начать. Как и любой хороший разработчик, я начал гуглить «архитектурные шаблоны Unity» или «как структурировать свой код», но, честно говоря, ни один результат не показался мне достаточно убедительным.
Некоторые говорят, что нужно плыть по течению и принять управляемую компонентами природу Unity, но это может очень легко пойти не так, если у вас нет опыта и ваша игра начинает расти. по размеру. Это, безусловно, самое простое, но если ваша цель — иметь чистый код и возможность повторного использования, это, ИМХО, не тот путь.
А как насчет МВК?
MVC был основным предложением для разработчиков с немного большим опытом, но ни один из примеров не вписывался в мою личную концепцию MVC.
В Unity у вас есть игровые объекты, скрипты MonoBehavior и пользовательские классы. Если мы хотим сопоставить «M»,«V» и «C», я бы выбрал:
- Модель: пользовательские классы, объекты с поддержкой сценариев.
- Просмотр: игровые объекты
- Контроллер: моноповедение и другие компоненты объекта
Пример
В моей RPG я хочу добавить некоторую информацию о мече, и я хочу, чтобы он поднимался, когда игрок приближается к нему.
Представление будет игровым объектом в сцене (или префабом, если хотите), моделью будет сериализуемый объектный класс SwordModel. Контроллер может быть этим MonoBehavior.
Когда игра начнет усложняться, код будет медленно трансформироваться в 🍝
Хотя это выглядит чисто, мне не нравится, что взаимодействие между контроллером и представлением находится в том же месте, что и игровая логика. Если ваша игровая логика проста, это может быть хорошо, но когда игра начнет усложняться, код будет медленно трансформироваться в🍝.
Что я хотел в своей игре, так это способ разделить их.
Входит в шаблон MVCM!
Ммодель Ввид КонтроллерМоно
Моя идея состоит в том, чтобы делегировать скрипту MonoBehavior (для краткости моно) только взаимодействие с игровым объектом, к которому он привязан: установка преобразования, установка спрайта, взаимодействие с другими компонентами объекта (жесткое тело, коллайдер и т. д.).
Контроллер должен исключительно обрабатывать игровую логику
Затем моно подключается к контроллеру, который отвечает исключительно за игровую логику. Несколько примеров игровой логики: гоблин попадает в 40% случаев, стрела меняет скорость в зависимости от уровня игрока, каждый удар мечом снижает ее прочность).
Наконец, контроллер имеет доступ к модели, которая ничем не отличается от стандартной MVC.
Вернемся к нашему примеру Sword
Как и раньше, у нас есть игровой объект SwordModel, прикрепленный к нему скрипт MonoBehaviour и модель. На этот раз у нас также есть скрипт SwordController между Mono и Model.
Это значительно больше кода для нашего простого примера, хотя это позволяет нам отделить часть логики от объектов Unity и, на мой взгляд, позволяет сделать код чище.
Выводы
Если вы читаете это, вы, вероятно, слышали это тысячу раз, но я чувствую, что это нужно повторить:
Выберите архитектуру, которая больше всего подходит для вашего варианта использования.
Такой способ структурирования кода очень помог мне в создании прочной кодовой базы. Хотя я бы не советовал, если вы строите небольшую игру.
Что вы думаете? Вы следуете какой-то определенной схеме? Вам трудно структурировать свой код в Unity?
