⚡⚡⚡ Полезные ссылки ⚡⚡⚡ 🔎 yakovlevgamedev.tilda.ws - запись на курс и дополнительная информация 🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал 🔎 th-cam.com/video/ZIGJTNrvfjg/w-d-xo.html - ссылка на видос с точкой входа (1-й совет) 🔎 boosty.to/yakovlevgamedev - ссылка на бусти (тут можно поддержать канал, выход новых видео и даже получить эксклюзивные ништяки) 🔎 th-cam.com/channels/C-hfECZdghe_QNAJzztHEg.html - ссылка на канал моего младшего брата (подпишись если не сложно)
Сколько не смотрел про DI и Zenject, в частности, туторов и статей, так и не понял плюсы от этих прокидываний зависимостей. Как по мне, все примеры его использования похожи на - Сначала сам себе выстрелю в ногу, затем обмотаю ее 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 :( Данные в монобех объект ведь можно и при его инициализации передавать и без конструктора. Так же тип ввода зависимо от девайса можно например в bootstrap классе или еще где прописать. единственный плюсом для себя выявил что удобнее проследить все байндинги и их чередование.
Тоже не особо понял. Но к примеру если мы берем управление, то между сценами его передавать можно сериализовав в файл типа конфига, а тут я так понимаю у зенжекта есть подобный инструмент, для хранения информации извне, чтобы передать его в другую сцену. И я подозреваю что Zenject делает это посредством DontDestroyOnLoad. Не знаю в общем. Типа удобная штука привлекает. Но отталкивает что все таки это стороннее, не юнитековское расширение.
Хорошее видео, однако стоит отметить что zenject 1) довольно тяжелый и медленный так как использует рефлексию под капотом. Байндинги можно запечь но это прям лишний слой сложности что делается крайне редко. 2) С недавних пор extenject перестал поддерживатся разработчиком.
@@РусланУстименко-л1ц его уже заменяют на vcontainer, который полегче и попроще. Основная претензия к зенжекту, на самом деле, то, что он содержит много лишнего функционала, таким образом это не просто dic, а швейцарский нож.
Вы бог, спасибо большое. Я недавно начал учить Unity и C#, кое что умею, но вот с архитектурой беда. Разобрался с ООП, SOLID, а что делать дальше не знаю, все равно путаюсь в своем же коде \ проекте, масштабировать тяжело. Будем учиться!
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.
Очень старался, но ничерта не поняя((( Видимо тормозила... было бы круто если кто нибудь поделиться живым примером на небольшом проекте использования zenjec... к сожалению так ничего полезного и не нашел. Спасибо
В принципе, это прокидывание любых зависимостей) Тут все зависит от игры, если универсально, то всякие штуки для сохранения (например на разных веб платформах сохранения могут работать по разному и удобно подменять это дело). Какие нибудь штуки связанные с ресурсами и отображениями на интерфейсе, тот же самый кошелек я пример приводил в видео. Конфиги тоже удобно прокидывать. А так все что нужно для конкретно твоей игры, тут уж подсказать не могу)
А теперь бы знать как это все юзать вместе с тем же Netcode for GameObjects, там будет куча подводных камней, которые придется решать. Например спавнить объекты через зенжектовский или неткодовский Instantiate, или как, например, заинжектить зависимости на клиенте объекту который был создан на сервере, и так далее. Все эти проблемы можно, наверное, решать, но мне проще было отказаться от зенжекта в пользу старого доброго сервис локатора.
Опцій багато: юзати лейзіІнджект, робити в інсталері мануально резолв за потреби та інджект. Я от в DOTS в OnCreate() системи вимикаю їх, а в кастомному методі/проперті з [Inject] атрибутом приймаю залежність й вмикаю систему. Бо тут такий прикол, що не можна юзати конструктори ECS системи, бо в ЕСS власний ДІ контейнер. Тож я можу резолвити системи з цього ecs контейнеру в інсталері зенджекта й вже через контейнер зенджекта робити інджект в них. Є й інші варіанти.
Согласен, сейчас это может быть «Так работает же», а потом боль-боль-боль Начнем с того, что даже масштабирование UI Unity много лет есть только для винды, тикеты висят на Мак и Линукс и всё
Вот все ровно не совсем понимаю Ведь с таким же успехом, можно было бы добавить в Мувмент хендлер те ифы, для проверки какой инпут нужен, и в старте оно бы создало тот инпут что нужен
А если ты захочешь ещё где-то 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) делаю через ООП, но сама игровая логика с ООП вот вообще никак не стакается. Или же это бывает крайне редко, в определённых жанрах "по три в ряд". Всё равно по итогу всё выльется в многостроковое "если-то"
@@-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 статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?
а как у вас с продуктовой разработкой? Где можно ознакомиться с вашими личными проектами? Желательно, классом от АА и выше. Кроме "навальный вс путин", конечно..
@@Woolf530 можно совет как правильно прокидывать зависимости? Приведу пример: у меня в игре есть класс MenuHandler, от него наследуются MainMenuHandler и PauseMenuHandler, им обоим нужен ProgressKeeper для того чтобы знать текущий уровень и достигнутый уровень. Я сделал ProgressKeeper статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?
⚡⚡⚡ Полезные ссылки ⚡⚡⚡
🔎 yakovlevgamedev.tilda.ws - запись на курс и дополнительная информация
🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал
🔎 th-cam.com/video/ZIGJTNrvfjg/w-d-xo.html - ссылка на видос с точкой входа (1-й совет)
🔎 boosty.to/yakovlevgamedev - ссылка на бусти (тут можно поддержать канал, выход новых видео и даже получить эксклюзивные ништяки)
🔎 th-cam.com/channels/C-hfECZdghe_QNAJzztHEg.html - ссылка на канал моего младшего брата (подпишись если не сложно)
как купить курс?
@@OrbitaGames8 к сожалению, места на этот поток закончились, только в следующий:(
А что скажешь насчет VContainer и Reflex? Прост зенжект не поддерживается уже несколько лет вроде.
сОлид а не сАлид ОООООООО
Сколько не смотрел про DI и Zenject, в частности, туторов и статей, так и не понял плюсы от этих прокидываний зависимостей. Как по мне, все примеры его использования похожи на - Сначала сам себе выстрелю в ногу, затем обмотаю ее 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! Вы, пожалуй, первый в СНГ-сообществе кто довольно подробно и хорошо всё разъяснил) Прекрасная работа!
Я так конкретно и не понял для себя в чем преимущество Zenject :( Данные в монобех объект ведь можно и при его инициализации передавать и без конструктора. Так же тип ввода зависимо от девайса можно например в bootstrap классе или еще где прописать. единственный плюсом для себя выявил что удобнее проследить все байндинги и их чередование.
Тоже не особо понял. Но к примеру если мы берем управление, то между сценами его передавать можно сериализовав в файл типа конфига, а тут я так понимаю у зенжекта есть подобный инструмент, для хранения информации извне, чтобы передать его в другую сцену. И я подозреваю что Zenject делает это посредством DontDestroyOnLoad. Не знаю в общем. Типа удобная штука привлекает. Но отталкивает что все таки это стороннее, не юнитековское расширение.
автоматизация внедрения зависимостей и их резолв. Да, это всё можно делать ручками, но с автоматическими инструментами это удобнее.
Смотрел другие видео по данной теме и всё давалось сложно, но как только посмотрел разбор данной темы у тебя, так всё стало на места
Хорошее видео, однако стоит отметить что zenject 1) довольно тяжелый и медленный так как использует рефлексию под капотом. Байндинги можно запечь но это прям лишний слой сложности что делается крайне редко. 2) С недавних пор extenject перестал поддерживатся разработчиком.
И тем не менее это всё равно почти мастхэв в любом проекте
@@РусланУстименко-л1ц его уже заменяют на vcontainer, который полегче и попроще. Основная претензия к зенжекту, на самом деле, то, что он содержит много лишнего функционала, таким образом это не просто dic, а швейцарский нож.
@@РусланУстименко-л1ц так VContainer имеет почти все те же функции, но более производительный и поддерживается разработчиками
Вы бог, спасибо большое. Я недавно начал учить Unity и C#, кое что умею, но вот с архитектурой беда. Разобрался с ООП, SOLID, а что делать дальше не знаю, все равно путаюсь в своем же коде \ проекте, масштабировать тяжело. Будем учиться!
Тут только практика и опыт помогает, сам сейчас только и делаю, что накапливаю этот опыт и нейронные связи😂
Чуть не кончил, когда увидел как изыскано Zenject решает проблему. Теперь понятно почему у меня нету девушки :D
Тупой синглтон с кучей разрозненных объектов, которые где-то нужны и лень прокидывать.
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.
Автор отвечает только на комментарии с благодарностями людей, которые на самом деле ничего не поняли?
Азахххххаыпвахп
Очень жду дальнейшего раскрытия темы Zenject
- Жёстко зависит и мы ничего не можем сделать
-
- ...
- Profit?
Спасибо большое🔥
Шикарный урок!)
Как раз помогло мне ответить на один вопрос: нужен ли EntryPoint, если есть Zenject)
Спасибо за видос! Супер полезный инструмент, буду разбирать. Всю жизнь сам юмлки чертил и руками зависимости раскидывал, кучу времени отнимало)
Однозначно лайк, давай больше видосов про zenject
восап! Пришел закинуть пару слов о том, что ты большой молодец. Такого контента на ru ютубе не хватает, продолжай) уважение+, как говорится ✌️
Больше роликoв по Zenject!!!
Очень старался, но ничерта не поняя((( Видимо тормозила... было бы круто если кто нибудь поделиться живым примером на небольшом проекте использования zenjec... к сожалению так ничего полезного и не нашел. Спасибо
ждем лайфхаки)
Топ контент, спасибо!
Можно совет для чего его ещё использовать кроме Input-а?
В принципе, это прокидывание любых зависимостей) Тут все зависит от игры, если универсально, то всякие штуки для сохранения (например на разных веб платформах сохранения могут работать по разному и удобно подменять это дело). Какие нибудь штуки связанные с ресурсами и отображениями на интерфейсе, тот же самый кошелек я пример приводил в видео. Конфиги тоже удобно прокидывать. А так все что нужно для конкретно твоей игры, тут уж подсказать не могу)
@@-it394 спасибо за ответ с примерами!
Спасибо!
столько вопросов закрыл просто одной технологией, какая же красота. спасибо большое
не лучше ли сейчас использовать New Input System?
Забавно, почему-то я не слышал про зенжект на всяких туториалах на Ютубе...
Все поголовно сели на него, проблем он решить особо не помогает. Это как мода
В кое-то веке увидел человека который коротко и ясно ответил на вопрос: "На**я DI нужен в Unity?".
Пасеба ❤.
Илья, вы являетесь мидл или сеньер разработчиком?
Хороший урок, понимание предмета на неплохом уровне, я узнал для себя новое про зенжект. Спасибо)
Ох уж эти оопшники использующие zenject... Создавая паутину из кучи зависимостей.
Хм. А есть способы создать архитектуры без кучи зависимостей?
Впервые понял вообще всё в видосе по зенжекту
кто знает где скачать курс, дайте ссылку
Спасибо за видео! Буду рад увидеть видео с лайфхаками по Zenject
Понравилось что быстро и всё по делу
Крутое видео. Спасибо
очень круто объяснил, респект
А теперь бы знать как это все юзать вместе с тем же Netcode for GameObjects, там будет куча подводных камней, которые придется решать. Например спавнить объекты через зенжектовский или неткодовский Instantiate, или как, например, заинжектить зависимости на клиенте объекту который был создан на сервере, и так далее. Все эти проблемы можно, наверное, решать, но мне проще было отказаться от зенжекта в пользу старого доброго сервис локатора.
Опцій багато: юзати лейзіІнджект, робити в інсталері мануально резолв за потреби та інджект. Я от в DOTS в OnCreate() системи вимикаю їх, а в кастомному методі/проперті з [Inject] атрибутом приймаю залежність й вмикаю систему. Бо тут такий прикол, що не можна юзати конструктори ECS системи, бо в ЕСS власний ДІ контейнер. Тож я можу резолвити системи з цього ecs контейнеру в інсталері зенджекта й вже через контейнер зенджекта робити інджект в них. Є й інші варіанти.
Zenject не обновлялса уже несколько лет и врядле будет. Не продвигай то что уже умерло...
Он прекрасно работает тем не менее
Согласен, сейчас это может быть «Так работает же», а потом боль-боль-боль
Начнем с того, что даже масштабирование UI Unity много лет есть только для винды, тикеты висят на Мак и Линукс и всё
@@РусланТимченко-х1о работаю уже больше 4х лет на маке, все ок, полет нормальный
в чём отличие 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) делаю через ООП, но сама игровая логика с ООП вот вообще никак не стакается. Или же это бывает крайне редко, в определённых жанрах "по три в ряд". Всё равно по итогу всё выльется в многостроковое "если-то"
Vcontainer на данный момент выглядит перспективнее
Просто zenject неплохо занял позиции уже)
@@-it394 как занял так и сдает. Плюшки на бумаге которые предлагает VConainer весомые. Это вес и скорость работы. а все эти фреймворки используются только чтобы инжектить что то, остальное это перегруз. Хотя и Vcontainer хочет чтобы ты переходил на их архитектуру aka ecs
VContainer до 50 раз быстрее Znject, а видео по нему в рус сегменте нет...
мда.. тот самый момент, когда 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 статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?
4:37 что за случаи такие где нужно сущность передать в объект через несколько других? Что за случаи где используют синглтоны для данной задачи?
уважаемый, объяснять это не твое((
Ребят, лучше пройдите курс у Синдикатов, там то ребята по опытнее будут, чем этот маслёнок без опыта в продуктовой разработке
а как у вас с продуктовой разработкой? Где можно ознакомиться с вашими личными проектами? Желательно, классом от АА и выше.
Кроме "навальный вс путин", конечно..
@@Woolf530 можно совет как правильно прокидывать зависимости? Приведу пример: у меня в игре есть класс MenuHandler, от него наследуются MainMenuHandler и PauseMenuHandler, им обоим нужен ProgressKeeper для того чтобы знать текущий уровень и достигнутый уровень. Я сделал ProgressKeeper статическим, так как он один на всю игру и доступ к нему нужен со всех сцен. Всё работает, но я недавно услышал что статика это страшное зло, с которым нужно бороться. Что делать в таком случае?