Что такое архитектура или 12 Столпов архитектуры Unity проекта

Архитектура игры это очень туманное понятие. Каждый под этим понимает своё.
Я, немного почитав Фаулера, дал бы такое определение:
Архитектура игры - это структура и дизайн разработанного вами проекта, набор ключевых правил и стратегий, которые вы считаете важными в вашем проекте.

Всё ещё довольно туманно? Не беда.

Специально для вас, я выделил конкретные аспекты, которые как кажется мне и моим коллегам юнитологам - являются основными столпами архитектуры Unity проекта.

1) Внедрение зависимостей. Один из самых главных столпов - как классы получают доступ друг к другу? Это могут быть как обычные синглтоны, так и сервис-локатор, так и DI в разном проявлении, будь то Zenject, VContainer или тупое внедрение зависимостей через конструкторы

2) Парадигма программирования. Как у вас происходит взаимодействие между элементами в игре? Может это классический ООП? Может это модифицированный ООП для Unity, называемый компонентно-ориентированным программированием? Или это может быть всеми любимый ECS где объекты вообще не взаимодействуют друг с другом?

3) Представление в игре. То как вы собираетесь описывать, например, сложные UI-окошки или то, разделяете ли вы ваш код на три слоя: данные, вид и логика. Если вы делите код на разные слои, то скорее всего вы выберете MVC, MVP или MVVM, а также их конфигурации.

4) Взаимодействие между классами. Если состояние одного объекта изменилось, как вы уведомляете остальные объекты? Вы вызываете событие ValueChanged? Вы напрямую используете метод OnValueChanged? Или может вы меняете значение свойства или поля? Или может всё сразу?


5) Хранение состояния игры. Если вы закрыли вашу игру, где сохранится текущее состояние вашей игры? Например, количество золота и кристаллов, уровень игрока, его рекорды и тд. На новичковых проектах чаще всего такие данные сохраняют в PlayerPrefs, более серьезные дяди уходят в сторону своих решений который сохраняют либо как зашифрованный JSON, либо отправляют данные на сервер.

6) Хранение конфигов вашей игры. Как вы храните игровой баланс вашей игры? Где вы храните данные о том сколько монстров будет на том или ином уровне? Чаще всего, новички используют ScriptableObjects, но также можно использовать либо эксель таблички, либо JSON-ы. А серьезные дяди эти данные еще заливают на сервер. И разумеется, это всё сочетать.

7) Хранение подгружаемых данных. Есть ли у вас подгружаемые данные, которые скачиваются после запуска игры? Чаще всего, такие данные либо упакованы в AssetBundles, либо Addressables. Впрочем, вам никто не мешает написать своё интересное решение.

8) Backend. Есть ли у вашей игры некий сервер с которого игра подгружает какие-то данные? Есть несколько вариантов того, как он может быть организован и на основе какого именно сетевого соединения.

9) Multiplayer. Если у вашей игры есть мультиплеер, необходимо понять на чём он будет основан. В зависимости от того, пошаговая ли у вас игра, или сетевой шутан - выберите нужную платформу.

10) Размер проекта. Деление очень условное, но в зависимости от размера вашего проекта очень сильно зависит то, насколько сильно нужно задумывать ваш код наперёд и наоборот насколько сильно можно закостылить те или иные модули. Многие решения хорошо покажут себя в краткосрочной перспективе, но причинят много боли в долгосрочной разработке.

11) Организация проекта в самой Unity. Здесь очень много мелких деталей которые вместе составляют важную часть вашей разработки. Как вы организуете файлы в вашем проекте? Есть ли у вас определённый нейминг для папок с кодом, картинками, анимациями и тд?

12) Тестирование, обратная связь и валидация. Довольно важный аспект для проектов больше среднего. Тестируете ли вы свою игру? Как много вашей игры покрыто тестами? Есть ли у вас в игре аналитические системы, которые позволят вам увидеть, что игроки сталкиваются на проде с какой-то ошибкой.

Если вы раскроете то, как выглядят эти столпы в вашем проекте другому разработчику, он сразу поймет вашу архитектуру, то есть то, как устроена ваша игра.