Архитектура unity проектов

За всю карьеру удалось поработать на множестве игровых проектов в качестве Lead Unity Developer. И за более чем 5 лет удалось насмотреться на разные подходы к созданию проектов.

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

TL;DR

Об авторе

Меня зовут Алексей и я Lead разработчик. А последние полгода помогаю компании Zeptolab улучшать проект Overcrowded.

Я самоучка. Всё, что связано с разработкой игр, я изучал самостоятельно. Все мои знания — личный опыт. Работал над 5 мобильными проектами в разных жанрах (mid-core, simulator, merge-3). А также делал несколько проектов в дополненной реальности.

Проводя много времени за ответом на вопросы в unity чатиках в Telegram, я понял что тема архитектуры очень плохо освещена. А странные best practices от unity часто не имеют ничего общего с реальными проектами.

Потому сделал свой блог в Telegram, где пишу про архитектуру проектов на unity, присоединяйтесь!

(А|а)рхитектура

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

Архитектурные подходы (паттерны) в разработке ПО универсальны. Их можно применить к любому языку и проекту. Код, следующий этим принципам, будет +- одинаков с точки зрения масштабируемости и сложности.

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

И при проектировании нужно вырабатывать эти решения (правила, подходы, гайдлайны) не только для кода, но и для всего с чем проект связан:

• Именование файлов и папок, структура хранения ассетов, структура сборок

• Утилиты для разработки, тестирование, работа с системой контроля версии

• Билд проекта и его деплой, работа со сторами и выливка хотфиксов

• Мониторинг метрик, ошибок и реагирование на них

Структура проекта

Папка проекта

Перед тем как написать первую строчку кода, нужно решить очень важную проблему — быстрое захламление иерархии проекта. Чтобы последующие N-лет работать с ней без головной боли.

Обычно происходит как:

• Cоздается проект, в этой же папке создается git репозиторий.

• У вас плане backend с общей shared частью (это общий код для бэка и клиента, например модели). И вам нужно где-то хранить скрипты для копирования shared части.

• Или бэкенд лежит в одном репозитории с клиентом.

• Или CI/CD пайплайн потребует запуска кастомных скриптов.

• Или есть внешние конфиги, которые вы хотите хранить вне папки Assets, чтобы они не попали в билд (например конфигурации сборки билда).
  + unity генерирует кучу папок, которые не попадают в репозиторий, но есть локально (Library, Debug, Temp, obj и прочие).
  + файлы, которые генерирует Rider и VS.

• В итоге все смешалось.
  Что принадлежит проекту, что unity, что утилитам… Различить становится сложно

Сталкивались с таким? В общем это ведет к тому что работать с этим становится все сложнее и сложнее со временем.

Как этого избежать?

У себя на проектах я делаю такую иерархию:

+-- %project_name% |   +-- .git |   +-- %project_name%.Build |   +-- %project_name%.ExternalConfigs |   +-- %project_name%.ThirdParty |   +-- %project_name%.Keystore |   +-- %project_name%.Backend |   +-- %project_name%.Kubernetes |   +-- %project_name%.Unity |   |    + -- Assets |   |    |    +-- _Project

Плюсы:

• Unity проект отображается в Unity Hub адекватно

• Внешние и внутренние файлы разделены

• Декларативность == низкая когнитивная сложность

Минусы:
Как по мне их нет, но если вы нашли, ?‍? в комментарии

Папка _Project

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

Со временем когнитивная сложность растет и поиск нужной папки отнимает все больше и больше времени.

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

Внутри

Первая проблема, которую я сразу решаю на новом проекте — 4 сцены для управления состоянием проекта.

• 0.Bootstrap — точка входа и контекст проекта (аналитика, SDK сторов, платежка, конфиги, связь с сервером)

• 1.Loading — загрузка, авторизация, GDPR, проверка обновлений и прочее что нужно для старта игры.

• 2.Meta — в основном UI в котором вы тратите накопленные ресурсы на прогресс по игре

• 3.Core — основная реиграбельная часть

• 4.Empty — костыль сцена для 100% выгрузки всех ресурсов предыдущей сцены.

Из любой сцены мы можем перейти в любую. Исключение Bootstrap. В нее входим только при запуске игры. И из нее загружаем только Loading

DI

DI (Dependency Injection) — подход, который абстрагирует создание объекта, выделяя его на отдельный слой и отделяя от основного приложения.

Добавляет концепцию управления зоной использования (scope) и временем жизни объекта.

При том важно разделять:

Composition Root (CR) — паттерн, подход при котором создание объектов системы происходит в одном месте.

Выделяет 3 (RRR) фазы управления жизненным циклом объектов:

• Register — создание зависимостей

• Resolve — решение графа зависимостей

• Release — удаление, освобождение объекта

DI container (DIc ?) — как правило плагин, реализация-автоматизация CR.

Т.е. вместо ручного создания и решения графа зависимостей, он через рефлексию или кодогеном сам прокидывает зависимости в конструктор или поля.

Service Locator (SL) — создает, хранит и отдает по требованию любое множество зависимостей.

Может быть частью реализации CR, но тогда решать граф нужно самому.

В этом месте, при не понимании RRR, возникает куча проблем (кольцевые зависимости, классы боги) из-за чего SL называют антипаттерном.

Из этого следует:

• Реализовать DI можно без использования DIc

• DIc (Zenject, Vcontainer и др.) сильно расширяют жизненный цикл любого класса

• С DIс мы делегируем обязанность по созданию и управлению жизненным циклом объекта!

• Легковестной реализацией DI может быть SL (статический класс со словарем)

При использовании DIc или SL важно навсегда запомнить:

1. Никакой логики в конструкторе. Только агрегация и композиция

2. Вся логика инициализации, как отдельная стадия создания объекта, выделяется в отдельный метод

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

Точка входа

Точка входа — LUCA проекта, место откуда все начинается.

А ее первостепенная и единственная задача — прозрачная инициализация проекта/сцены.

Критерии прозрачности:

• Можно легко найти в проекте/сцене

  • Объект всегда находится вверху иерархии сцены

  • На сцене объект всегда называется EntryPoint

• Сквозное единое именование

  • Постфикс Scope — для RRR фазы

  • Постфикс Flow — для фазы инициализации

  • Пример: BattleScope, BattleFlow, MetaScope, MetaFlow

• Единый дизайн классов

• Каждый Scope наследуется от класса, предоставляющий функционал IoC контейнера LifetimeScope, MonoInstaller

• Каждый Flow начинается с метода Start, в котором происходит вся инициализация

Т.е. мы сначала создаем объекты, inject’им их в Flow, ждем вызова Start и согласно нашему порядку инициализируем.

Из интересного:

• Поскольку решение графа и инициализация разделены, то начало работы класса может быть отложено на сколько угодно по времени.

• Инициализация в Start освобождает от необходимости помнить что такое ExecutionOrder
Так же защищает от рисков обратиться к внешней зависимости (плагину), которая еще не проинициализирована.

• Можно легко включать, отключать части игры, занося блоки инициализации под define

• Правило «1 точка входа = 1 сцена» избавляет от racing condition при инициализации

• Для инициализации монобехов пишется отдельный метод Init

• Start и Awake не реализуются из-за racing condition
  Иногда удобно прописать вызов Init() в Start(), чтобы запустить объект на другой сцене, вне основной системы

• Легко сделать примитивный перезапуск игры. Достаточно ещё раз вызвать метод Start

Define’ы проекта

В большинстве случаев, делай как удобно и норм.

Но со временем у меня сформировалось 3 подхода к добавление и использованию define’ов в проекте:

1. Восходящий — define’ы и их кол-во определяется фичами, которые используются в проекте. Как бы идем снизу, от фичей.
   Начинаются с ENABLE или DISABLE и отключают какой-то функционал, например: DISABLE_CHEATS, DISABLE_LOGS, ENABLE_SERVER_CONFIGS и т.д.

2. Нисходящий — define’ы и их кол-во определяется потребностями проекта.
   Начинаются с имени компании SILVERFOX, ROGAIKOPbITA и отключают/включают целую группу функций, которые должны быть доступны на том или ином окружение.

3. Комбинированный — когда включение одного define’а, включает/отключает несколько фичей. Требует конфигурации глобальных предиктив (те что действуют на весь проект).
   К сожалению поддерживается только для проектов, где *.csproj файлы задаются пользователем. В unity эти файлы генерирует только IDE, самому unity они не нужны, т.к. файлы ищутся по всему проекту и отдаются на сборку через csc.exe.

Например вот так в своей студии я организовывал define’ы:

• SILVERFOX_RC — отключены читы, отключен fake iap магазин, отключены валидации данных, отключены все логи ниже warning, включена консоль с логами

• SILVERFOX_PROD — отключены все фичи отладки и разработки

• В случае если ни одна из предиктив не указана, проект собирается со всеми включенными отладками, читами, логами. В общем работает по максимуму на разработчика и поиск проблемы

Плюсы:

• Кол-во define’ов полностью синхронизировано с кол-вом веток и их назначением

• Есть четкое понимание когда какой define нужно использовать

• Нет проблемы с двойным отрицанием по типу !DISABLE_CHEATS

Минусы:

Как по мне их нет, но если вы нашли, ?‍? в комментарии

Структура сборок

Сборки (Assembly definition, asmdef) — unity обертка над сборками в .NET. По факту это json в котором прописана конфигурация .NET Assembly.

Это делает сборки неотъемлемой частью архитектуры, потому что каждую сборку можно версионировать, проставлять в нее зависимости, определять отдельные define’ы.

Так же по умолчанию она поддерживает проверку на циклические зависимости.

У себя на проектах я выделяю такие сборки:

• Runtime — клиентский код

• Editor — утилиты редактора

• Tests.PlayMode — интеграционные тесты.

  • Т.е. тесты, для которых требуется unity scripts lifecycle

• Tests.EditorMode — unit тесты

Для онлайн приложений так же выделяю:

• Transport — cпецифичная для клиента связь с сервером. Реализация подключения, обмена данными, переключение состояний

• Shared — общие с бэком модели данных, константы, конфиги и прочее.

  • Т.е. эти сборки является моделью домена и явно отделяют отображение unity (слой Presentation) от источника данных (слой Data Source)

Выделение этих частей позволяет mock‘ать клиентскую часть и запускать клиент без unity т.е. должны стоять галки No Engine References

Из интересного:

• В define constrains поддерживает отрицание. Т.е. можно выключить всю сборку для PROD define’ов

• MonoBehavior нельзя добавить как компонент на объект если в Platforms отмечен только Editor
  Чтобы это обойти, поставьте галку на любую платформу, под которую 100% проект никогда не будет собран (Stadia например)

• Для удобства редактирования и отслеживания изменений в git, уберите галку Use GUIDs

• csc.rsp можно положить рядом с asmdef и прописать туда дополнительные параметры компиляции
  Удобно когда нужно подключить большой список define’ов или отключить надоедливые warning’и

• Можно делать точеные оптимизации или патчи IL кода через Mono.Cecil или Harmony. Так раньше был сделан Inject в VContainer

• Если сборка не изменилась, то перекомпилироваться она не будет. Таким образом, разбивая крупные сборки на более мелкие, можно снизить время компиляции проекта

Инициализация

Для правильной инициализации нужно одно:

❕Честная загрузка приложения без фейковых ожиданий и шкал.

Это меняет архитектуру объектов, так как загрузка должна быть асинхронной и последовательной.

Звучит не сложно, но часто проект сталкивается с проблемами из-за невнимания к этому:

• Инициализация происходит слишком рано
  У меня раньше было искажение что инициализация должна происходить до того как загрузится сцена. Такое решение может привести к неочевидным проблемам.

• Инициализация детерминирована
  Когда RRR и инициализация разделяются, но вызовы методов не упорядочены
  Или упорядочены не прозрачно, с завязкой на порядок регистрации или BindExecutionOrder

• Логика инициализации выполняется раньше решения графа
  Частая ошибка — писать весь код инициализации в Start или Awake, смешивая загрузку и инициализацию ресурсов.

  Так можно столкнуться с ситуацией, когда ресурс А зависит от ресурса Б, который еще не готов.

Чтобы этих проблем не было, нужно:

• Разделить фазу RRR и инициализации

• Выделить конcтруктор и метод Init(-ialize)

• Сделать сервис загрузки

• Реализовать все Initialize методы

• Запустить инициализацию, когда все компоненты движка 100% загружены

Тут лежит пример как это может быть реализовано на практике.

Это реальное тестовое задание, которое я делал пару месяцев назад меня с ним взяли в компанию, где я сейчас работаю.

Так же пример точки инициализации с одного из реальных проектов. Для понимания как это выглядит в продакшене.

Unity Empty Project Template (UEPT)

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

В разделе Installation вы сможете найти инструкции по настройке.

Пока там 10 пунктов, все из которых нужно делать ручками.

Использовать unitypackage не получилось т.к. он игнорирует пустые папки при импорте ?‍?

Заключение

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

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