- Мне нравятся эти сложные синтетические объяснения паттернов на том же рефакторинг гуру, чтобы в конечном итоге понять, что например декоратор - это наследование от класса, который виртуально реализовывает интерфейс. Вместо этого простого предложения там городят какой-то марсианский огород в форме большого и длинного - Недавно наткнулся на ваш канал, и очень рад находке. До этого слонялся по англоговорящему ютубу и безуспешно пытался отфильтровать инфоцыган от людей с настоящим опытом. А здесь одним ухом слушал, другим был где-то далеко, и всё равно всё понял. Благодарю за материал
Замечательно и понятно всё! Правильно ли я понимаю суть абстракции? Декоратор - в переводе маляр или поклейщик обоев. Как бы получается "изменяющий снаружи", не меняющий внутренней сути стены. Логично предполагать что в рамках паттерна - он меняет свойства или обработку того, на что накладывается и не учитывает то, что есть другие декораторы. Но если есть необходимость в декораторе учитывать наличие других декораторов - это можно сделать? Мне почему то кажется что это в принципе невозможно, так как декораторы условно говоря друг о друге ничего не знают. Единственное что приходит на ум - это прокидывать внутри самого вызова нужного декорируемого метода какую-то переменную стек вызова и там сообщать о каждом этапе....
Классный урок, спасибо. Вопрос таки есть) Можно ли через декоратор реализовать конвертацию отдельного типа урона или для этой задачи есть более подходящая реализация?
Благодарю за видео. Хотелось бы еще знать в реализациях каких фич (помимо нанесения разного урона) используют данный паттерн и другие . И часто ли бывают ситуации, когда на реализацию одной и той же фичи претендует сразу 2 паттерна и уже в зависимости от нюансов конкретного проекта используется тот или иной
Этот паттерн удобен для объектов, которым надо сгенерировать функционал, и наследование для этого не подходит, т.к. требуется реаливать динамическую генерацию функционала. Да, звучит сложно но по факту: абилки, зелья, оружие, все что даёт какие-то бафы, которые нужно генерировать. Второе - часто ли претендуют 2 паттерна. Не часто, и нюансы конкретного проекта как раз и помогают определиться в выборе. Когда есть ТЗ - то выбираешь исходя из того, что нужно сделать чтобы ТЗ было выполнено)
Для примера без разницы на самом деле, что использовать. Но тема хорошая да, инструмент удобный (не понимаю, почему юнити сами не впилили что-то подобное в свои асинки)
@@yaroslavmakarov2218 мне была интересна твоя версия) юнитаски, таски и корутины делают одно и тоже, разными путями. Вот мне и стало интересно, чем же корутины лучше) Корутинами пользуются в основном начинающие и в логике представления, в доменном слое логичнее использовать таски
Если можно, то прошу рассмотреть в одом из следующих видео такую тему, как максимально сократить зависимость классов от MonoBehaviour. Часто такое слышал, но в основном на русскоговорящих каналах, но как именно это реализовать не рассказывают. Например, Максим Крюков точно об этом говорил... кто еще не помню, но точно где то еще слышал. За материал и труды по просвещению русскоговорящего сообщества Unity большое спасибо!
@@MrKingofTiger там обычно не говорится именно о ECS. Обычно это все таки монобихевиор, но как я понял не на всех объектах/компонентах. Еще иногда видел попытки отвязки от монобихевиора но с применением, например, интерфейса IUpdateble, который не имеет своего Update метода (и не наследуется от монобихевиора), но все объекты реализующие этот интерфейс перебираются циклом в объекте имеющим Update моно.
Возможно стоит посмотреть в сторону Zenject, он позволяет создавать классы с методом Tick(), который аналогичен Update(), но без использования MonoBehaviour. Ну и помимо этого, в zenject полно всего интересного :)
Отвязывание от монобехов - это не про зенжект или ECS. Это построение архитектуры приложения-игры таким образом, чтобы сам движок выполнял только косметическую роль и принимал инпут. Архитектур великое множество, но однозначности в этом вопросе нет. Пожалуй, нужен видос об этом)
Отличное видео, но есть вопрос: при апгрейде вы все время переопределяете одну и ту же абилку, а как потом убрать какой-либо функционал? Например сняли сапоги электричества и нужно убрать урон от электричества.
Хорошее видео, спасибо. Возник вопрос: можно ли реализовать этот шаблон на MonoBehaviour? Имею в виду, не через привязку ссылок через инспектор по аналогии передачи декорируемой сущности в конструктор декоратора(не MonoBeh), а каким-то проверенным через код способом. Например, есть компоненты BaseDamage, ElectricDamageDecorator и WaterDamageDecorator на объекте, у ElectricDamageDecorator и WaterDamageDecorator явно указана ссылка на BaseDamage, в остальном стандартная декораторная логика работы. Главный недостаток тут что ссылки нужно задавать явно, ручками, через инспектор, а это не труЪ. То есть в идеале схема такая: базовый компонент и декораторы висят на одном GameObject, и порядок декорации каждый из них знает и делают это без явной привязки ссылок через инспектор.
@@Danak471 @user-ml5tn8qn8j @sinlessdevil5970 Zenject не для этого сделан. Он не выполнит описанных тут задач, даже если постарайтесь. Плюс опять же, порядок не гарантирован
Я конечно не так давно начал изучать Unity, но возник вопрос. Если столько файлов(классов) требуется создать на одну механику получение урона, то сколько их может быть на финальной стадии создания РПГ игры ?
- Мне нравятся эти сложные синтетические объяснения паттернов на том же рефакторинг гуру, чтобы в конечном итоге понять, что например декоратор - это наследование от класса, который виртуально реализовывает интерфейс. Вместо этого простого предложения там городят какой-то марсианский огород в форме большого и длинного
- Недавно наткнулся на ваш канал, и очень рад находке. До этого слонялся по англоговорящему ютубу и безуспешно пытался отфильтровать инфоцыган от людей с настоящим опытом. А здесь одним ухом слушал, другим был где-то далеко, и всё равно всё понял. Благодарю за материал
смотрю канал как сериал. В этом эпизое автор наконец заменил this. на подчеркивание!! Ура!!!
Здравствуйте. А можно попросить Вас, сделать видео на тему "как правильно декомпозировать программу на классы, интерфейсы".
В цикле waitforseconds генерит мусор лучше кешировать
Опана , подъехала годнота)
Просто прекрасные уроки! Почему так мало подписчиков?!
Замечательно и понятно всё!
Правильно ли я понимаю суть абстракции? Декоратор - в переводе маляр или поклейщик обоев. Как бы получается "изменяющий снаружи", не меняющий внутренней сути стены.
Логично предполагать что в рамках паттерна - он меняет свойства или обработку того, на что накладывается и не учитывает то, что есть другие декораторы. Но если есть необходимость в декораторе учитывать наличие других декораторов - это можно сделать? Мне почему то кажется что это в принципе невозможно, так как декораторы условно говоря друг о друге ничего не знают. Единственное что приходит на ум - это прокидывать внутри самого вызова нужного декорируемого метода какую-то переменную стек вызова и там сообщать о каждом этапе....
чет я пропустил, а где мы создавали/брали widgetDamagePrefab? вообще с чатью про юай не понятно.(
Обожаю ваши видео, спасибо за то что вы делаете!!!
не понятно ничего какая строчка отвечает за что, суть - важная механика, работа скриптов, а точнее как реализуется, не понятно
автор так и не скинул ссылку на урок где он использовал корутину без монобехи
короче вот он
th-cam.com/video/kc-2X_HmtUM/w-d-xo.html
Классный урок, спасибо. Вопрос таки есть) Можно ли через декоратор реализовать конвертацию отдельного типа урона или для этой задачи есть более подходящая реализация?
Не очень понятна задача) что значит конвертация урона? Если похожая задача что и в примере обсуждается, то конечно да)
Благодарю за видео. Хотелось бы еще знать в реализациях каких фич (помимо нанесения разного урона) используют данный паттерн и другие . И часто ли бывают ситуации, когда на реализацию одной и той же фичи претендует сразу 2 паттерна и уже в зависимости от нюансов конкретного проекта используется тот или иной
Этот паттерн удобен для объектов, которым надо сгенерировать функционал, и наследование для этого не подходит, т.к. требуется реаливать динамическую генерацию функционала. Да, звучит сложно но по факту: абилки, зелья, оружие, все что даёт какие-то бафы, которые нужно генерировать.
Второе - часто ли претендуют 2 паттерна. Не часто, и нюансы конкретного проекта как раз и помогают определиться в выборе. Когда есть ТЗ - то выбираешь исходя из того, что нужно сделать чтобы ТЗ было выполнено)
@@gamedevlavka благодарю за ответ. Все понятно
Хотелось по-больше размер текста кода.
Что-то я не уследил. Будет)
Циферки, которые выскакивают вообще топ. И анимация крутая. Как в доте.
Спасибо, очень интересно и полезно. Ты использовал корутину, возможно удобней использовать UniTask, запиши про этот инструмент ролик.
Для примера без разницы на самом деле, что использовать.
Но тема хорошая да, инструмент удобный (не понимаю, почему юнити сами не впилили что-то подобное в свои асинки)
Корутины надежнее
@@yaroslavmakarov2218 чем?
@@gamedevlavka Погугли. В целом и юнитаски можно настроить грамотно, но для среднего юнити-школяра лучше корутины)
@@yaroslavmakarov2218 мне была интересна твоя версия) юнитаски, таски и корутины делают одно и тоже, разными путями. Вот мне и стало интересно, чем же корутины лучше)
Корутинами пользуются в основном начинающие и в логике представления, в доменном слое логичнее использовать таски
Если можно, то прошу рассмотреть в одом из следующих видео такую тему, как максимально сократить зависимость классов от MonoBehaviour. Часто такое слышал, но в основном на русскоговорящих каналах, но как именно это реализовать не рассказывают. Например, Максим Крюков точно об этом говорил... кто еще не помню, но точно где то еще слышал.
За материал и труды по просвещению русскоговорящего сообщества Unity большое спасибо!
ECS
@@MrKingofTiger там обычно не говорится именно о ECS. Обычно это все таки монобихевиор, но как я понял не на всех объектах/компонентах. Еще иногда видел попытки отвязки от монобихевиора но с применением, например, интерфейса IUpdateble, который не имеет своего Update метода (и не наследуется от монобихевиора), но все объекты реализующие этот интерфейс перебираются циклом в объекте имеющим Update моно.
Возможно стоит посмотреть в сторону Zenject, он позволяет создавать классы с методом Tick(), который аналогичен Update(), но без использования MonoBehaviour. Ну и помимо этого, в zenject полно всего интересного :)
Отвязывание от монобехов - это не про зенжект или ECS. Это построение архитектуры приложения-игры таким образом, чтобы сам движок выполнял только косметическую роль и принимал инпут. Архитектур великое множество, но однозначности в этом вопросе нет. Пожалуй, нужен видос об этом)
Дякую за урок, дуже інформативно ("+1 патерн в копілку"), якщо получиться наступний відос щось звязане з , напевно оригінальна функція називається.
Имеется ввиду генерик классы и методы?
@@gamedevlavka Напевно)
@@domiurk про генерик классы есть вроде видео на канале)
@@gamedevlavka Аааа знайшов, Дякую)
недурно, спасибо за урок.
Спасибо большое!
Ровно то, что мне было нужно)
так как использовать корутину без MonoBehaviour?
Отличное видео, но есть вопрос: при апгрейде вы все время переопределяете одну и ту же абилку, а как потом убрать какой-либо функционал? Например сняли сапоги электричества и нужно убрать урон от электричества.
Все базы хранятся в массиве, и заворачивать предыдущий урон в новый, проходя по массиву. Удаляешь баф из массива, пересчитываешь урон и вот ото
Не нашел скрипт Coroutines. Прикрепи, если можешь)
th-cam.com/video/kc-2X_HmtUM/w-d-xo.html
Хорошее видео, спасибо. Возник вопрос: можно ли реализовать этот шаблон на MonoBehaviour? Имею в виду, не через привязку ссылок через инспектор по аналогии передачи декорируемой сущности в конструктор декоратора(не MonoBeh), а каким-то проверенным через код способом.
Например, есть компоненты BaseDamage, ElectricDamageDecorator и WaterDamageDecorator на объекте, у ElectricDamageDecorator и WaterDamageDecorator явно указана ссылка на BaseDamage, в остальном стандартная декораторная логика работы. Главный недостаток тут что ссылки нужно задавать явно, ручками, через инспектор, а это не труЪ.
То есть в идеале схема такая: базовый компонент и декораторы висят на одном GameObject, и порядок декорации каждый из них знает и делают это без явной привязки ссылок через инспектор.
К сожалению, если говорить о монобехах, то выстроить порядок без прямых ссылок не выйдет красивым способом
Я могу ошибаться , но попробую почитать про zenject. Может поможет решить твою проблему
@@sinlessdevil5970 zenject отличная тебя для следующего видео)
Спасибо за ответы!
@@Danak471 @user-ml5tn8qn8j @sinlessdevil5970 Zenject не для этого сделан. Он не выполнит описанных тут задач, даже если постарайтесь. Плюс опять же, порядок не гарантирован
Я конечно не так давно начал изучать Unity, но возник вопрос. Если столько файлов(классов) требуется создать на одну механику получение урона, то сколько их может быть на финальной стадии создания РПГ игры ?
Достаточно много, но напрямую зависит от количества типов урона
Я думаю декораторы создаются потом через билдеры и ты не прописываешь каждый декоратор, а собираешь с уже готовых кусочков
А где найти класс Coroutines? Хочу попробовать в своих проектах
th-cam.com/video/kc-2X_HmtUM/w-d-xo.html