⚡⚡⚡ Полезные ссылки ⚡⚡⚡ 🔎 yakovlevgamedev.tilda.ws - запись на курс и дополнительная информация 🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал 🔎 ruclips.net/video/ZIGJTNrvfjg/видео.html - ссылка на видос с точкой входа (1-й совет) 🔎 boosty.to/yakovlevgamedev - ссылка на бусти (тут можно поддержать канал, выход новых видео и даже получить эксклюзивные ништяки) 🔎 ruclips.net/channel/UCC-hfECZdghe_QNAJzztHEg - ссылка на канал моего младшего брата (подпишись если не сложно)
Неплохое видео про 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, в которой можно всё максимально удобно и кастомно настроить, не лезя в код. Ещё и можно одной галочкой сделать чтобы игра автоматически определяла систему ввода. То есть подойдёт даже для специфических игроков, которые играют, условно, сразу с клавиатуры и контроллера
привет. Не знаю жива ли тема, но меня интерисут пример с мобильным управлением если оно нужно через SystemInfo, как в примере на 10:39. Что если я использую "новую" input system и забиндил уже через нее управление? Стоит ли пользоваться таким подходом дополнительно или это уже не актуально и лучше такие зависимости не внедрять?
Я так конкретно и не понял для себя в чем преимущество Zenject :( Данные в монобех объект ведь можно и при его инициализации передавать и без конструктора. Так же тип ввода зависимо от девайса можно например в bootstrap классе или еще где прописать. единственный плюсом для себя выявил что удобнее проследить все байндинги и их чередование.
Тоже не особо понял. Но к примеру если мы берем управление, то между сценами его передавать можно сериализовав в файл типа конфига, а тут я так понимаю у зенжекта есть подобный инструмент, для хранения информации извне, чтобы передать его в другую сцену. И я подозреваю что Zenject делает это посредством DontDestroyOnLoad. Не знаю в общем. Типа удобная штука привлекает. Но отталкивает что все таки это стороннее, не юнитековское расширение.
Вы бог, спасибо большое. Я недавно начал учить Unity и C#, кое что умею, но вот с архитектурой беда. Разобрался с ООП, SOLID, а что делать дальше не знаю, все равно путаюсь в своем же коде \ проекте, масштабировать тяжело. Будем учиться!
Хорошее видео, однако стоит отметить что zenject 1) довольно тяжелый и медленный так как использует рефлексию под капотом. Байндинги можно запечь но это прям лишний слой сложности что делается крайне редко. 2) С недавних пор extenject перестал поддерживатся разработчиком.
@@РусланУстименко-л1ц его уже заменяют на vcontainer, который полегче и попроще. Основная претензия к зенжекту, на самом деле, то, что он содержит много лишнего функционала, таким образом это не просто dic, а швейцарский нож.
В принципе, это прокидывание любых зависимостей) Тут все зависит от игры, если универсально, то всякие штуки для сохранения (например на разных веб платформах сохранения могут работать по разному и удобно подменять это дело). Какие нибудь штуки связанные с ресурсами и отображениями на интерфейсе, тот же самый кошелек я пример приводил в видео. Конфиги тоже удобно прокидывать. А так все что нужно для конкретно твоей игры, тут уж подсказать не могу)
А теперь бы знать как это все юзать вместе с тем же Netcode for GameObjects, там будет куча подводных камней, которые придется решать. Например спавнить объекты через зенжектовский или неткодовский Instantiate, или как, например, заинжектить зависимости на клиенте объекту который был создан на сервере, и так далее. Все эти проблемы можно, наверное, решать, но мне проще было отказаться от зенжекта в пользу старого доброго сервис локатора.
Опцій багато: юзати лейзіІнджект, робити в інсталері мануально резолв за потреби та інджект. Я от в DOTS в OnCreate() системи вимикаю їх, а в кастомному методі/проперті з [Inject] атрибутом приймаю залежність й вмикаю систему. Бо тут такий прикол, що не можна юзати конструктори ECS системи, бо в ЕСS власний ДІ контейнер. Тож я можу резолвити системи з цього ecs контейнеру в інсталері зенджекта й вже через контейнер зенджекта робити інджект в них. Є й інші варіанти.
я бы с Construct поспорил, мне выглядит это наоборот более грязным решением, ведь теперь у меня 2 места определения зависимости. метод и само поле лучше чем держать все близко и рядом пока ничего нет, а проблемы видимости всех зависимостей решается группировкой, ток жаль что у c# нет линтера на подобие eslint как в js, там можно было бы правило с автофиксом разработать)
Вот все ровно не совсем понимаю Ведь с таким же успехом, можно было бы добавить в Мувмент хендлер те ифы, для проверки какой инпут нужен, и в старте оно бы создало тот инпут что нужен
А если ты захочешь ещё где-то Input использовать? Тоже будешь городить повторяющийся код, так ещё и получится так, что у тебя существует 2 Input'а, вместо одного. Вообщем, учи SOLID, DRY и прочие.
Приветствую, при работе над более менее крупным проектом на сцене образуется огромное количество зависимостей, нужно в инспекторе прокидывать хренальон ссылок и в этом очень легко запутаться, когда условно говоря у нас есть 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) делаю через ООП, но сама игровая логика с ООП вот вообще никак не стакается. Или же это бывает крайне редко, в определённых жанрах "по три в ряд". Всё равно по итогу всё выльется в многостроковое "если-то"
Очень старался, но ничерта не поняя((( Видимо тормозила... было бы круто если кто нибудь поделиться живым примером на небольшом проекте использования zenjec... к сожалению так ничего полезного и не нашел. Спасибо
Сколько не смотрел про DI и Zenject, в частности, туторов и статей, так и не понял плюсы от этих прокидываний зависимостей. Как по мне, все примеры его использования похожи на - Сначала сам себе выстрелю в ногу, затем обмотаю ее Zenjectом - и вуаля - не косяк, а фитча. Спорная технология. А в больших проектах от такого кол-ва абстракций и вовсе дурно становится.
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.
@@-it394 как занял так и сдает. Плюшки на бумаге которые предлагает VConainer весомые. Это вес и скорость работы. а все эти фреймворки используются только чтобы инжектить что то, остальное это перегруз. Хотя и Vcontainer хочет чтобы ты переходил на их архитектуру aka ecs
мда.. тот самый момент, когда 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 статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?
Согласен, сейчас это может быть «Так работает же», а потом боль-боль-боль Начнем с того, что даже масштабирование UI Unity много лет есть только для винды, тикеты висят на Мак и Линукс и всё
а как у вас с продуктовой разработкой? Где можно ознакомиться с вашими личными проектами? Желательно, классом от АА и выше. Кроме "навальный вс путин", конечно..
@@Woolf530 можно совет как правильно прокидывать зависимости? Приведу пример: у меня в игре есть класс MenuHandler, от него наследуются MainMenuHandler и PauseMenuHandler, им обоим нужен ProgressKeeper для того чтобы знать текущий уровень и достигнутый уровень. Я сделал ProgressKeeper статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
⚡⚡⚡ Полезные ссылки ⚡⚡⚡
🔎 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! Вы, пожалуй, первый в СНГ-сообществе кто довольно подробно и хорошо всё разъяснил) Прекрасная работа!
на вашем канале я его тоже смотрел )
Смотрел другие видео по данной теме и всё давалось сложно, но как только посмотрел разбор данной темы у тебя, так всё стало на места
Неплохое видео про 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 решает проблему. Теперь понятно почему у меня нету девушки :D
Хороший урок, понимание предмета на неплохом уровне, я узнал для себя новое про зенжект. Спасибо)
Однозначно лайк, давай больше видосов про zenject
Спасибо за видео! Буду рад увидеть видео с лайфхаками по Zenject
Спасибо за видос! Супер полезный инструмент, буду разбирать. Всю жизнь сам юмлки чертил и руками зависимости раскидывал, кучу времени отнимало)
восап! Пришел закинуть пару слов о том, что ты большой молодец. Такого контента на ru ютубе не хватает, продолжай) уважение+, как говорится ✌️
Топ контент, спасибо!
привет. Не знаю жива ли тема, но меня интерисут пример с мобильным управлением если оно нужно через SystemInfo, как в примере на 10:39. Что если я использую "новую" input system и забиндил уже через нее управление? Стоит ли пользоваться таким подходом дополнительно или это уже не актуально и лучше такие зависимости не внедрять?
Больше роликoв по Zenject!!!
Понравилось что быстро и всё по делу
Шикарный урок!)
Как раз помогло мне ответить на один вопрос: нужен ли EntryPoint, если есть Zenject)
Я так конкретно и не понял для себя в чем преимущество Zenject :( Данные в монобех объект ведь можно и при его инициализации передавать и без конструктора. Так же тип ввода зависимо от девайса можно например в bootstrap классе или еще где прописать. единственный плюсом для себя выявил что удобнее проследить все байндинги и их чередование.
Тоже не особо понял. Но к примеру если мы берем управление, то между сценами его передавать можно сериализовав в файл типа конфига, а тут я так понимаю у зенжекта есть подобный инструмент, для хранения информации извне, чтобы передать его в другую сцену. И я подозреваю что Zenject делает это посредством DontDestroyOnLoad. Не знаю в общем. Типа удобная штука привлекает. Но отталкивает что все таки это стороннее, не юнитековское расширение.
автоматизация внедрения зависимостей и их резолв. Да, это всё можно делать ручками, но с автоматическими инструментами это удобнее.
Вы бог, спасибо большое. Я недавно начал учить Unity и C#, кое что умею, но вот с архитектурой беда. Разобрался с ООП, SOLID, а что делать дальше не знаю, все равно путаюсь в своем же коде \ проекте, масштабировать тяжело. Будем учиться!
Тут только практика и опыт помогает, сам сейчас только и делаю, что накапливаю этот опыт и нейронные связи😂
Спасибо большое🔥
очень круто объяснил, респект
Спасибо!
Хорошее видео, однако стоит отметить что zenject 1) довольно тяжелый и медленный так как использует рефлексию под капотом. Байндинги можно запечь но это прям лишний слой сложности что делается крайне редко. 2) С недавних пор extenject перестал поддерживатся разработчиком.
И тем не менее это всё равно почти мастхэв в любом проекте
@@РусланУстименко-л1ц его уже заменяют на vcontainer, который полегче и попроще. Основная претензия к зенжекту, на самом деле, то, что он содержит много лишнего функционала, таким образом это не просто dic, а швейцарский нож.
@@РусланУстименко-л1ц так VContainer имеет почти все те же функции, но более производительный и поддерживается разработчиками
Крутое видео. Спасибо
Очень жду дальнейшего раскрытия темы Zenject
Впервые понял вообще всё в видосе по зенжекту
Можно совет для чего его ещё использовать кроме Input-а?
В принципе, это прокидывание любых зависимостей) Тут все зависит от игры, если универсально, то всякие штуки для сохранения (например на разных веб платформах сохранения могут работать по разному и удобно подменять это дело). Какие нибудь штуки связанные с ресурсами и отображениями на интерфейсе, тот же самый кошелек я пример приводил в видео. Конфиги тоже удобно прокидывать. А так все что нужно для конкретно твоей игры, тут уж подсказать не могу)
@@-it394 спасибо за ответ с примерами!
не лучше ли сейчас использовать New Input System?
А теперь бы знать как это все юзать вместе с тем же Netcode for GameObjects, там будет куча подводных камней, которые придется решать. Например спавнить объекты через зенжектовский или неткодовский Instantiate, или как, например, заинжектить зависимости на клиенте объекту который был создан на сервере, и так далее. Все эти проблемы можно, наверное, решать, но мне проще было отказаться от зенжекта в пользу старого доброго сервис локатора.
Опцій багато: юзати лейзіІнджект, робити в інсталері мануально резолв за потреби та інджект. Я от в DOTS в OnCreate() системи вимикаю їх, а в кастомному методі/проперті з [Inject] атрибутом приймаю залежність й вмикаю систему. Бо тут такий прикол, що не можна юзати конструктори ECS системи, бо в ЕСS власний ДІ контейнер. Тож я можу резолвити системи з цього ecs контейнеру в інсталері зенджекта й вже через контейнер зенджекта робити інджект в них. Є й інші варіанти.
кто знает где скачать курс, дайте ссылку
4:37 что за случаи такие где нужно сущность передать в объект через несколько других? Что за случаи где используют синглтоны для данной задачи?
я бы с Construct поспорил, мне выглядит это наоборот более грязным решением, ведь теперь у меня 2 места определения зависимости. метод и само поле
лучше чем держать все близко и рядом пока ничего нет, а проблемы видимости всех зависимостей решается группировкой, ток жаль что у c# нет линтера на подобие eslint как в js, там можно было бы правило с автофиксом разработать)
ждем лайфхаки)
столько вопросов закрыл просто одной технологией, какая же красота. спасибо большое
Зачем zenject если есть новая система ввода
Круто)
нужно ещё.
Забавно, почему-то я не слышал про зенжект на всяких туториалах на Ютубе...
В кое-то веке увидел человека который коротко и ясно ответил на вопрос: "На**я DI нужен в Unity?".
Пасеба ❤.
Илья, вы являетесь мидл или сеньер разработчиком?
- Жёстко зависит и мы ничего не можем сделать
-
- ...
- Profit?
в чём отличие zenject от паттерна service locator?
ускоряет процесс. Использование паттернов не всегда и везде помогает + в больших проектах сложно это соблюдать, в zenject тупо тыкнул и готово
Вот все ровно не совсем понимаю
Ведь с таким же успехом, можно было бы добавить в Мувмент хендлер те ифы, для проверки какой инпут нужен, и в старте оно бы создало тот инпут что нужен
Или это все делается только для того, чтобы потом вручную не перекидывать в другие классы(по типу Плеера) поля?
А если ты захочешь ещё где-то Input использовать? Тоже будешь городить повторяющийся код, так ещё и получится так, что у тебя существует 2 Input'а, вместо одного. Вообщем, учи SOLID, DRY и прочие.
сОлид а не сАлид ОООООООО
Приветствую, при работе над более менее крупным проектом на сцене образуется огромное количество зависимостей, нужно в инспекторе прокидывать хренальон ссылок и в этом очень легко запутаться, когда условно говоря у нас есть 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) делаю через ООП, но сама игровая логика с ООП вот вообще никак не стакается. Или же это бывает крайне редко, в определённых жанрах "по три в ряд". Всё равно по итогу всё выльется в многостроковое "если-то"
👍👍
Очень старался, но ничерта не поняя((( Видимо тормозила... было бы круто если кто нибудь поделиться живым примером на небольшом проекте использования zenjec... к сожалению так ничего полезного и не нашел. Спасибо
Как же пое...ть на солид, аж заплакать хочется.
Сколько не смотрел про DI и Zenject, в частности, туторов и статей, так и не понял плюсы от этих прокидываний зависимостей. Как по мне, все примеры его использования похожи на - Сначала сам себе выстрелю в ногу, затем обмотаю ее Zenjectом - и вуаля - не косяк, а фитча. Спорная технология. А в больших проектах от такого кол-ва абстракций и вовсе дурно становится.
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
VContainer до 50 раз быстрее Znject, а видео по нему в рус сегменте нет...
Ох уж эти оопшники использующие zenject... Создавая паутину из кучи зависимостей.
Хм. А есть способы создать архитектуры без кучи зависимостей?
+
мда.. тот самый момент, когда 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 статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?
Zenject не обновлялса уже несколько лет и врядле будет. Не продвигай то что уже умерло...
Он прекрасно работает тем не менее
Согласен, сейчас это может быть «Так работает же», а потом боль-боль-боль
Начнем с того, что даже масштабирование UI Unity много лет есть только для винды, тикеты висят на Мак и Линукс и всё
@@РусланТимченко-х1о работаю уже больше 4х лет на маке, все ок, полет нормальный
Тупой синглтон с кучей разрозненных объектов, которые где-то нужны и лень прокидывать.
Ребят, лучше пройдите курс у Синдикатов, там то ребята по опытнее будут, чем этот маслёнок без опыта в продуктовой разработке
а как у вас с продуктовой разработкой? Где можно ознакомиться с вашими личными проектами? Желательно, классом от АА и выше.
Кроме "навальный вс путин", конечно..
@@Woolf530 можно совет как правильно прокидывать зависимости? Приведу пример: у меня в игре есть класс MenuHandler, от него наследуются MainMenuHandler и PauseMenuHandler, им обоим нужен ProgressKeeper для того чтобы знать текущий уровень и достигнутый уровень. Я сделал ProgressKeeper статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?
уважаемый, объяснять это не твое((
Все поголовно сели на него, проблем он решить особо не помогает. Это как мода