Еще одна схемка, очень надеюсь, что понятная для тех, кто слышал слово DI или фразу Dependency Injection

На схемке типичная контейнеризация зависимостей, разделенная на разные уровни доступа:

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

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

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

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

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

Продолжаем идти по "кусочкам" архитектурной схемки

Наиболее удобным для управления, расширения, изменения данных способом на моем опыте оказался паттерн команда, используемый через сервисы. В игре существует некий ICommandProcessor, который при старте игры/сцены пичкается набором обработчиков команд. То есть фактически процессор бесконечно расширяемый и не зависит от собственных кишков. Этот процессор раздается всем желающим. И все желающие могут создать команду и послать в процессор для обработки.

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

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

Этим мы уже занимались в #пилимигру, если что. У нас как раз домики так строятся.

Вопросики в комменты, пожалуйста!

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

В посте выше, я уже рассказывал, как устроены взаимосвязи в MVVM. Но то были взаимосвязи "по вертикали", то есть кто кого видит, и за что отвечает. Теперь же нам нужно бы разобраться, как строятся горизонтальные связи. Как условное оружие, которое можно модернизировать отображается и в геймплее и в UI окошке с крафтом, например? Используют ли они одну вьюмодель?

Прежде чем читать далее, небольшой дисклеймер:
1. На схеме выше, а также в проекте #пилимигру мы делаем не бест оф зе бест реализацию MVVM. Потому что идеальная реализация подразумевает то, что баиндеры - это маленькие монобехи цепляющиеся непосредственно к свойствам классов вьюмодели. То есть в редакторе вешаешь баиндер (монобех) на строку, выбираешь вьюмодель к которой цепляешься и реактивное свойство со строкой. Таким образом такой баиндер можно использовать повсюду. Баиндеры могут быть и на спрайты, и на звуки, и ковертеры вроде bool => Sprite, чтобы в зависимости от реактивного свойтсва подставлять нужную картинку и т.д. Этого у нас не будет, но у меня однажды была попытка сделать подобное в ассете Lukomor. Наверное, надо бы его обновить, глядишь, полезным окажется
2. Вьюмодели нужны не для всех объектов в игре. В зависимости от игры, для мировых объектов вьюмодели могут не применяться. Пример: игры вроде Lethal Company, или R.E.P.O. Все объекты с которыми можно взаимодействовать не нуждаются во вьюмоделях, т.к. не содержат необходимости быть соединенными с моделью. Игрок играет сессию, собирает/рушит/перемещает предметы в игре, но это никак не влияет на модель (сами предметы в модели никак не отображаются). Предметы могут нанести урон игроку - но это происходит за счет игрока, соединенного с моделью, а не предметов. Так что не нужно пихать вьюмодели там, где они не нужны.

В остальном, мы получаем некое дерево зависимостей, с входом через 2 точки: для UI и для World, т.е. для мира. Так разделено, потому что UI обычно создается из префаба, а World (то бишь сцена) имеет какие-то заготовки помимо создаваемых объектов. Фабрики вьюмоделей регистрируются в DI контейнере, поэтому в момент входа на сцену после регистрации, мы можем запросить нам выдать корневые вьюмодели - для UI и для World. Тут же в точке входа мы можем вытащить UIRootBinder и WorldRootBinder и выполнить методы Bind(uiRootViewModel) и Bind(worldRootViewModel) на обоих. Каждая вьюмодель может иметь внутри себя ссылки или списки ссылок на другие вьюмодели. Они даже могут пересекаться (несколько вьюмоделей иметь ссылку на одну и ту же модель, см. ViewModel D). Игрок имеет инвентарь, инвентарь имеет ячейку, ячейка имеет предмет - вложенность, я думаю понятна.

Получается каждый баиндер получает свою модель. И (в нашем проекте) каждый баиндер имеет ссылку на вложенные баиндеры. То есть условный баиндер инвентаря имеет ссылку на баиндеры ячеек инвентаря. Баиндер инвентаря получает вьюмодель инвентаря в которой лежит список вьюмоделей ячеек инвентаря. Баиндер инвентаря проходится по этому списку и запихивает каждую вьюмодель ячейки в баиндер ячейки. И так далее. Получается дерево.

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

Как-то так. Похоже, скоро всё соберется в кучку и выдавится в видеоролик.. Вопросы!