Продолжим разбор архитектурных вопросов

Дисклеймер:
Придется потерпеть скучные и местами рваные кусочки информации, потому что я решил собрать всё в кучу, но сделать это постепенно, отслеживая фидбек, чтобы не отойти в сторону. Потом это всё соберется в отдельную видео-лекцию. За вопросы всем заранее спасибо!

Наверное, про игровое состояние знают все (если не все - отпишитесь, в комментах, плез). Но вот что точно знают не все, так это то, как оно должно меняться, чтобы было не больно. Для того, чтобы все работало хорошо, стабильно и легко расширяемо и изменяемо, реализуем тот самый принцип единой ответственности (да, тот что из SOLID).

1. Существуют классы, которые знают КАК менять данные. Знают, потому что вы их написали, конечно. Их называют обработчики данных. На скринах можно увидеть пример обработки добавления предмета в инвентарь. Отдельный класс, он умеет только добавлять предмет в инвентарь и возвращать ответ, на этом всё. Это вынесенно намеренно в отдельный класс, чтобы в случае резкого изменения механики добавления просто выбросить этот класс и написать новый без поисков откуда ноги растут. Если при добавлении предмета что-то работает не так - знаем где искать.

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

На скринах показана связка, для чего нужен сервис и как он взаимодействует с данными (через посредника - обработчика данных). Это, наверное, базовая база. MVVM, MVP, MVC, независимо от выбранной базы архитектуры, связка сервис - обработчик данных останется прежней. Если упороться, можно и в ECS применять, но там это излишне, ECS немного по-другому работает,

Еще одна схемка, очень надеюсь, что понятная для тех, кто слышал слово 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, он автоматически меняется и в мире, т.к. биндеры подписаны на одну и ту же модель

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