Архитектура MV* используется для разделения логики персонажей?
В качестве хобби и саморазвития занимаюсь написанием игровых механик на юнити. Попробовал всем известную компонентную систему юнити с монобехами. Часть компонентов отвязал от монобеха и сложил в отдельный объект контейнер компонентов, но без монобехов.
Иногда встречаю высказывания, что всю логику хорошо бы делить еще и по MVC/MVP и т.д. И для UI таких примеров много. Но говорят, что и логику, например, для персонажа, можно переписать с использованием MV* паттернов. Вроде бы особенно часто это используют в сетевых проектах, чтобы отделить визуал от бизнес логики. И вот тут у меня прям проблема - я не понимаю как это сделать. Игровой персонаж - сложная сущность состоящая из многих компонентов. И эти компоненты так или иначе связаны между собой. Если каждый из них еще поделить на Модель/Вью/Презентер... то как связать эти компоненты, ну например, модель компонента Здоровье и Смерть? И как их хранить? Раньше все хранилось в одной коллекции, так сказать в куче... Нужен совсем другой подход. Можете посоветовать примеры таких реализаций?
P.S.: Возможно все компоненты в MVP нужно инициализировать в Main скрипте, точке входа для персонажа? И там же пробрасывать зависимости тем самым делая связи между компонентами...
Иногда встречаю высказывания, что всю логику хорошо бы делить еще и по MVC/MVP
И почти всегда такие высказывания делают люди, которые этот мвх только на юи примерах видели.
Не нужно использовать мвх для логики игры, ничего, кроме разделения одной/двух сущностей на 3 оно не делает. Использование его приводит только к запутанности кода, когда логика одной сущности раскидана по нескольким классам и один из этих классов существует только, чтобы связать между собой другие.
Мвх может быть полезен для юи и то в очень редких случаях, в остальном это написание кода ради написания кода.
Если ты хочешь свой проект на юнитевских компонентах переделать в мвх, то проще будет создать новый проект и изначально писать его на мвх. Можешь попробовать, чтобы понять насколько это абсурдный паттерн.
Я попробовал на новом проекте, и пока действительно получается довольно сложно запутанная бизнес логика. Не всем компонентам нужно все три части из MVP, но все равно кода намного больше и он какой то запутанный. Возможно я неправильно делаю, но к сожалению, примеров, я так и не нашел. Максимум что нашел - пример с компонентом Здоровье и то, он сам по себе, без связки с другими возможными компонентами сущности. А сущности у нас обычно состоят из многих компонентов... тот же самый игрок, или NPC.
Но я надеюсь все таки встретить пример проекта, или доклад, который хоть чуть прольет свет на этот вариант организации кода... почему то ж об этом говорят. Хотя бы ради интереса и общего развития. На данный момент есть цикл видео на ютюб канале "Лавка разработчика". Он использует MVVM... Вроде он сказал, что действительно, в одном из следующих видео, будет разделять и игровые объекты на MVVM компоненты. Посмотрим.
Николай Егоров, можешь декомпилировать(открыть в райдере/вижуал студио Assembly-CSharp.dll, которая находится в папке Game_Data/Managed) игры от Owlcat Games (pathfinder, wh rogue trader), там какой-то из мвх паттернов используется для юи.
А сущности у нас обычно состоят из многих компонентов... тот же самый игрок, или NPC
С мвх компонентный подход, когда на одном геймобжекте висит 20 компонентов несовместим в принципе. Будет еще больше ненужного кода, который ничего не делает, а существует просто для связи одного с другим. Делай один компонент для игрока и в него пхай все, что относится к игроку. Если хочешь вынести что-то в отдельный компонент, просто выноси это в отдельный класс и пхай его в сущность, соответственно, этому классу не нужно плодить контроллеры, вью и т.п. И будет тогда, условно, Player, PlayerView, PlayerController, гораздо меньше бесполезного говнокода.
Простой
