Zenject в Unity! Лучший инструмент для построения архитектуры игры! Внедрение зависимостей
HTML-код
- Опубликовано: 19 июн 2024
- ⚡️⚡️⚡️ Полезные ссылки ⚡️⚡️⚡️
🔎 yakovlevgamedev.tilda.ws - запись на курс и дополнительная информация
🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал
🔎 • Архитектура игры C# и ... - ссылка на видос с точкой входа (1-й совет)
🔎 boosty.to/yakovlevgamedev - ссылка на бусти (тут можно поддержать канал, выход новых видео и даже получить эксклюзивные ништяки)
🔎 / @alexgameryt6256 - ссылка на канал моего младшего брата (подпишись если не сложно)
📝Всем шарп! Сегодня я расскажу вам о наверное лучшем инструменте для внедрения зависимостей и построения архитектуры в Unity - Zenject. Постараюсь подробно донести для чего нужен этот инструмент и какие проблемы проекта он помогает решить, посмотрим на базовый функционал зенжекта, и разберем пару интересных ситуаций. Если хотите больше видосов по данной теме, то ставьте лайки и пишите комментарии! Всем приятного просмотра!
🕒Тайм-коды:
➜ 00:00 - Вступление
➜ 00:16 - Вводный пример для разбора (SOLID + Zenject)
➜ 02:48 - Как стоит относится к SOLID
➜ 03:23 - Точка входа и проблема инициализации приложения
➜ 05:24 - Zenject и полезная информация!
➜ 06:40 - Разбираемся с базовым функционалом
➜ 10:20 - Прокачиваем регистрацию объектов
➜ 11:15 - Инициализация игрока и атрибут Inject
➜ 12:49 - Глобальное внедрение зависимостей на весь проект
➜ 14:12 - Заключение
🔥🔥🔥 На этом канале вы найдете множество уроков по Unity и C#, а так же различных видео на тему разработки игр, так что не стесняйтесь, заглядывайте на канал и вы обязательно найдете что-то по душе!🔥🔥🔥
#Unity#ЯковлевИлья#Zenject#архитектура
⚡⚡⚡ Полезные ссылки ⚡⚡⚡
🔎 yakovlevgamedev.tilda.ws - запись на курс и дополнительная информация
🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал
🔎 ruclips.net/video/ZIGJTNrvfjg/видео.html - ссылка на видос с точкой входа (1-й совет)
🔎 boosty.to/yakovlevgamedev - ссылка на бусти (тут можно поддержать канал, выход новых видео и даже получить эксклюзивные ништяки)
🔎 ruclips.net/channel/UCC-hfECZdghe_QNAJzztHEg - ссылка на канал моего младшего брата (подпишись если не сложно)
как купить курс?
@@OrbitaGames8 к сожалению, места на этот поток закончились, только в следующий:(
А что скажешь насчет VContainer и Reflex? Прост зенжект не поддерживается уже несколько лет вроде.
Смотрел другие видео по данной теме и всё давалось сложно, но как только посмотрел разбор данной темы у тебя, так всё стало на места
Неплохое видео про Zenject. Но все же хотелось бы увидеть примеры его применения в реальных играх, там его функционал более лучше раскрывается. А в целом, спасибо!
Ну на субъективном опыте приведу кейсы применения этого Зенжехта:
Абривеатуры:
SO - Scriptable Object.
MO - MonoInstaller зенжекта.
1) Ну очевидный пример тот что на видосе - подмена обработчика инпутов из MO в зависимости от платформы на которой игра запущена.
2) Через switch case в MO, в зависимости от enum UnityEngine.Application.systemLanguage, можно подменить текст в менюшках или озвучку персонажей под язык системы через сохранённые SO локализации.
3) Аналогично через switch и какой-нить собственный enum GameDifficulty,
можно подменить свой SO настроек урона
или количества спауна ботов на уровне
или пул вероятностей дропа шмоток с мобов,
крч автоматом подменить настройки всех зависимых от игровой сложности сущностей.
4) Так же как и со сложностью, но на сей раз уже с прогрессом игрока в игре,
можно поменять диалоги у NPC в зависимости от выполненных квестов игроком через вставку SO многосвязного древа выполненных игроком квестиков в фабрику диалогов NPC на сцене.
5) Обновить ассортимент какой-нить лавки на сцене, подменив пул товаров SO через метод-конструктор ассортимента лавки, в зависимости от сохранённой "репутации" игрока с фракцией владельца этой лавки перед запуском сцены в MO.
Пока что в голову больше ничё не приходит,
ну по крайней мере вышеописанное уже можно мутить через зенжых.
@@lewaplay зачем придумывать какие-то велосипеды с подменой обработчиков ввода, если есть новая InputSystem, в которой можно всё максимально удобно и кастомно настроить, не лезя в код. Ещё и можно одной галочкой сделать чтобы игра автоматически определяла систему ввода. То есть подойдёт даже для специфических игроков, которые играют, условно, сразу с клавиатуры и контроллера
Спасибо за видео! Буду рад увидеть видео с лайфхаками по Zenject
Отличное видео по Zenject! Вы, пожалуй, первый в СНГ-сообществе кто довольно подробно и хорошо всё разъяснил) Прекрасная работа!
Хороший урок, понимание предмета на неплохом уровне, я узнал для себя новое про зенжект. Спасибо)
Однозначно лайк, давай больше видосов про zenject
Топ контент, спасибо!
Очень жду дальнейшего раскрытия темы Zenject
Спасибо за видос! Супер полезный инструмент, буду разбирать. Всю жизнь сам юмлки чертил и руками зависимости раскидывал, кучу времени отнимало)
восап! Пришел закинуть пару слов о том, что ты большой молодец. Такого контента на ru ютубе не хватает, продолжай) уважение+, как говорится ✌️
очень круто объяснил, респект
Крутое видео. Спасибо
Понравилось что быстро и всё по делу
Спасибо!
Чуть не кончил, когда увидел как изыскано Zenject решает проблему. Теперь понятно почему у меня нету девушки :D
Вы бог, спасибо большое. Я недавно начал учить Unity и C#, кое что умею, но вот с архитектурой беда. Разобрался с ООП, SOLID, а что делать дальше не знаю, все равно путаюсь в своем же коде \ проекте, масштабировать тяжело. Будем учиться!
Больше роликoв по Zenject!!!
Круто)
Шикарный урок!)
Как раз помогло мне ответить на один вопрос: нужен ли EntryPoint, если есть Zenject)
Хорошее видео, однако стоит отметить что zenject 1) довольно тяжелый и медленный так как использует рефлексию под капотом. Байндинги можно запечь но это прям лишний слой сложности что делается крайне редко. 2) С недавних пор extenject перестал поддерживатся разработчиком.
И тем не менее это всё равно почти мастхэв в любом проекте
@@user-dp1fg7wj7b его уже заменяют на vcontainer, который полегче и попроще. Основная претензия к зенжекту, на самом деле, то, что он содержит много лишнего функционала, таким образом это не просто dic, а швейцарский нож.
Впервые понял вообще всё в видосе по зенжекту
ждем лайфхаки)
нужно ещё.
Я так конкретно и не понял для себя в чем преимущество Zenject :( Данные в монобех объект ведь можно и при его инициализации передавать и без конструктора. Так же тип ввода зависимо от девайса можно например в bootstrap классе или еще где прописать. единственный плюсом для себя выявил что удобнее проследить все байндинги и их чередование.
Тоже не особо понял. Но к примеру если мы берем управление, то между сценами его передавать можно сериализовав в файл типа конфига, а тут я так понимаю у зенжекта есть подобный инструмент, для хранения информации извне, чтобы передать его в другую сцену. И я подозреваю что Zenject делает это посредством DontDestroyOnLoad. Не знаю в общем. Типа удобная штука привлекает. Но отталкивает что все таки это стороннее, не юнитековское расширение.
автоматизация внедрения зависимостей и их резолв. Да, это всё можно делать ручками, но с автоматическими инструментами это удобнее.
👍👍
сОлид а не сАлид ОООООООО
не лучше ли сейчас использовать New Input System?
Илья, вы являетесь мидл или сеньер разработчиком?
В кое-то веке увидел человека который коротко и ясно ответил на вопрос: "На**я DI нужен в Unity?".
Пасеба ❤.
Приветствую, при работе над более менее крупным проектом на сцене образуется огромное количество зависимостей, нужно в инспекторе прокидывать хренальон ссылок и в этом очень легко запутаться, когда условно говоря у нас есть Npc который наследуется от Entity, у него есть скрипт отвечающий за его расу Race, от нее наследуемые Human и Alien, при создании этого Entity мы можем выбрать его расу, в зависимости от нее у нас будут разные скрипты передвижения - HumanMovementSystem для Human и AlienMovementSystem для Alien, так-же у Alien будет InputAlienSystem наследуемое от InputSystem, у Human - InputHumanSystem, тоже самое для AttackSystem, HumanAttackSystem - может использовать определенные скиллы и тип оружия: холодное, огнестрельное, метательное, AlientAttackSystem - может использовать только магические скиллы. Так-же у каждого из них должены быть свои уникальные вьюхи. (Так-же по этому подобию, профессии, характеристики, умения, репутация - и все это в юнити в идеале должно быть в виде отдельных скриптов/компонентов, допустим, в будущем дизайнеры захотели, что-бы у Alien появились профессии, мы взяли и быстро забиндили с помощью DI, либо добавили в фабрику которая создает наших персонажей нужный интерфейс) Обычно для подобной реализации хорошо подходит паттерн стратегия и грамотное использование полиморфизма, но проблема в том, что мы не можем юзать ее напрямую из инспектора, есть вариант реализации стратегии на SO, но это огромный гемор.
И вот хотелось-бы увидеть подобный пример с использованием DI контейнера для Monobehaviour скриптов, когда мы ссылку на скрипт первого объекта прокидываем на второй и тд., а так-же примерно то, что было описано выше.
вывод - неверная архитектура. Не используйте ООП в играх.
@@Woolf530 проблема не в самом ООП, а в том, что инспектор юнити не может в полиморфизм), к примеру использование стратегии через реализацию интерфейса (а на интерфейсах построен весь ООП подход), без ООП уже через месяц проект загнется, так-как для какого либо изменения придется вносить хренальон правок, некоторые сложные задачи я решал с помощью собственной ECS + генерацией SO через кастомный Editor Window, а из этих SO при старте объекты забирали себе данные для инициализации. Но в любом случае полностью проект на ECS делать максимально плохое решение. Без ООП возможно запилить игру только есть уже финальное ТЗ, которое ни когда не будет изменяться и в будущем игра не будет обновляться допустим новыми механиками. =) А так допустим если-бы проект был чисто в виде десктопного приложения, то все эти зависимости можно было спокойно прокинуть в коде даже без использования сторонних DI контейнеров.
@@kent8695 " Без ООП возможно запилить игру только есть уже финальное ТЗ," да нет.. а кто мешает вам переписать определённые классы в процессе ввода нужной фичи? Не, я не против ООП как таковой вообще, иногда полезно, я, например, интерфейсы (те, которые UI) делаю через ООП, но сама игровая логика с ООП вот вообще никак не стакается. Или же это бывает крайне редко, в определённых жанрах "по три в ряд". Всё равно по итогу всё выльется в многостроковое "если-то"
- Жёстко зависит и мы ничего не можем сделать
-
- ...
- Profit?
Можно совет для чего его ещё использовать кроме Input-а?
В принципе, это прокидывание любых зависимостей) Тут все зависит от игры, если универсально, то всякие штуки для сохранения (например на разных веб платформах сохранения могут работать по разному и удобно подменять это дело). Какие нибудь штуки связанные с ресурсами и отображениями на интерфейсе, тот же самый кошелек я пример приводил в видео. Конфиги тоже удобно прокидывать. А так все что нужно для конкретно твоей игры, тут уж подсказать не могу)
@@-it394 спасибо за ответ с примерами!
Забавно, почему-то я не слышал про зенжект на всяких туториалах на Ютубе...
кто знает где скачать курс, дайте ссылку
А теперь бы знать как это все юзать вместе с тем же Netcode for GameObjects, там будет куча подводных камней, которые придется решать. Например спавнить объекты через зенжектовский или неткодовский Instantiate, или как, например, заинжектить зависимости на клиенте объекту который был создан на сервере, и так далее. Все эти проблемы можно, наверное, решать, но мне проще было отказаться от зенжекта в пользу старого доброго сервис локатора.
Опцій багато: юзати лейзіІнджект, робити в інсталері мануально резолв за потреби та інджект. Я от в DOTS в OnCreate() системи вимикаю їх, а в кастомному методі/проперті з [Inject] атрибутом приймаю залежність й вмикаю систему. Бо тут такий прикол, що не можна юзати конструктори ECS системи, бо в ЕСS власний ДІ контейнер. Тож я можу резолвити системи з цього ecs контейнеру в інсталері зенджекта й вже через контейнер зенджекта робити інджект в них. Є й інші варіанти.
4:37 что за случаи такие где нужно сущность передать в объект через несколько других? Что за случаи где используют синглтоны для данной задачи?
в чём отличие zenject от паттерна service locator?
ускоряет процесс. Использование паттернов не всегда и везде помогает + в больших проектах сложно это соблюдать, в zenject тупо тыкнул и готово
+
Вот все ровно не совсем понимаю
Ведь с таким же успехом, можно было бы добавить в Мувмент хендлер те ифы, для проверки какой инпут нужен, и в старте оно бы создало тот инпут что нужен
Или это все делается только для того, чтобы потом вручную не перекидывать в другие классы(по типу Плеера) поля?
А если ты захочешь ещё где-то Input использовать? Тоже будешь городить повторяющийся код, так ещё и получится так, что у тебя существует 2 Input'а, вместо одного. Вообщем, учи SOLID, DRY и прочие.
Очень старался, но ничерта не поняя((( Видимо тормозила... было бы круто если кто нибудь поделиться живым примером на небольшом проекте использования zenjec... к сожалению так ничего полезного и не нашел. Спасибо
Or you can just make your code modular. For example my Input class would always be input method agnostic, with multiple other classes providing specific platform input. The users use the agnostic class.
Never seen a good real world use case for Zenject that is not due to BAD initial architecture.
A lot of unnecessary busy work with Zenject in comparison to modular architecture with simple singletons.
Vcontainer на данный момент выглядит перспективнее
Просто zenject неплохо занял позиции уже)
@@-it394 как занял так и сдает. Плюшки на бумаге которые предлагает VConainer весомые. Это вес и скорость работы. а все эти фреймворки используются только чтобы инжектить что то, остальное это перегруз. Хотя и Vcontainer хочет чтобы ты переходил на их архитектуру aka ecs
Автор отвечает только на комментарии с благодарностями людей, которые на самом деле ничего не поняли?
Азахххххаыпвахп
Ох уж эти оопшники использующие zenject... Создавая паутину из кучи зависимостей.
Хм. А есть способы создать архитектуры без кучи зависимостей?
Zenject не обновлялса уже несколько лет и врядле будет. Не продвигай то что уже умерло...
Он прекрасно работает тем не менее
VContainer до 50 раз быстрее Znject, а видео по нему в рус сегменте нет...
Ребят, лучше пройдите курс у Синдикатов, там то ребята по опытнее будут, чем этот маслёнок без опыта в продуктовой разработке
а как у вас с продуктовой разработкой? Где можно ознакомиться с вашими личными проектами? Желательно, классом от АА и выше.
Кроме "навальный вс путин", конечно..
@@Woolf530 можно совет как правильно прокидывать зависимости? Приведу пример: у меня в игре есть класс MenuHandler, от него наследуются MainMenuHandler и PauseMenuHandler, им обоим нужен ProgressKeeper для того чтобы знать текущий уровень и достигнутый уровень. Я сделал ProgressKeeper статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?
мда.. тот самый момент, когда 20 лет профессионально занимаешься геймдевом, из которых 10 лет на юнити, а про "самый популярный инструмент" впервые слышишь.. как собственно, и отсутствие понимания, на кой хрен оно нужно.. Получается, сначала усложняется код ООПом, патернами, ивентами и другой совершенно не нужной хренью, а затем берутся костыли, которые это всё.. превращают обратно в обычный понимаемый код. Бинго, ля!
Печальная повесть о том, как рождаются долгострои ))
Тоже не понимаю этого возвышения зенжектов и прочих DI контейнеров. Сколько лет хожу вокруг них и никак не могу приткнуть их для себя. Хотя и инверсии зависимостей есть и абстракции, но почему то вот все мои архитектуры прекрасно обходятся без DI контейнеров. И при этом нет вложенных инициализаций. Все инициализации как то сами собой разруливаются и абсолютно без гемора. Я в итоге пришёл к выводу что все эти DI контейнеры притащили из софтверного программирования, где они действительно нужны и могут экономить время, а для юнити оно особо не нужно, может только в исключительных случаях. Больше на моду похоже, делайте так потому что это модно
@@olegsitnikov633 Ребят я с вами, изучаю юнити три года, работаю один. И я вот все время чувствовал себя как долбаеб, когда в ру чате по юнити все с этими зависимостями ебутся, вот нихуя не понимаю как зачем и куда, то ли у меня не такие большие проекты, то ли что, не пойму и всё.
@@olegsitnikov633 можно совет как правильно прокидывать зависимости? Приведу пример: у меня в игре есть класс MenuHandler, от него наследуются MainMenuHandler и PauseMenuHandler, им обоим нужен ProgressKeeper для того чтобы знать текущий уровень и достигнутый уровень. Я сделал ProgressKeeper статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?
@@BlackHole-ei9mi можно совет как правильно прокидывать зависимости? Приведу пример: у меня в игре есть класс MenuHandler, от него наследуются MainMenuHandler и PauseMenuHandler, им обоим нужен ProgressKeeper для того чтобы знать текущий уровень и достигнутый уровень. Я сделал ProgressKeeper статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае? Буду благодарен, если дадите дельный совет.
@@olegsitnikov633 можно совет как правильно прокидывать зависимости? Приведу пример: у меня в игре есть класс MenuHandler, от него наследуются MainMenuHandler и PauseMenuHandler, им обоим нужен ProgressKeeper для того чтобы знать текущий уровень и достигнутый уровень. Я сделал ProgressKeeper статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?
Тупой синглтон с кучей разрозненных объектов, которые где-то нужны и лень прокидывать.