DI + UNITY = ZENJECT ⚡️ Dependency injection в Unity

• Ведущие приветствуют участников вебинара по теме инжекшн в Unity.  

• Удивляются количеству зарегистрированных и пришедших участников.  

• Представляют себя: Леша и Катя.  

• Проверяют звук и свет.  

• Вебинар будет посвящен инжекшн в Unity и Zenject.  

• Обсуждают, что инжекшн в Unity часто вызывает споры и обсуждения.  

• Zenject как воплощение инжекшн в Unity.  

• Обсуждение комментариев о перегруженности Zenject функционалом.  

• Ведущие отвечают на комментарии и объясняют, что Zenject поддерживается и имеет свои преимущества.  

• Zenject как фреймворк для инжекшн в Unity.  

• Zenject часто упоминается в вакансиях как плюс.  

• Ведущие рекомендуют использовать Zenject для инжекшн в Unity.  

• Ведущие планируют показать, как использовать Zenject без встраивания в проект.  

• Рассматривают типичные кейсы и проблемы, которые можно решить с помощью Zenject.  

• Используют туториал от Unity для демонстрации.  

• Обсуждение зависимостей в объектно-ориентированном программировании.  

• Зависимости как сервисы, используемые классами.  

• Важность явных и неявных зависимостей для понимания кода.  

• Обсуждение зависимости классов и их влияния на выполнение задач.  

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

• Проблемы с пониманием кода из-за использования сложных конструкций.  

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

• Композиция кода и регистрация зависимостей.  

• Инъекция зависимостей как способ автоматизации работы с зависимостями.  

• Понятие контекстов в Unity и их роль в регистрации зависимостей.  

• Глобальный контекст проекта и контекст сцены.  

• Практическое применение контекстов для регистрации зависимостей.  

• История создания и поддержка Inject.  

• Установка Inject в проект и настройка зависимостей.  

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

• Катя рассказала о контейнерах зависимостей, где регистрируются различные зависимости.  

• Инсталлеры могут регистрировать зависимости в контейнере.  

• Рекомендуется использовать моно-инсталлер для регистрации зависимостей.  

• Обсуждение создания объектов и их ассоциации через инжекшн.  

• Настройка сцены и контекстов для корректной работы.  

• Использование сцены для инициализации и старта игры.  

• Разделение начальной сцены и основной игры.  

• Создание сцен контекста для инициализации зависимостей.  

• Использование скриптов для управления порядком инициализации.  

• Создание папки для хранения экзорси.  

• Создание страп-инсталлера для регистрации сервисов.  

• Добавление страп-инсталлера в список моно-инсталлеров.  

• Добавление сцен контекста на сцену уровня.  

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

• Проблемы с вросшим героем и оптимизация уровней.  

• Хранение героя на каждом уровне неудобно и болезненно.  

• Герой имеет несколько атрибутов, которые нужно применить.  

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

• Ошибки возникают из-за того, что герой имеет ссылки на объекты на сцене.  

• Удаление героя приводит к ошибкам, так как другие объекты зависят от него.  

• Решение: восстановить поведение туториала, минимально изменяя код.  

• Герой должен быть инстанцирован на стартовом поинте каждого уровня.  

• Создан новый инсталлер, который будет жить столько, сколько сцена.  

• Герой будет инстанцироваться из кода, а не из модели.  

• Герой будет передаваться как зависимость в монстров.  

• Инстанцирование героя будет происходить через контейнер DI.  

• Контейнер DI будет инжектить необходимые компоненты в героя.  

• Регистрация зависимостей происходит по интерфейсу.  

• Это удобно для тестирования и адаптации под разные платформы.  

• Использование интерфейса ограничивает использование и позволяет легко менять реализации.  

• Вопрос о возможности использования DI с Photon.  

• Рекомендуется использовать фабрику для инжектирования зависимостей.  

• Фабричный подход позволяет корректно работать с DI и Photon.  

• Обсуждение различных вариантов использования инжектов.  

• Рекомендация не инжектить в гейм-объекты, если это возможно.  

• Переход на использование инжектов постепенно.  

• Описание трех вариантов использования инжектов: дефолтный, кэш и синглтон.  

• Дефолтный вариант: создание нового инстанса при каждом запросе.  

• Кэш: сохранение инстанса до уничтожения контейнера.  

• Синглтон: исключение при попытке зарегистрировать тот же инстанс дважды.  

• Синглтоны могут инициализироваться в разных местах и в разном порядке.  

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

• В большинстве случаев синглтоны используются для удобства.  

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

• Рекомендация использовать методы с одинаковым названием для инжекции.  

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

• Рекомендация не инжектить в поля и свойства.  

• Инжекция в методы с одинаковым названием предпочтительнее.  

• Пример использования метода для инжекции в класс.  

• Описание проблемы с инвентарем и скриптами.  

• Решение проблемы через создание контейнерного компонента.  

• Пример создания и регистрации контейнерного компонента.  

• Обсуждение регистрации зависимостей в контейнере.  

• Пример регистрации зависимостей как lazy-зависимостей.  

• Важность понимания, когда и как использовать lazy-зависимости.  

• Обсуждение методов и компонентов для отображения инвентаря.  

• Решение использовать метод в компоненте героя.  

• Создание метода для контракта и использование шаблона для быстрого создания.  

• Проблемы с отображением инвентаря в компоненте.  

• Обсуждение необходимости изменения ссылок и последовательности кода.  

• Решение использовать дисплей-холдер для отображения инвентаря.  

• Оптимизация кода для использования Unity.  

• Создание массива для хранения слотов.  

• Добавление новых компонентов и проверка их работы.  

• Проблемы с управлением героем и его поведением.  

• Обсуждение использования Unity Events и их недостатков.  

• Решение переделать логику управления героем.  

• Переделка логики управления героем.  

• Удаление Unity Events и использование обычных событий.  

• Создание интерфейса для управления героем.  

• Установка интерфейса для управления героем.  

• Создание контейнера для инстанцирования компонента.  

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

• Создаем синглтон для работы с маус-сервисом.  

• Добавляем метод для получения маус-сервиса в хиро-контроллер.  

• Подписываемся на события и освобождаем сервис при выходе из игры.  

• Удаляем ненужные изменения и переносим маус-сервис в прифаб.  

• Проверяем работу сервиса в игре, включая атаку и спел-каст.  

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

• Рассматриваем типичные ситуации интеграции сервисов.  

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

• Рекомендует использовать инжектор для новичков.  

• Добавляем дополнительные сервисы в бутстрап-инсталлятор.  

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

• Подчеркиваем важность правильного использования контекстов и инжектора.  

• Вебинар является дополнением к курсу по архитектуре игр.  

• Курс охватывает различные приемы и техники для разработки игр.  

• Обсуждаем использование DI-контейнеров и их роль в организации зависимостей.  

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

• Подчеркиваем важность базового понимания программирования и работы с Unity.  

• Планируем старт курса 25 ноября.  

• Рассматриваем использование фабрик для создания объектов на рантаме.  

• Демонстрируем инжекцию сервисов в объекты, используя монстров.  

• Подчеркиваем важность правильного инжектирования зависимостей.  

• Фабрики удобны для создания объектов.  

• Видео начало подлагивать, решили остановить трансляцию и перезапустить.  

• Фабрики позволяют легко контролировать зависимости и пробрасывать их.  

• Монстры на сцене требуют настройки позиций и моделей.  

• Решили заменить текущую систему на более логичную.  

• Обсудили важность разделения ответственности в классах.  

• Создали маркерный класс для удобства размещения монстров.  

• Класс будет иметь публичную переменную для настройки типа монстра.  

• Добавили красную сферу для визуализации маркеров.  

• Монстры будут иметь два типа: мили и рендж.  

• Создали два маркера для каждого типа монстра.  

• Монстры будут спавниться на основе этих маркеров.  

• Создали собственную фабрику для создания монстров.  

• Фабрика должна уметь загружать и создавать монстров.  

• Обсудили использование интерфейсов для отвязки от Unity.  

• Интерфейс позволяет зарегистрировать объекты после резова.  

• Пример использования интерфейса для регистрации инсталлера.  

• Интерфейс позволяет распознавать и использовать зависимости.  

• Возможность жесткого получения зависимостей через форс.  

• Пример использования хака для получения фабрики.  

• Обсуждение необходимости использования инжекции зависимостей.  

• Обсуждение работы с фреймворком и скриптами.  

• Пример использования фреймворка для создания объектов.  

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

• Создание и использование фабрики для создания объектов.  

• Пример написания маленьких методов для улучшения читаемости кода.  

• Обсуждение важности аккуратного написания кода.  

• Инъекция зависимостей через контейнер.  

• Пример использования контейнера для создания объектов.  

• Обсуждение ответственности за создание объектов и использование контейнера.  

• Создание и загрузка прифабов для объектов.  

• Пример использования прифабов для создания монстров.  

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

• Завершение работы с прифабами и контейнером.  

• Тестирование и исправление ошибок.  

• Обсуждение необходимости передачи маркеров в инсталлер.  

• Обсуждение добавления маркеров и их заполнения из Unity.  

• Проблемы с использованием маркеров и их решение.  

• Обсуждение использования вай-пойнтов и их обнуление.  

• Демонстрация работы с инстанцированием через фабрики.  

• Обсуждение использования фабрик и их преимуществ.  

• Проблемы и решения при использовании инжект-контейнеров.  

• Обсуждение архитектуры и ивентов в Unity.  

• Проблемы с использованием ивентов и их влияние на код.  

• Преимущества использования инжект-контейнеров для упрощения работы.  

• Описание курса и его формата.  

• Темы, охватываемые курсом: архитектура, управление ресурсами, сборка и т.д.  

• Преимущества просмотра курса и его стоимость.  

• Процесс прохождения курса и его длительность.  

• Скидки на курс и его доступность.  

• Пример использования курса на конкретном проекте.  

• Курс направлен на создание повторяемого и подробного кода.  

• Обсуждение использования спавнера и его особенностей.  

• Важность объектно-ориентированного мышления и его совместимость с IoC.  

• IoC не является архитектурой, а лишь фреймворком.  

• Важно понимать, что IoC не ограничивает архитектурные решения.  

• IoC облегчает жизнь разработчикам, но не является обязательным.  

• IoC помогает даже при отсутствии строгой архитектуры.  

• Обсуждение специфичных задач и их решений.  

• Вопросы и ответы о IoC и его применении.  

• Планы по созданию платформы для стажировки.  

• Поддержка и расширение текущих проектов.  

• Продолжение создания игр и проведение вебинаров.