Чтобы попасть в закрытый Telegram чат с доступом навсегда, то можете отправить мне донат на любую сумму от 100 рублей на сервис Boosty: boosty.to/makeyourgame , а я пришлю ссылку в течение 24 часов. Только убедитесь, что у вас открыты сообщения на Boosty. ================================= Группа в ВКонтакте: vk.com/makeyourgameunreal ================================= Подписка на канал - только приветствуется! ================================= #games #unreal #unrealengine
Основная проблема кастров в том, что логика объектов с которыми мы взаимодействуем прописывается в нашем персонаже. Логика должна быть разделена. А с кастом как в этом примере смена материала вызывается в персонаже. И теперь что бы поменять логику кубика надо лезть в персонажа, а если с кубиком взаимодействует несколько объектов - это совсем грусть будет.
Это было очень полезно, ранее сталкивался с интерфейсами и особо не заценил их эффективность, пересмотрел свое восприятие...Благодарю автор!!! Все очень понятно и подробно.
Смотри: у меня файтинг, где по краям экрана есть 2 невидимые стены, пол и потолок, которые ограничивают передвижение ПЕРСОНАЖА, а ещё снаряды определённого типа могут взрываться/останавливаться, отскакивать от, и всё такое. И я делаю КАСТ на каждый снаряд и вызываю поведение в зависимости от того, что там за снаряд и что должно произойти. В итоге стена несёт на себе все снаряды в игре, даже если играть не за персонажа, который может этими снарядами СТРЕЛЯТЬ. Вывод: я хоть и не дурачок, но не обладал ЗНАНИЯМИ... А автор видео мне эти знания ДАЁТ. Теперь надо сделать выводы и исправить ЛОГИКУ в стенах, чтобы они не тащили на себе санки с пятью мужиками.
Демонстрацию получения переменных через интерфейс еще не на одном видео не встречал по данной тематике, а ведь это, наряду с функциями, основополагающая вещь.
отдельно отметил для зрителей, в уроке 16 про интерфейсы, примерно на 50 секунде, для получения переменных от иного объекта вы рекомендуете использовать casting, есть output интерфейса, который можно использовать как get, это наблюдение и послужило причиной моего замечания, но насколько это профитней сказать не могу, может кто внесет ясность о целесообразности подобных манипуляций. Или же наследование от с++ класса с набором используемых переменных и функций (без mesh, particle и прочего тяжелого) и каст к нему не хуже в плане производительности, а может даже и лучше. А вообще, в данной теме упоминают, что компоненты и композиция для взаимодействия объектов лучше всего, что это за концепция я не представляю, буду рад увидеть что-то из этого.
Спасибо за ролик. Мне нравится твое объяснение на пальцах, мне было интуитивно не понятно как работают интерфейсы. Обязательно посмотрю твои ролики про касты и интерфейсы. Теперь мне надо перешить все свои блюпринты. Ох... потная катка будет, учитывая что я чуть ли не в каждом БП делал касты. Тысячи их! XD
Добрый день! Очень понравилось видео. По факту это интерфейсы из c++, ну и других языков, предназначеные показать что данный объект точно имеет в себе реализацию какого-то функционала. Единственное все-таки разделять интефейсы для разных задач, а не запихивать все в один. Если я простолушал про этот момент очень извеняюсь. Спасибо большое за видео.
Понятно. Не хватает только простого упоминания про разделение логики объектов. Логика левых предметов не должна находится "внутри" персонажа. Лайк вам)
Недавно посмотрел ваш урок с стаминой, там у вас каст в виджете выносливости на персонажа с целью его сохранения в перменную персонажа, но переменная персонажа не была задействована в дальнейшей логике., данные качались через каст, а не через переменную с персонажем. Это была пропущено потому что торопились с уроком или потому что если каст сделан. то взаимодействие с этими переменными уже не приводят к дополнительной СУЩЕСТВЕННОЙ нагрузуки?
А можно видео, где касты уместны? Я сейчас пытаюсь через кастомный notify state сделать трейс у оружия и кроме каста похоже там ничего использовать не получится или есть другой путь?
А как применить интерфейс если у меня коллмзия сфера при пересечении шейдит оутлайн материал при окончании пересеяения выклбчается как делать это без кастов!?
Урок полезный, единственное, что смущает в интерфейсе- само название сущности. Потому что в Анриле уже есть UMG интерфейсы и сам первое время путался, когда изучал. Если бы разрабы заменили слово интерфейс на "посредник", ясности было бы больше. Ну и еще не понял чисто по механике, в какой момент "подгружается" класс, на который делаешь каст. В момент, когда стрелочка на него приходит, или когда вытягиваешь синюю ноду "as actor". Так как сам использую каст только для проверки класса, но из актора логику другого актора никогда не вызываю, так как это не слишком оопэшно.
Немного поправлю, если то что вы говорите правда, то это просто провал в ООП, что бы каждый раз в момент каста грузился весь класс, уверен вы допускаете ошибку в своем высказывание, такое поведение на каст - убило бы разработку в многопоточной среде. Пример: Два объекта наносят урон персонажу, оба выполняют каст его внутри своей логики, для последующего вычитания общего количества ХП, и получается что разработчики движка сделали так - копируют при касте, но тогда каждый из тех кто кастует получит копии, первое они будут уменьшать ХП каждый у своей копии , и самое главное основному персонажу вообще как то нет дела, ведь он отдал от себя клонов. Скорее всего идет речь о том что сам каст по себе , подгружает ссылку на игрока а не хранит ее в себе постоянно, это и плохо для работы, потому как реально при наличии множества , ему нужно будет каждый момент грузить эти данные, а потом удалять. Интерфейсы совершенно не решают эту проблему - это разные подходы, "композиция" и наследование. Обратите внимание композиция тут в кавычках - потому что ее нет, просто есть каст который выполняет приведения типа во временной функции. А вот если вы действительно хотели бы рассказать о преимуществе интерфейса, то пример нужно было строить не от отдельного Events, а к примеру создать внутри вашего Класса или Блюпринта, в вашем случае три объекта Куб, Плайн и Сферу, а далее в момент создания класса или блюпринта получить через какст единожды и сохранить полученные данные в эти ссылки , тем самым убрав дорогую операцию в отдельных Events. Вот тогда бы мы увидели зачем нам нужны интерфейсы, когда внутри нашего класса нам бы пришлось выбирать из вашего примера одного из трех, а потом из 20 и так далее, нежели просто использовать назначенный им интерфейс.
Это не мои слова. Я же специально показал, что в описании к касту самими разработчиками указано, что загружается весь блюпринт и это дорого. И да, при касте вы можете получить и достать все что угодно. И нет, это не провал ООП. Это облегчение разработки в некоторых случаях. Те, кто хотят ООП - пожалуйста, есть наследование, прайват переменные, интерфейсы и т.д.
Так, стоп, получается при каждом касте создается еще один дубликат актера? То есть его из одной копии можно надюпать 10 тысяч? То есть его даже в наследовании лучше избегшать, не кастить к предмету? (абстракт) - приведение к предмет (бутылка огненной воды) ? Будет дюп актера "предмет"?
В данном конкретном случае секвенция одновременно кастуется сразу на несколько блюпринтов. Одновременный каст и одновременная логика. Если потребуется какая-нибудь задержка, то нужно делать delay между секвенциями и создавать прочие зависимости. Секвенция будет на себе тащить много всего и много на ней будет завязано, что неудобно
А, в этом плане. Я уж подумал из-за какой-то негативной производитеьлности непосредственно самого этого нода. Тогда можно было просто пустить ветки через Cast Failed. Не одновременно, а последовательно. Нод даже переводится так. За кадр пройдет все по порядку. А вот delay это куда большее зло. Лучше стараться их избегать архитектурно.@@makeyourgame2210
Вот мне кажется что вы заблуждаетесь. А что на счёт каста на один объект из которого идёт наследование и полиморфизм? И весь ваш интерфейс уже к чертям катится и погружает вообще все объекты с этим интерфейсом. Все должно быть в меру!
Замечание справедливое, но отвечу. Я не зря в видео сказал, что давайте представим, что куб - враг, планка - патроны, сфера - транспорт. Думаю вы поняли на что я намекаю. Ни один здравомыслящий человек не будет наследоваться от транспорта, чтобы сделать патроны.
@@makeyourgame2210Хорошо, но ведь в любом случае можно сделать условно 7 родительских классов, это не так много, тем более вешать можно не на сиквенс, а на каст фэил. Тем более если делать что либо по сети - как работать с интерфейсами - не ясно, ведь он не реплицируется.
@@DisoftGDmedia ну хорошо, а что если в одном из семи родительских классов нужна будет другая логика чтобы вызывалась? Ну вдруг понадобилось. Как тогда из ситуации будете выходить? Как будете другую логику из одного каста вызывать, который является родительским для всех других? Делать бранчи? А если в двух дочерних классах поменять что-то? Ещё один бранч? Вообще дискуссия о том, что касты нужно использовать с примирением всяких кастфэйлов + с использованием дочерних классов я считаю неуместной, когда САМИ ЖЕ РАЗРАБОТЧИКИ на САМОЙ НОДЕ пишут о том, что каст может убить оптимизацию.
@@makeyourgame2210 Ну почему нельзя просто переопределяться функцию? Как по мне самый логичный вариант для другой логики. Никаких проблем не вижу. А вот проблемы с интерфейсами я вижу. Как использовать их в сетевом проекте - я не знаю, вроде как нельзя. Ну а кастить с персонажа на разные классы я считаю нормой. Ну а делать наоборот - не очень, лишь в качестве исключений
@@DisoftGDmediaПо сети все прекрасно работает. Но ваша точка зрения - правильная. Если вы работаете с деревом классов, то вам хватит обычного каста. Достаточно переопределить функцию в наследниках и все пойдет как по маслу. Интерфейсы пригодятся когда, например враг, может быть и AActor и APawn и UObject. В таком случае дерево классов не возможно, а общее поведение необходимо. Не все системы (оружие как пример) можно расписать деревом классов.
Очередная пугалка кастами и введение в заблуждение, что-бы сделать аналогичное взаимодействие с кучей объектов нужен 1 каст на 1 класс т.к. наследование и полиморфизм никто не отменял. То что интерфейсы удобней тут не спорю, но всё остальное это страшилки.
Человек делающий уроки про С++ не знает? А вообще очень просто что если данный класс на который делается каст не существует то он будет загружен в память, в случае же с персонажем который с вероятностью 99.9999 уже есть ничего произойдёт т.к. данный класс используется и в памяти уже есть. @@makeyourgame2210