В одном из видео с официальных курсов по анрилу прямо сказано, что именно Event Dispatcher реализуют паттерн Observer. Хотя интерфейсы довольно универсальный инструмент, его хорошо для Strategy использовать, когда множество разношерстных акторов, чтобы удобнее было реализовывать расширение и изменение функционала. Все эти выборки всех объектов класса или интерфейсов рекомендуется по возможности вообще не использовать. И спасибо за интересный урок, подписался.
Огромное тебе спасибо, добрый человек. Я две недели пытался безуспешно решить задачу для своего приложения, и оказалось, что она очень легко решается с помощью интерфейсов и паттерна обсервер! Огромный лайк с меня!!!! Жду следующих уроков, поставил колокольчик!
09:45 Если кто не будет понимать почему не находятся эвенты от интерфейса - их в поиске нету, нужно нажать правой клавишей мыши в левом меню Interfaces, по нужному, и выбрать Implement Event.
Первое. Тебе дизлайк за то, что удаляешь аргументированную критику без оскорблений на своём канале. Боишься, что школьники донатить перестанут? Второе. Если человек не знает, как имплементить интерфейс в движке, хотя это интуитивно понятно, и, простите, написано прямым текстом, пусть и по-английски, значит, ему ещё вообще рано изучать паттерны.
Разве можно сказать, что блупринт интерфейсы в анриле работают, как паттерн Observer? В рамках этого паттерна, как я думал, должен быть реализован механизм "подписки" - подписанные объекты следят и реагируют на события, происходящие в объекте, на который они подписаны. Event Dispatchers лучше подходят для демонстрации данного паттерна.
Божечки, неужели нормальный русскоязычный канал по анрилу без бе-ме, воды и школьников. Автор не останавливайся! Хочу смотреть как правильно делать частичную разрушаемость от пуль через Unreal Chaos , процедурно генерировать помещения из комнат и остальные паттерны жду с нетерпением! Лайк, подписка.
Уважаемый, поясните вкратце, в чём принципиальное отличие эвент диспетчеров от интерфейсов? Из всех видео по этим элементам получается, что они в некотором смысле идентичны, т.е поставленную задачу можно легко и непринуждённо реализовать как ЭД, так и интерфейсами.
Observer это патерн про делегаты (диспатчеры), а интерфейсы это Strategy патерн. Я бы на вашем месте удалил это видео чтобы не позориться либо исправил ошибку. Касательно кода get all actors это тяжелый метод, использование которого мягко скажем не оправдано. Сама идея "анонимности" и заменяемости конечно как бы соблюдается (иначе смысла использовать интерфейс вообще бы не было), но я бы не назвал такое решение хорошей практикой. Вообще то что вы сделали больше похоже на Chain of responsibility патерн: перебор клиентов, которые сами решают реагировать им на событие или нет. Только там бы использовался break наверное.
К сожалению, очень слабо. Видно, что базы у тебя практически нет, раз в самом простом паттерне (после шаблонного метода и одиночки) ты плаваешь. Но могу утешить, лучше, чем у всех остальных, что я видел. Если другие - это вообще детский сад, то у тебя уровень начальной школы, что уже неплохо. Теперь по сути. Первое. Интерфейсы вот так не используют. Могу много писать, но просто пример. У тебя в боссе ищутся все объекты с интерфейсом. А что если кому-нибудь ещё потребуется информация о том, что босс умер? Но при этом ему не нужны твои "входы и выходы в ловушку". Реализовать весь этот интерфейс в новом объекте? Так это нарушение одного из принципов SOLID. Дописать поиск ещё всех других объектов с другим интерфейсом? Так это нарушение принципа открытости-закрытости. Поэтому плавно вытекает второе. Никакого отношения вот этот пример к Observer не имеет. Для Observer в движке есть Event Dispatcher. Любой объект может сделать bind на событие смерти того же босса, и если он помирает, то босс просто делает call, а подписчик (он же наблюдатель, отсюда и название паттерна) это перехватывает самостоятельно и обрабатывает.
Для демонстрации интерфейсов , пример не удачный. Да и такая реализация , будет работать, только если на уровне одна такая комната. В реальном мире, каждый актор необходимо указывать ручками , или как то искать объекты в рамках вольюм бокса секретной комнаты.
Спасибо! :) Если не затруднит, подскажи, какой пример более хорошо бы подошел. (на самом деле я могу даже еще больше найти изъянов в том, что было показано в ролике, просто ставилась цель показать лишь один из вариантов, как сделать определенную вещь).
@@UNREALRUSSIA Если у нас есть Какое то количество объектов которым нужно отослать информацию. Берём get all \ actors \ widgets \ interfaces \ и т.д. это наверно идеальный вариант, в ряде случаев. В другом варианте вручную забиваем в массивы объекты которым нужно разослать информацию. Либо автоматически , выбирая объекты из области через вольюм. А напоследок диспатчеры с которыми я особо не работал, т.к. не находил им применение.
@@DeltaZavr. get all actors of class - достаточно прожорливая функция. Особенно, если вызываться она будет сразу в нескольких акторах. Когда логика проекта разрастется, такая функция может стать бутылочным горлышком. Имеет смысл подумать в сторону единого менеджера, который на констракте\бегине один раз соберет массив из необходимых акторов, подпишется на их делегаты (диспатчеры) и в своем теле уже разрулит логику вида событие>>реакция. Для акторов на уровне можно, например, создать базовый класс, содержащий в себе мета-информацию (например, уникальный ID) и отнаследоваться от него, а в менеджере собирать массив типа Map, к элементам которого можно обращаться по имени, либо массив структур, если необходимы дополнительные данные помимо ID. Возможностей для реализации на самом деле много и зависят они от конкретных задач.
@@DeltaZavr. get all \ actors странный выбор для этого, а если на сцене тысячи акторов из которых разослать нужно 10ти, а если рассылка нужна часто? Тогда каждый раз будут перебираться все тысячи акторов на сцене чтобы получить несколько., такое себе средство.
Привет :) Ну еще бы я не знал о делегатах, если о них говорится в каждом видеокурсе. :) У меня было желание записать еще одно видео с тем же самым, но с вариантом через EventDispatcher'ы. Можешь подконкретней подсказать, как бы ты оптимальней это сделал через EventDispatcher'ы? Там просто есть разные варианты, буду благодарен если подскажешь какой-нибудь максимально правильный и элегантный.
@@UNREALRUSSIA варианты разные абсолютно. Но использовать get all actors with interface это такое себе, очень не оптимизированный вариант. По сути должна быть сущность (хороший вариант использовать тот же гейм стейт, если мы говорим о каких то глобальных игровых ивентах или сабсистемы, правд это уже плюсы) в которую теми или иными путями приходят события(например триггер при оверлапе может дергать метод данной сущности), далее эта сущность уже файрит делегаты, и кому надо тот уже и подписывается на данные делегаты...
@@UNREALRUSSIA так же хочу заметить что вызов интерфейса достаточно тяжёлая штука, немного тяжелее каста и могут возникнуть ситуации когда на уровне объектов очень много (1000+ лампочек к примеру) в которых нужно по интерфейсу вызвать ивент, что приведет к ощутимому фризу
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Ох, вы первый, кто затронул тему паттернов UE4 в рутюбе, довольно интересно )
да, только патерны перепутал )
В одном из видео с официальных курсов по анрилу прямо сказано, что именно Event Dispatcher реализуют паттерн Observer. Хотя интерфейсы довольно универсальный инструмент, его хорошо для Strategy использовать, когда множество разношерстных акторов, чтобы удобнее было реализовывать расширение и изменение функционала. Все эти выборки всех объектов класса или интерфейсов рекомендуется по возможности вообще не использовать. И спасибо за интересный урок, подписался.
Огромное тебе спасибо, добрый человек. Я две недели пытался безуспешно решить задачу для своего приложения, и оказалось, что она очень легко решается с помощью интерфейсов и паттерна обсервер! Огромный лайк с меня!!!! Жду следующих уроков, поставил колокольчик!
09:45 Если кто не будет понимать почему не находятся эвенты от интерфейса - их в поиске нету, нужно нажать правой клавишей мыши в левом меню Interfaces, по нужному, и выбрать Implement Event.
Ага помогло, спасибо.
Первое. Тебе дизлайк за то, что удаляешь аргументированную критику без оскорблений на своём канале. Боишься, что школьники донатить перестанут?
Второе. Если человек не знает, как имплементить интерфейс в движке, хотя это интуитивно понятно, и, простите, написано прямым текстом, пусть и по-английски, значит, ему ещё вообще рано изучать паттерны.
Тон у Вас хамоватый. И где ты увидел здесь школьников и донат?
круто, спасибо! Интересно продолжение. Думал в этом видео про диспетчер будет это первое что пришло на ум для показа паттерна наблюдателя
Разве можно сказать, что блупринт интерфейсы в анриле работают, как паттерн Observer? В рамках этого паттерна, как я думал, должен быть реализован механизм "подписки" - подписанные объекты следят и реагируют на события, происходящие в объекте, на который они подписаны. Event Dispatchers лучше подходят для демонстрации данного паттерна.
Думаю, тут не только сигнал отправляет, но так и добротный пинок, типа давай работай.
Механизм подписки уже зашит в интерфейсы бп
Event Dispatcher'ы тоже под подобное подходят 👍
Смотрю твои видео на работе, в студии Ubisoft, очень помогают 😁
Спасибо за раскрытие таких важных тем. Лайк однозначно.
У ваших видео есть большая проблема - они очень редко выходят
Крутейше!!! Всё подробно и понятно. Решпехт!!!!))
Спасибо за материал. Попробовал. Очень прикольный механизм. Вот только вопрос. Всю игру можно на этом патерне сделать?
Шикарный урок! очень лаконично и по делу.
наконец то нашёл правильные интерфейсы на анриле)
Даже Проще чем в js, blueprint удобная штука))
Как всегда круто бро!))
p.s От Костяна :)
Божечки, неужели нормальный русскоязычный канал по анрилу без бе-ме, воды и школьников. Автор не останавливайся! Хочу смотреть как правильно делать частичную разрушаемость от пуль через Unreal Chaos , процедурно генерировать помещения из комнат и остальные паттерны жду с нетерпением! Лайк, подписка.
Уважаемый, поясните вкратце, в чём принципиальное отличие эвент диспетчеров от интерфейсов? Из всех видео по этим элементам получается, что они в некотором смысле идентичны, т.е поставленную задачу можно легко и непринуждённо реализовать как ЭД, так и интерфейсами.
огонь контент. Дюже благодарствую.
Дружище ты супер. Даже я понял.
Лайк!
Жду последующие части
Супер, как с вами связаться в телеграмме? есть крутое финансовое предложение.
А где продолжение?
интерфейсы помогают легко сообщаться туда обратно, на сколько я понял.
Больше паттернов! =)
ПуЕр. Сижу думаю шо за пуЕр. Чай, что ли. А это, оказывается, player ))
Отличный контент, спасибо
Очень полезная инфа!!
Observer это патерн про делегаты (диспатчеры), а интерфейсы это Strategy патерн. Я бы на вашем месте удалил это видео чтобы не позориться либо исправил ошибку.
Касательно кода get all actors это тяжелый метод, использование которого мягко скажем не оправдано.
Сама идея "анонимности" и заменяемости конечно как бы соблюдается (иначе смысла использовать интерфейс вообще бы не было), но я бы не назвал такое решение хорошей практикой.
Вообще то что вы сделали больше похоже на Chain of responsibility патерн: перебор клиентов, которые сами решают реагировать им на событие или нет. Только там бы использовался break наверное.
Молодец! Все понятно!
К сожалению, очень слабо. Видно, что базы у тебя практически нет, раз в самом простом паттерне (после шаблонного метода и одиночки) ты плаваешь. Но могу утешить, лучше, чем у всех остальных, что я видел. Если другие - это вообще детский сад, то у тебя уровень начальной школы, что уже неплохо. Теперь по сути.
Первое. Интерфейсы вот так не используют. Могу много писать, но просто пример. У тебя в боссе ищутся все объекты с интерфейсом. А что если кому-нибудь ещё потребуется информация о том, что босс умер? Но при этом ему не нужны твои "входы и выходы в ловушку". Реализовать весь этот интерфейс в новом объекте? Так это нарушение одного из принципов SOLID. Дописать поиск ещё всех других объектов с другим интерфейсом? Так это нарушение принципа открытости-закрытости. Поэтому плавно вытекает второе. Никакого отношения вот этот пример к Observer не имеет. Для Observer в движке есть Event Dispatcher. Любой объект может сделать bind на событие смерти того же босса, и если он помирает, то босс просто делает call, а подписчик (он же наблюдатель, отсюда и название паттерна) это перехватывает самостоятельно и обрабатывает.
Что лучше тогда посомтреть/почитать чтобы лучше понимать это всё?
Для демонстрации интерфейсов , пример не удачный.
Да и такая реализация , будет работать, только если на уровне одна такая комната.
В реальном мире, каждый актор необходимо указывать ручками ,
или как то искать объекты в рамках вольюм бокса секретной комнаты.
Спасибо! :) Если не затруднит, подскажи, какой пример более хорошо бы подошел.
(на самом деле я могу даже еще больше найти изъянов в том, что было показано в ролике, просто ставилась цель показать лишь один из вариантов, как сделать определенную вещь).
@@UNREALRUSSIA Если у нас есть Какое то количество объектов которым нужно отослать информацию.
Берём get all \ actors \ widgets \ interfaces \ и т.д. это наверно идеальный вариант, в ряде случаев.
В другом варианте вручную забиваем в массивы объекты которым нужно разослать информацию.
Либо автоматически , выбирая объекты из области через вольюм.
А напоследок диспатчеры с которыми я особо не работал, т.к. не находил им применение.
@@DeltaZavr. get all actors of class - достаточно прожорливая функция. Особенно, если вызываться она будет сразу в нескольких акторах. Когда логика проекта разрастется, такая функция может стать бутылочным горлышком. Имеет смысл подумать в сторону единого менеджера, который на констракте\бегине один раз соберет массив из необходимых акторов, подпишется на их делегаты (диспатчеры) и в своем теле уже разрулит логику вида событие>>реакция.
Для акторов на уровне можно, например, создать базовый класс, содержащий в себе мета-информацию (например, уникальный ID) и отнаследоваться от него, а в менеджере собирать массив типа Map, к элементам которого можно обращаться по имени, либо массив структур, если необходимы дополнительные данные помимо ID. Возможностей для реализации на самом деле много и зависят они от конкретных задач.
@@DeltaZavr. get all \ actors странный выбор для этого, а если на сцене тысячи акторов из которых разослать нужно 10ти, а если рассылка нужна часто? Тогда каждый раз будут перебираться все тысячи акторов на сцене чтобы получить несколько., такое себе средство.
под такую задачу room manager какой нить напрашивается)
Про делегаты почитай и потом появится желание перезаписать это видео)))
Привет :) Ну еще бы я не знал о делегатах, если о них говорится в каждом видеокурсе. :) У меня было желание записать еще одно видео с тем же самым, но с вариантом через EventDispatcher'ы. Можешь подконкретней подсказать, как бы ты оптимальней это сделал через EventDispatcher'ы? Там просто есть разные варианты, буду благодарен если подскажешь какой-нибудь максимально правильный и элегантный.
@@UNREALRUSSIA варианты разные абсолютно. Но использовать get all actors with interface это такое себе, очень не оптимизированный вариант. По сути должна быть сущность (хороший вариант использовать тот же гейм стейт, если мы говорим о каких то глобальных игровых ивентах или сабсистемы, правд это уже плюсы) в которую теми или иными путями приходят события(например триггер при оверлапе может дергать метод данной сущности), далее эта сущность уже файрит делегаты, и кому надо тот уже и подписывается на данные делегаты...
@@UNREALRUSSIA так же хочу заметить что вызов интерфейса достаточно тяжёлая штука, немного тяжелее каста и могут возникнуть ситуации когда на уровне объектов очень много (1000+ лампочек к примеру) в которых нужно по интерфейсу вызвать ивент, что приведет к ощутимому фризу
@@sansey5 Лайк :) Сделаю наверно и про eventdispatcher'ы :)
@@sansey5 @UNREAL: RUSSIA Дополню, что обычно триггеры относятся к конкретной карте и этой сущностью как раз и будет level-blueprint.
лукойл