Vertical Scroller - заключение, Паттерны на практике, DialogManager, Entry Point, Unity C# 

Согласен. В том же зенжекте все зависимости устанавливаются в тех же MonoInstaller, который етри поинтом и является. Впрочем у меня под одним из видео была жаркая дискуссия где оппонент доказывал, что сервис локатор имеет те же проблемы что и у синглтона и вообще используйте DI-контейнеры а не SL. Оппонент был во многом прав, но всё же я считаю что в некоторых местах SL вполне себе подходит)

Если у вас 5 типов окон, да, можно их создать и пусть лежат выключенными на сцене. Но надо контролировать за ними ссылки и чтобы не было каких-то условий чтобы одновременно на сцене не было 2х окон одного типа(например 2 окна шмотки, когда вы сравниваете новый и старый меч) Если же окон у вас много(100+), как в каком-нибудь Raid, то хранить всю эту портянку на сцене будет и визуально муторно и по памяти не очень. К тому же не стоит забывать что есть вложенные окна, когда одно окно является внутренним меню другого(инвентарь - инфо о предмете - окошко усиления предмета). Такое на сцене хранить будет крайне неудобно и сложно.

Декоратор в планах, где-то четвёртый в очереди

@@sergeykazantsev1655 Мда, на Адаптер лучше даже не тратить время

Почему?)

@@sergeykazantsev1655 Слишком элементарный и очевидный

Здравствуйте, я бы сказал, что зависит от того, будет ли общение по вашему проекту с работодателем. Если после отправки задания обязательно будет созвон с лидом который задаст вам вопросы по проекту - то можно. Просто вы на созвоне объясните что знаете, что сервис локатор много где считается антипаттерном, и что в целом все рекомендуют вместо него использовать DI-контейнер. Если же созвона не будет или есть высок риск что после отправки проекта до созвона не дойдет... Может нет смысла рисковать. Хотя несмотря на то, что у нас было под видео про сервис локаторов несколько жарких дискуссий где мне довольно конструктивно объясняли почему сервис локатор - антипаттерн, я всё ещё убеждён что для небольших проектов его можно использовать.

@@sergeykazantsev1655 Спасибо за ответ.

Ну если 5к подписчиков наберу - заведу) А пока нет особой нужды)

Пока курс делать не планирую, так как придумать полноценный курс на кучу видеоуроков, с домашкой, обратной связью, раскруткой рекламы и тд это не то же самое что раз 2-4 недели по вечерочкам собирать материал и заснять видосик. Ну и плюс у меня есть основная работа, а если делать курс, работу придётся бросать. А я этого пока не хочу)

@@sergeykazantsev1655 Спасибо, вы у нас на вес бриллиантов)

Проблема заключается в том, что если у вас игра зависит от порядка инициализирования систем и вы используете Script Execution Order - высока вероятность того, что в будущем у вас будут большие проблемы. Много систем будут зависеть друг от друга, правильный порядок инициализации настроить будет очень болезненно, в Script Execution Order попадёт больше половины написанных систем и огромную часть времени вы будете тратить не на модификацию или написание нового кода, а на распутывание этого порядка инициализации

А в чем разница прописать порядок инициализации систем в script order-е или через свежий класс bootstrap-a, entryPoint-a? Из далека действия очень похожи между собой...

Да, они действительно похожи между собой, но я бы сказал что тут проблема в наглядности и явности. Если у вас есть entry point или bootstrap, любой разработчик вступающий в команду сразу видит порядок вызовов. А если разработчик не в курсе, до идеи залезть в Script Execution Order он дойдет очень не сразу)

Получается какая-то аксиома Эскобара если сравнивать

Один из вариантов считается более прозрачным и нагглядным)

То есть если у тебя под тридцать разных окошек в игре, они все должны быть сразу на сцене? А модифицировать и переделывать окна как если префабов нет? Прямо на сцене? Как историю изменения префабов отслеживать?

@@sergeykazantsev1655 Да хоть 100500, какая разница, если они все аккурат разложены по папочкам с говорящей иерархией и имеют простую и понятную структуру, тем более что одновременно активны из них 1 - 4шт. И зачем кучу окон? Одно окно-оверлей для сообщений пользователю с гридом для кнопок (ошибка, инфо, вопрос (даже ввод цифр можно встроить)), другое для наград, третье для результатов игры... штучная вещь. Окна само переделываются исходня из входных данных (количество награды, иконки... небольшие изменения). Тем более что с того что они на сцене, не нужно тратиться на инстанцирование и удаление. Мутить ObjectPool както слишком мелко. Я не понимаю, зачем чтото программируется вручную, если для этого было сделана среда разработки, чтобы это разрабатывать мышкой через интерфейс. Тоже самое, что создавать массив, структуру, наделять его методами, когда можно воспользоваться готовым List.

Как я уже сказал есть несколько причин. Первая - это командная разработка. Если префабов окон нет, первый разработчик сделал новое окно А, а второй разработчик в этот же момент сделал новое окно Б, в главной ветке будет конфликт в файле сцены. Распутывать такое без префабов очень сложно. То же самое касается отслеживания истории изменений окна. По префабу легко и довольно удобно отследить мелкие точечные изменения (сделали шрифт побольше, цвет кнопки поменял и тд) - по сцене непонятно какой именно элемент поменялся Плюс есть окна которые используются в нескольких сценах. (Окна подтверждения, каких нибудь настроек и тд) - добавлять их на несколько сцен? А если окно изменилось, надо на каждую сцену переносить новое окно? А как если нет префаба

@@sergeykazantsev1655 Спасибо за разъяснения. Но. Чтото насчет командной разработки мутно объяснил) конфликты могут быть везде, если нет взаимосвязей и системы и возможностью бесконтрольно создавать. При окнах-объектах на сцене всё понятно - вот есть окно оверлей отвечающее за вывод инфу поверх всех окон, хочешь чтото сказать пользователю - узнай как оно работает и вызывай; вот окно результатов... нужно новое окно - обсуди, создай по подобию существующих; а создать префаб объекта и плюхнуть его на новую сцену, распаковав префаб - изи. Менеджер окон наконец мб с аля шиной эвентов. История? Гитхаб в помощь. Не знаю, ощущение, что создавать UI в Unity из кода из статичных данных это зашквар (простой в 90%).

Ну давай попробую яснее объяснить Есть два юнитолога в команде: Вася и Петя Васе надо сверстать окно YouWinDialog, Пете YouLoseDialog. Вася и Петя как правильные люди создают ветки от мастера в Гите, верстают окна и добавляют их как не префабы на сцену. Вася вливает свой диалог в ветку мастер, Петя пытается влить свою и бац, возникает мерж конфликт, потому что на месте куда Петя поставил youlosedialog, стоит Васин youwindialog И опять же, как ты по Гиту по истории гита поймёшь какие изменения ты сделал в том или ином окне? У тебя а истории будут изменения только в файле сцены