Уровень материала: 🐥 #middle
Ранее я писал, что прохожу обучение на курсе от Unity Architect. Недавно была тема, посвященная
MVC. И упор был сделан не на очередной разбор очередной реализации, а на выяснение причин, почему существует такое разнообразие трактовок. Из этого вытекают и некоторые следствия, о которых не часто рассказывают, но которые находят место в практике.Про разнообразие подходов 🛠 :
Причина такого раздрая — «так исторически сложилось». Когда по принципу «глухого телефона» революционный много десятилетий назад подход дошёл до наших современных дней.
Подробнее с этим можно ознакомиться в длинном исследовательском материале из двух частей на Хабре 📝: #1 и #2. Текст объёмный и сложный. Но увлекательный. Для вдумчивого чтения (а иначе смысла нет) стоит заложить на обе статьи где-то 1 час.
А один из примеров реализации в геймдеве я шарил в этом посте 💬
Следствие 1️⃣:
MVC — это изначально история про взаимодействие с пользователем. Т. е. про UI. Соответственно, попытки затащить это в геймплей сделают из MVC не MVC (и даже не обязательно какой-то MVx). Т. к. для удобства использования в геймплее эту штуку приходится адаптировать.Следствие 2️⃣:
Как бы ни был «приготовлен»
MVC, кто-то обязательно скажет, что это неправильно. Или это не MVC, а какой-нибудь другой MVx. Это бесконечные бессмысленные споры, стоящие на противоречивых источниках.Чтобы не маячить красным платком перед «искушённой» публикой, можно отойти от общеизвестного нейминга. Соблюсти идею разделения визуала и бизнес-логики, но назвать это иначе. Особенно легко это делается в геймплее.
Ведь задача — спроектировать всё хорошо, а не сдать экзамен по «эталонному соответствию канонам». Тогда на нападки в виде «но в MVx же...» можно отвечать «а это не MVx».
Следствие 3️⃣:
Эталонно
View и Controller находятся на одном слое взаимодействия с пользователем. И в современных системах, где нет низкоуровневого кода по непосредственно рендерингу и обработке ввода, контроллер как-таковой не шибко нужен. Поэтому достаточно использовать только Model и View.В качестве
Model можно подготовить специальную прослойку, типа Facade, Adapter или Mediator, которая будет агрегировать внутри всю коммуникацию с необходимыми игровыми моделями и сервисами. Например, нажалась кнопочка, медиатор из
WalletModel снял монетки, в StorageModel положил конфетки, а у AdService запросил показ InterstitialAd.В свою очередь
View будет отвечать за всю логику представления (кнопочки, формочки, генерация карточек, анимации прокрутки, заполнение прогресс-баров и пр.) и передачу событий в Mediator.Связку из
View и Mediator я и в своей команде использую уже очень давно — это отлично себя показывает в проектах разных масштабов. На каком-то из стримов K-Syndicate оговаривались, что используют двухуровневый шаблон и связующий слой тоже называют
Mediator. Не нашёл, на каком именно, но у них был большой классный стрим по MVx в целом 📺upd: поступило полезное дополнение со стримом от K-Syndicate про UI без MVx — там рассматривается
Mediator, немножко в другой роли, но это тоже даёт полезный взгляд на проблему игрового UI.————————————
#unity #gamedev #development #architecture #mvc #mvx #геймдев #разработка #архитектура #рекомендация #статья #видео