Спасибо за контент! Касательно entry point и composition root - это все про DI. Как раз читаю книжку по нему. И да в копозишн рут может полная шляпа твориться и это не всегда страшно.
Спасибо за видос! Наткнулся недавно на канал, пересмотрел все видео. Спасибо,что освящаете темы более продвинутого программирования, такие каналы, как вы - на вес золота сейчас в сегменте!
по сути весь DI очень удобно прокидывать через ентри поинт, там же использовать сервис локатор. Что убирает потребность в синглтонах, т.к. все зависимости теперь либо достаются из локатора, либо прокидываются в конструктор/инициализацию из ентри поинта.
Согласен. В том же зенжекте все зависимости устанавливаются в тех же MonoInstaller, который етри поинтом и является. Впрочем у меня под одним из видео была жаркая дискуссия где оппонент доказывал, что сервис локатор имеет те же проблемы что и у синглтона и вообще используйте DI-контейнеры а не SL. Оппонент был во многом прав, но всё же я считаю что в некоторых местах SL вполне себе подходит)
Здравствуйте. Хотел спросить, можно ли использовать Service Locator (и подобные сомнительные паттерны) для демонстрационного проекта, который будет оценивать работодатель? Насколько вообще это критично для джуна?
Здравствуйте, я бы сказал, что зависит от того, будет ли общение по вашему проекту с работодателем. Если после отправки задания обязательно будет созвон с лидом который задаст вам вопросы по проекту - то можно. Просто вы на созвоне объясните что знаете, что сервис локатор много где считается антипаттерном, и что в целом все рекомендуют вместо него использовать DI-контейнер. Если же созвона не будет или есть высок риск что после отправки проекта до созвона не дойдет... Может нет смысла рисковать. Хотя несмотря на то, что у нас было под видео про сервис локаторов несколько жарких дискуссий где мне довольно конструктивно объясняли почему сервис локатор - антипаттерн, я всё ещё убеждён что для небольших проектов его можно использовать.
Спасибо за классное видео! У меня вопрос по окнам: Почему нельзя держать всё диалоговые окна на канвасе в неактивном состоянии и просто Show/Hide их когда это необходимо? Мне даже тяжело вспомнить случай диалогового окна, которое не покажется за время жизни сцены… У окон Win/Lose - ~50% быть показанными. Т.е. я хочу спросить, в чём кроется главная проблема, которая вынуждает нас инстанциировать прифабы окон при их необходимости, а при закрытии дистроить их?
Если у вас 5 типов окон, да, можно их создать и пусть лежат выключенными на сцене. Но надо контролировать за ними ссылки и чтобы не было каких-то условий чтобы одновременно на сцене не было 2х окон одного типа(например 2 окна шмотки, когда вы сравниваете новый и старый меч) Если же окон у вас много(100+), как в каком-нибудь Raid, то хранить всю эту портянку на сцене будет и визуально муторно и по памяти не очень. К тому же не стоит забывать что есть вложенные окна, когда одно окно является внутренним меню другого(инвентарь - инфо о предмете - окошко усиления предмета). Такое на сцене хранить будет крайне неудобно и сложно.
Спасибо за инфу. А в чем реально проблема со script execution order? Everyone talks about this sh*t, but noone explains "почему плохо его использовать, и в чем реально состоит проблема?"
Проблема заключается в том, что если у вас игра зависит от порядка инициализирования систем и вы используете Script Execution Order - высока вероятность того, что в будущем у вас будут большие проблемы. Много систем будут зависеть друг от друга, правильный порядок инициализации настроить будет очень болезненно, в Script Execution Order попадёт больше половины написанных систем и огромную часть времени вы будете тратить не на модификацию или написание нового кода, а на распутывание этого порядка инициализации
А в чем разница прописать порядок инициализации систем в script order-е или через свежий класс bootstrap-a, entryPoint-a? Из далека действия очень похожи между собой...
Да, они действительно похожи между собой, но я бы сказал что тут проблема в наглядности и явности. Если у вас есть entry point или bootstrap, любой разработчик вступающий в команду сразу видит порядок вызовов. А если разработчик не в курсе, до идеи залезть в Script Execution Order он дойдет очень не сразу)
Пока курс делать не планирую, так как придумать полноценный курс на кучу видеоуроков, с домашкой, обратной связью, раскруткой рекламы и тд это не то же самое что раз 2-4 недели по вечерочкам собирать материал и заснять видосик. Ну и плюс у меня есть основная работа, а если делать курс, работу придётся бросать. А я этого пока не хочу)
"Странно пропихивать префабы окон в gamecontroller"? А не странно ли гавнокодить окна вручную в инструменте, который предоставляет возможность создания и управления окнами посредством UI Editor, чтобы не нужно было гавнокодить их вручную. Да и зачем префабы, просто включать/отключать объекты на сцене (окна).
То есть если у тебя под тридцать разных окошек в игре, они все должны быть сразу на сцене? А модифицировать и переделывать окна как если префабов нет? Прямо на сцене? Как историю изменения префабов отслеживать?
@@sergeykazantsev1655 Да хоть 100500, какая разница, если они все аккурат разложены по папочкам с говорящей иерархией и имеют простую и понятную структуру, тем более что одновременно активны из них 1 - 4шт. И зачем кучу окон? Одно окно-оверлей для сообщений пользователю с гридом для кнопок (ошибка, инфо, вопрос (даже ввод цифр можно встроить)), другое для наград, третье для результатов игры... штучная вещь. Окна само переделываются исходня из входных данных (количество награды, иконки... небольшие изменения). Тем более что с того что они на сцене, не нужно тратиться на инстанцирование и удаление. Мутить ObjectPool както слишком мелко. Я не понимаю, зачем чтото программируется вручную, если для этого было сделана среда разработки, чтобы это разрабатывать мышкой через интерфейс. Тоже самое, что создавать массив, структуру, наделять его методами, когда можно воспользоваться готовым List.
Как я уже сказал есть несколько причин. Первая - это командная разработка. Если префабов окон нет, первый разработчик сделал новое окно А, а второй разработчик в этот же момент сделал новое окно Б, в главной ветке будет конфликт в файле сцены. Распутывать такое без префабов очень сложно. То же самое касается отслеживания истории изменений окна. По префабу легко и довольно удобно отследить мелкие точечные изменения (сделали шрифт побольше, цвет кнопки поменял и тд) - по сцене непонятно какой именно элемент поменялся Плюс есть окна которые используются в нескольких сценах. (Окна подтверждения, каких нибудь настроек и тд) - добавлять их на несколько сцен? А если окно изменилось, надо на каждую сцену переносить новое окно? А как если нет префаба
@@sergeykazantsev1655 Спасибо за разъяснения. Но. Чтото насчет командной разработки мутно объяснил) конфликты могут быть везде, если нет взаимосвязей и системы и возможностью бесконтрольно создавать. При окнах-объектах на сцене всё понятно - вот есть окно оверлей отвечающее за вывод инфу поверх всех окон, хочешь чтото сказать пользователю - узнай как оно работает и вызывай; вот окно результатов... нужно новое окно - обсуди, создай по подобию существующих; а создать префаб объекта и плюхнуть его на новую сцену, распаковав префаб - изи. Менеджер окон наконец мб с аля шиной эвентов. История? Гитхаб в помощь. Не знаю, ощущение, что создавать UI в Unity из кода из статичных данных это зашквар (простой в 90%).
Ну давай попробую яснее объяснить Есть два юнитолога в команде: Вася и Петя Васе надо сверстать окно YouWinDialog, Пете YouLoseDialog. Вася и Петя как правильные люди создают ветки от мастера в Гите, верстают окна и добавляют их как не префабы на сцену. Вася вливает свой диалог в ветку мастер, Петя пытается влить свою и бац, возникает мерж конфликт, потому что на месте куда Петя поставил youlosedialog, стоит Васин youwindialog И опять же, как ты по Гиту по истории гита поймёшь какие изменения ты сделал в том или ином окне? У тебя а истории будут изменения только в файле сцены
![Quando Rondo - Grow Up [Official Music Video]](http://i.ytimg.com/vi/8zFnCg3BO4Q/mqdefault.jpg)
Комментарий в поддержку канала. Смотреть будем потом)))
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
Я сейчас пробежусь по всем видео и каждому лайк поставлю. Ты топ! Продолжай за MVVP, MVP огромное спасибо. Просто пушка.
Спасибо за контент!
Касательно entry point и composition root - это все про DI. Как раз читаю книжку по нему.
И да в копозишн рут может полная шляпа твориться и это не всегда страшно.
Спасибо за видос!
Наткнулся недавно на канал, пересмотрел все видео.
Спасибо,что освящаете темы более продвинутого программирования, такие каналы, как вы - на вес золота сейчас в сегменте!
Царский лайк!
Очень долго не тыкал в юнити потому что было непонятно как писать по науке без драга префабов в инспектор (;
по сути весь DI очень удобно прокидывать через ентри поинт, там же использовать сервис локатор. Что убирает потребность в синглтонах, т.к. все зависимости теперь либо достаются из локатора, либо прокидываются в конструктор/инициализацию из ентри поинта.
Согласен. В том же зенжекте все зависимости устанавливаются в тех же MonoInstaller, который етри поинтом и является.
Впрочем у меня под одним из видео была жаркая дискуссия где оппонент доказывал, что сервис локатор имеет те же проблемы что и у синглтона и вообще используйте DI-контейнеры а не SL. Оппонент был во многом прав, но всё же я считаю что в некоторых местах SL вполне себе подходит)
Здравствуйте. Хотел спросить, можно ли использовать Service Locator (и подобные сомнительные паттерны) для демонстрационного проекта, который будет оценивать работодатель? Насколько вообще это критично для джуна?
Здравствуйте, я бы сказал, что зависит от того, будет ли общение по вашему проекту с работодателем.
Если после отправки задания обязательно будет созвон с лидом который задаст вам вопросы по проекту - то можно. Просто вы на созвоне объясните что знаете, что сервис локатор много где считается антипаттерном, и что в целом все рекомендуют вместо него использовать DI-контейнер.
Если же созвона не будет или есть высок риск что после отправки проекта до созвона не дойдет... Может нет смысла рисковать.
Хотя несмотря на то, что у нас было под видео про сервис локаторов несколько жарких дискуссий где мне довольно конструктивно объясняли почему сервис локатор - антипаттерн, я всё ещё убеждён что для небольших проектов его можно использовать.
@@sergeykazantsev1655 Спасибо за ответ.
Уважаемый товарисч джедай, будут ли ролики про паттерны Адаптер, Декоратор, Proxy?
Декоратор в планах, где-то четвёртый в очереди
@@sergeykazantsev1655 Мда, на Адаптер лучше даже не тратить время
Почему?)
@@sergeykazantsev1655 Слишком элементарный и очевидный
Спасибо за классное видео! У меня вопрос по окнам:
Почему нельзя держать всё диалоговые окна на канвасе в неактивном состоянии и просто Show/Hide их когда это необходимо? Мне даже тяжело вспомнить случай диалогового окна, которое не покажется за время жизни сцены… У окон Win/Lose - ~50% быть показанными. Т.е. я хочу спросить, в чём кроется главная проблема, которая вынуждает нас инстанциировать прифабы окон при их необходимости, а при закрытии дистроить их?
Если у вас 5 типов окон, да, можно их создать и пусть лежат выключенными на сцене. Но надо контролировать за ними ссылки и чтобы не было каких-то условий чтобы одновременно на сцене не было 2х окон одного типа(например 2 окна шмотки, когда вы сравниваете новый и старый меч)
Если же окон у вас много(100+), как в каком-нибудь Raid, то хранить всю эту портянку на сцене будет и визуально муторно и по памяти не очень.
К тому же не стоит забывать что есть вложенные окна, когда одно окно является внутренним меню другого(инвентарь - инфо о предмете - окошко усиления предмета). Такое на сцене хранить будет крайне неудобно и сложно.
Спасибо за инфу.
А в чем реально проблема со script execution order?
Everyone talks about this sh*t, but noone explains "почему плохо его использовать, и в чем реально состоит проблема?"
Проблема заключается в том, что если у вас игра зависит от порядка инициализирования систем и вы используете Script Execution Order - высока вероятность того, что в будущем у вас будут большие проблемы. Много систем будут зависеть друг от друга, правильный порядок инициализации настроить будет очень болезненно, в Script Execution Order попадёт больше половины написанных систем и огромную часть времени вы будете тратить не на модификацию или написание нового кода, а на распутывание этого порядка инициализации
А в чем разница прописать порядок инициализации систем в script order-е или через свежий класс bootstrap-a, entryPoint-a?
Из далека действия очень похожи между собой...
Да, они действительно похожи между собой, но я бы сказал что тут проблема в наглядности и явности. Если у вас есть entry point или bootstrap, любой разработчик вступающий в команду сразу видит порядок вызовов. А если разработчик не в курсе, до идеи залезть в Script Execution Order он дойдет очень не сразу)
Получается какая-то аксиома Эскобара если сравнивать
Один из вариантов считается более прозрачным и нагглядным)
6:52 непонятно за что grade отвечает, там везде 0
grade опять же нужен на будущее, если препятсвия планируются быть сложнее в дальнейшем. Например супер мины или супер аптечки
Нравятся ваши видео, не думали завести тг канал?
Ну если 5к подписчиков наберу - заведу) А пока нет особой нужды)
Сергей, вы собираете делать свой курс, или вы настоко щедрый,что бесплатно и дальше будите выкладывать такие хорошие уроки.
Пока курс делать не планирую, так как придумать полноценный курс на кучу видеоуроков, с домашкой, обратной связью, раскруткой рекламы и тд это не то же самое что раз 2-4 недели по вечерочкам собирать материал и заснять видосик.
Ну и плюс у меня есть основная работа, а если делать курс, работу придётся бросать. А я этого пока не хочу)
@@sergeykazantsev1655 Спасибо, вы у нас на вес бриллиантов)
"Странно пропихивать префабы окон в gamecontroller"? А не странно ли гавнокодить окна вручную в инструменте, который предоставляет возможность создания и управления окнами посредством UI Editor, чтобы не нужно было гавнокодить их вручную. Да и зачем префабы, просто включать/отключать объекты на сцене (окна).
То есть если у тебя под тридцать разных окошек в игре, они все должны быть сразу на сцене?
А модифицировать и переделывать окна как если префабов нет? Прямо на сцене? Как историю изменения префабов отслеживать?
@@sergeykazantsev1655
Да хоть 100500, какая разница, если они все аккурат разложены по папочкам с говорящей иерархией и имеют простую и понятную структуру, тем более что одновременно активны из них 1 - 4шт.
И зачем кучу окон? Одно окно-оверлей для сообщений пользователю с гридом для кнопок (ошибка, инфо, вопрос (даже ввод цифр можно встроить)), другое для наград, третье для результатов игры... штучная вещь. Окна само переделываются исходня из входных данных (количество награды, иконки... небольшие изменения).
Тем более что с того что они на сцене, не нужно тратиться на инстанцирование и удаление. Мутить ObjectPool както слишком мелко.
Я не понимаю, зачем чтото программируется вручную, если для этого было сделана среда разработки, чтобы это разрабатывать мышкой через интерфейс. Тоже самое, что создавать массив, структуру, наделять его методами, когда можно воспользоваться готовым List.
Как я уже сказал есть несколько причин. Первая - это командная разработка. Если префабов окон нет, первый разработчик сделал новое окно А, а второй разработчик в этот же момент сделал новое окно Б, в главной ветке будет конфликт в файле сцены. Распутывать такое без префабов очень сложно.
То же самое касается отслеживания истории изменений окна. По префабу легко и довольно удобно отследить мелкие точечные изменения (сделали шрифт побольше, цвет кнопки поменял и тд) - по сцене непонятно какой именно элемент поменялся
Плюс есть окна которые используются в нескольких сценах. (Окна подтверждения, каких нибудь настроек и тд) - добавлять их на несколько сцен? А если окно изменилось, надо на каждую сцену переносить новое окно? А как если нет префаба
@@sergeykazantsev1655
Спасибо за разъяснения. Но. Чтото насчет командной разработки мутно объяснил) конфликты могут быть везде, если нет взаимосвязей и системы и возможностью бесконтрольно создавать. При окнах-объектах на сцене всё понятно - вот есть окно оверлей отвечающее за вывод инфу поверх всех окон, хочешь чтото сказать пользователю - узнай как оно работает и вызывай; вот окно результатов... нужно новое окно - обсуди, создай по подобию существующих; а создать префаб объекта и плюхнуть его на новую сцену, распаковав префаб - изи. Менеджер окон наконец мб с аля шиной эвентов. История? Гитхаб в помощь.
Не знаю, ощущение, что создавать UI в Unity из кода из статичных данных это зашквар (простой в 90%).
Ну давай попробую яснее объяснить
Есть два юнитолога в команде: Вася и Петя
Васе надо сверстать окно YouWinDialog, Пете YouLoseDialog.
Вася и Петя как правильные люди создают ветки от мастера в Гите, верстают окна и добавляют их как не префабы на сцену. Вася вливает свой диалог в ветку мастер, Петя пытается влить свою и бац, возникает мерж конфликт, потому что на месте куда Петя поставил youlosedialog, стоит Васин youwindialog
И опять же, как ты по Гиту по истории гита поймёшь какие изменения ты сделал в том или ином окне? У тебя а истории будут изменения только в файле сцены