Звучит масштабно! Очень жду продолжения. Так же было бы интересно узнать, что хотя бы приблизительно представляет из себя архитектура действительно больших пректов, и какие для них существуют общие подходы и идеи.
Честно, я по опыту работал с малым количеством больших проектов. С одним, но три года :D На сколько я знаю, в среднем у многих встречается DI и Zenject, который каждая команда дотачивает под свои нужды. Некоторые конечно наворачивают лютую шайтан машину, выворачивая игру наизнанку, а кто-то тихенько сидит с синглтонами и как-то существует.
Очень здорово, надеюсь, проект получит развитие. Потому что в большинстве искомых примеров нет реальных случаев использования тех или иных практик и их углубления, а плоские примеры уровня "ну вот тут мы перетащим UI в скрипт прсонажа, а дальше подпишемся и вот весь наблюдатель"
Было бы интересно увидеть паттерны на практике. Если в теории MVP казался довольно понятным, то когда я начал применять его в тестовом задании, то столкнулся с кучей проблем.
Всегда ещё интерестно смотреть про собеседования, джун -мидл -сеньйор и вообше про техлидов , так что иногда можешь и про ето рассказать. Я подписался XD . Было бы круто узнать какие задачи дают каждый день.
Сергей, уточнить хотел бы уточнить про event bus, если про него не будет описан в будущем. Чем заменить можно Event bus? Я когда столкнулся с ним после изучения Action, то разбивал по объектам (ивенты для оружия, врагов и т.д.)
Предположу что если у нас в игре есть DI, то вместо Event Bus можно подписываться на ивенты внутри классов. Условно говоря когда мы инжектим в один класс другой, там эти ивенты и прокидываем. Но честно, пока других идей нет) Я и сам немного в замешательстве)
Да, постараюсь на днях выпустить видосик по ООП и займусь второй игрой в рубрике "Паттерны на практике" и там будет Zenject. Если получится - код будет через месяц, но всё может и затянуться
Пожелание к следующим видео: разобрать место анимации в архитектуре игры. Вроде бы понятно, что они относятся к View, но не до конца понятно в каком месте их лучше инициализировать и подписывать на какие либо события. Они должны находится в одном View или для них должен быть отдельный класс? Спасибо за очень крутые видосы!
Анимация явно должна быть на view, но если там очень очень много разной логики, можно вынести в отдельный класс который будет внутри этого самого view. Наверное, как-то так. Я попробую написать вторую игру с использованием MVVM для диалогов, не обещаю что это будет скоро, но постараюсь до этого дойти)
для увеличение времени просмотра - рекомендую изменить формат изложения . . .для этого нужно РЕАЛЬНО открыть Unity и там все излагать, причем со всеми настроечками для элементов - там их выше крыши . . . тогда за вами все начинающие будут реально повторять - например видео на 10 мин реально растянется на пол-часа
Спасибо за предложение, но я преследую другие цели. Я хочу наоборот делать короткие и содержательные видео, без мямленья, лишней информации и тд. Я сам лично когда ищу информацию в интернете, очень не люблю видео на полчаса и более.
@@sergeykazantsev1655 и я о том же - об коротком видео . . . но если в нем нужно НАБИРАТЬ код и самое главное - ДЕЛАТЬ настройки для элементов в Unity то пауз не обойтись и она растягивается надолго . .. ведь паттернов всего несколько десятков - и в каждом видео вы как бы закрываете тему их излагая . . а игроков для которых их можно применить - тьма.
А по вашему, есть существенное различие между использованием одного и того же паттерна в геймдеве или в проектировании БД? Или вы имеете ввиду что вам нужны паттерны, заточенные именно под БД?
@@sergeykazantsev1655 я думаю, что спагетти-код, который очень удобен программисту, когда он разрабатывает приложение, очень неудобен компании, которая уволив этого программиста, возьмет другого, и увидев этот спагетти код тот через месяц скажет, что это никчемное ПО и надо переписывать. Но: паттерны были созданы не для удобства разработчиков, давайте не будем лукавить, паттерны были созданы для удобства компаний, нанимающих разработчиков. Культура использования паттернов крайне противоречива, и "неписаных правил талмут", следование которой сродни путешествию по минному полю. Но никто не хочет признать за разработчиками роли исследователей(творцов) потому что им тогда нужно дать больше прав. Последние годы массовый ажиотаж на ИТ специалистов, но знание ли паттернов определяет успешного разработчика. Я извините, за последний месяц изучил три фреймворка и какие там паттерны(особеннов JS)?
@@sergeykazantsev1655 думаю, что разработчику удобнее сделать спагетти-код, который он оставит в наследие компании, где он работал, а пришедший вновь разработчик через пару месяцев работы с этим легаси заявит о том, что здесь все требует переделки. Паттерны - это некая культура взаимодействия в среде, которая хочет стать обыденной, но никак не может ей стать. И эта мода на программирование - когда кодить пытаются научить каждого таракана, так как для компаний разработчиков рабочий ресурс стал непомерно дорог. Я думаю, что паттерны это просто некий сигнал между специалистами, что они говорят на одном языке, однако нигде нет системного обучения этим паттернам. Или ты попадаешь в проект где с нуля нужно быстро что-то лепить или идешь в большой готовый проект и строишь его помаленьку
Ну чтож, на это я могу высказать только свое мнение - а уж вам решать - соглашаться или нет :) 1. 95% задач с которыми сталкиваются разработчики - не уникальны. Паттерны проектирования - это шаблоны решения этих задач. Паттерны проектирования позволяют каждый раз не изобретать велосипед, тем более что высока вероятность что если вы изобретете это сами -вы что-то забудете, недоучтете и придется модифицировать ваше решение несколько раз 2. С моей точки зрения успешного разработчика характеризуют такие черты как: скорость разработки, качество кода и количество проблем которые он может решить. Условно джун пишет медленно, качество кода так себе, и если бага нестандартная - он не знает как ее пофиксить. Сильный разраб пишет быстрее джуна, пишет качественнее и может решить даже неочевидную и глубокую проблему, написав модификацию какого-нибудь драйвера или плагин. Знание паттернов - улучшает качество и скорость разработки кода. 3. Я не понимаю почему вы противопоставляете интересы компаний и разработчиков. У компаний есть цель - разрабатывать продукт как можно быстрее и как можно качественнее. Разработчики подстраиваются под это и ищут решения как это сделать. Мне как разработчику тоже не нравится читать чужой спагетти код и в нем разбираться). Если же вы хотите быть исследователем и иметь полную свободу - пожалуйста - пилите собственные пет проекты, решения и код - экспериментируйте вдоволь.
Хочу взглянуть на Ваш проект но юнити просит скачать версию 2021, а меня жаба душит 6 гигов качать, как в таких случаях поступать, переключать на имеющую версию (2022) или лучше скачивать старую?
![Самый богатый человек в Вавилоне. Джордж Самюэль Клейсон. [Аудиокнига]](http://i.ytimg.com/vi/XEEvmlkPZUw/mqdefault.jpg)
![Quando Rondo - Grow Up [Official Music Video]](http://i.ytimg.com/vi/8zFnCg3BO4Q/mqdefault.jpg)
Звучит масштабно! Очень жду продолжения.
Так же было бы интересно узнать, что хотя бы приблизительно представляет из себя архитектура действительно больших пректов, и какие для них существуют общие подходы и идеи.
Честно, я по опыту работал с малым количеством больших проектов. С одним, но три года :D На сколько я знаю, в среднем у многих встречается DI и Zenject, который каждая команда дотачивает под свои нужды. Некоторые конечно наворачивают лютую шайтан машину, выворачивая игру наизнанку, а кто-то тихенько сидит с синглтонами и как-то существует.
Очень здорово, надеюсь, проект получит развитие. Потому что в большинстве искомых примеров нет реальных случаев использования тех или иных практик и их углубления, а плоские примеры уровня "ну вот тут мы перетащим UI в скрипт прсонажа, а дальше подпишемся и вот весь наблюдатель"
Сергей, спасибо за урок! Было бы интересно посмотреть про машину состояний.
Так! Я посмотрел только две минуты, и это уже лучший туториал по юнити, который я видел за последний год. Жду следующих видео.
Было бы интересно увидеть паттерны на практике. Если в теории MVP казался довольно понятным, то когда я начал применять его в тестовом задании, то столкнулся с кучей проблем.
С нетерпением буду ждать части про диалоговые окна и ui!
Отлично, очень рад что именно вы это сделаете))
Всегда ещё интерестно смотреть про собеседования, джун -мидл -сеньйор и вообше про техлидов
, так что иногда можешь и про ето рассказать. Я подписался XD . Было бы круто узнать какие задачи дают каждый день.
Большое спасибо. Это очень полезно
воу, будет классно, ждемс
особенно интересно посмотреть реализацию конфигов и их использование в коде)
Просто супер!
Интересная рубрика. Как раз практики не хватает.
Вот это подгон от ютуба. Туториалы здорового человека.
Большое дело делаешь, мен. Развиваешь русскоязычное паттернопонимае))
Огонь!
Отлично! Поехали! поярче давай
Звучит круто!
Спасибо
Только хотел написать когда новое видео))
Жду следующие видео.
Сергей, уточнить хотел бы уточнить про event bus, если про него не будет описан в будущем. Чем заменить можно Event bus? Я когда столкнулся с ним после изучения Action, то разбивал по объектам (ивенты для оружия, врагов и т.д.)
Предположу что если у нас в игре есть DI, то вместо Event Bus можно подписываться на ивенты внутри классов. Условно говоря когда мы инжектим в один класс другой, там эти ивенты и прокидываем. Но честно, пока других идей нет) Я и сам немного в замешательстве)
Хотелось услышать и узнать что-то интересное о Zenject. Так как в интернете если обобщить не так уж и много об его использовании. Спасибо за видео!
Да, постараюсь на днях выпустить видосик по ООП и займусь второй игрой в рубрике "Паттерны на практике" и там будет Zenject. Если получится - код будет через месяц, но всё может и затянуться
Огнищееееее!
Пожелание к следующим видео: разобрать место анимации в архитектуре игры. Вроде бы понятно, что они относятся к View, но не до конца понятно в каком месте их лучше инициализировать и подписывать на какие либо события. Они должны находится в одном View или для них должен быть отдельный класс? Спасибо за очень крутые видосы!
Анимация явно должна быть на view, но если там очень очень много разной логики, можно вынести в отдельный класс который будет внутри этого самого view. Наверное, как-то так.
Я попробую написать вторую игру с использованием MVVM для диалогов, не обещаю что это будет скоро, но постараюсь до этого дойти)
Очень интересная и полезная тема, но какой-то странный выбор паттернов
Спасибо, насчёт выбора паттернов, у меня есть некоторое видение и представление на основе моего опыта. Ему я и следую
для увеличение времени просмотра - рекомендую изменить формат изложения . . .для этого нужно РЕАЛЬНО открыть Unity и там все излагать, причем со всеми настроечками для элементов - там их выше крыши . . . тогда за вами все начинающие будут реально повторять - например видео на 10 мин реально растянется на пол-часа
Спасибо за предложение, но я преследую другие цели. Я хочу наоборот делать короткие и содержательные видео, без мямленья, лишней информации и тд. Я сам лично когда ищу информацию в интернете, очень не люблю видео на полчаса и более.
@@sergeykazantsev1655 и я о том же - об коротком видео . . . но если в нем нужно НАБИРАТЬ код и самое главное - ДЕЛАТЬ настройки для элементов в Unity то пауз не обойтись и она растягивается надолго . .. ведь паттернов всего несколько десятков - и в каждом видео вы как бы закрываете тему их излагая . . а игроков для которых их можно применить - тьма.
Зачем желать настройки если проект выложен на гитхаб и любой человек может все скачать и посмотреть что ему нужно?)
@@sergeykazantsev1655 спасибо . . . не знал за гитхаб
Наверное да, игровые приложения востребованы, но вот мне например нужны паттерны проектирования
с базами данных
А по вашему, есть существенное различие между использованием одного и того же паттерна в геймдеве или в проектировании БД?
Или вы имеете ввиду что вам нужны паттерны, заточенные именно под БД?
@@sergeykazantsev1655 я думаю, что спагетти-код, который очень удобен программисту, когда он разрабатывает приложение, очень неудобен компании, которая уволив этого программиста, возьмет другого, и увидев этот спагетти код тот через месяц скажет, что это никчемное ПО и надо переписывать.
Но: паттерны были созданы не для удобства разработчиков, давайте не будем лукавить, паттерны были созданы для удобства компаний, нанимающих разработчиков. Культура использования паттернов крайне противоречива, и "неписаных правил талмут", следование которой сродни путешествию по минному полю. Но никто не хочет признать за разработчиками роли исследователей(творцов) потому что им тогда нужно дать больше прав. Последние годы массовый ажиотаж на ИТ специалистов, но знание ли паттернов определяет успешного разработчика. Я извините, за последний месяц изучил три фреймворка и какие там паттерны(особеннов JS)?
@@sergeykazantsev1655 думаю, что разработчику удобнее сделать спагетти-код, который он оставит в наследие компании, где он работал, а пришедший вновь разработчик через пару месяцев работы с этим легаси заявит о том, что здесь все требует переделки.
Паттерны - это некая культура взаимодействия в среде, которая хочет стать обыденной, но никак не может ей стать. И эта мода на программирование - когда кодить пытаются научить каждого таракана, так как для компаний разработчиков рабочий ресурс стал непомерно дорог. Я думаю, что паттерны это просто некий сигнал между специалистами, что они говорят на одном языке, однако нигде нет системного обучения этим паттернам. Или ты попадаешь в проект где с нуля нужно быстро что-то лепить или идешь в большой готовый проект и строишь его помаленьку
Ну чтож, на это я могу высказать только свое мнение - а уж вам решать - соглашаться или нет :)
1. 95% задач с которыми сталкиваются разработчики - не уникальны. Паттерны проектирования - это шаблоны решения этих задач. Паттерны проектирования позволяют каждый раз не изобретать велосипед, тем более что высока вероятность что если вы изобретете это сами -вы что-то забудете, недоучтете и придется модифицировать ваше решение несколько раз
2. С моей точки зрения успешного разработчика характеризуют такие черты как: скорость разработки, качество кода и количество проблем которые он может решить. Условно джун пишет медленно, качество кода так себе, и если бага нестандартная - он не знает как ее пофиксить. Сильный разраб пишет быстрее джуна, пишет качественнее и может решить даже неочевидную и глубокую проблему, написав модификацию какого-нибудь драйвера или плагин. Знание паттернов - улучшает качество и скорость разработки кода.
3. Я не понимаю почему вы противопоставляете интересы компаний и разработчиков. У компаний есть цель - разрабатывать продукт как можно быстрее и как можно качественнее. Разработчики подстраиваются под это и ищут решения как это сделать. Мне как разработчику тоже не нравится читать чужой спагетти код и в нем разбираться). Если же вы хотите быть исследователем и иметь полную свободу - пожалуйста - пилите собственные пет проекты, решения и код - экспериментируйте вдоволь.
Хотелось бы увидеть от вас паттерн состояние
В планах)
Хочу взглянуть на Ваш проект но юнити просит скачать версию 2021, а меня жаба душит 6 гигов качать, как в таких случаях поступать, переключать на имеющую версию (2022) или лучше скачивать старую?
видео по Window Manager будет через месяц?
Думаю да, но когда выйдет видео по сервис локатору я опубликую проект на гитхабе и там это решение можно будет посмотреть