Дополню, UnityEvent выгоден если только один объект подписан на него, в любых других случаях он проигрывает в произовидельности остальным делигатам

видос хороший, НО вот лично мне реально пришлось "догугливать" что бы до конца разобраться ибо пример совсем плохо разобран (( НО, всё равно, спасибо) теперь я знаю чуть-чуть больше))

для начинающего не подходит.

Да у него обычно хорошо выходит вкратце и понятно изложить смысл но тут явно слишком урезал важные моменты

урок не очем, автор урока просто кэп, а в тонкостях сам видать не шарит

лучший коммент на этом видео + 50% к информативности к видео)

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

О, димас, дарова)

Какие люди в Голливуде)

Записал в список идей для будущих видео)

Да, вариант с UnityAction (Или просто Action, который в namespace System есть) даже удобней в основном. А насчёт отписки - если классы с ивентами или классы-подписчики уничтожаются, то в целом ничего фатального если не отписаться не произойдёт, например после смены уровня все не-статик ивенты пропадут. А вот статики отписывать в строгом порядке, если они существуют)

@@insaneone-7220 поэтому не лениться и отписываться всегда)

С чего ты взял, что ему виднее? 😂

Чел, когда я узнал про такую штуку то я подумал "Почему я не сделал себе этого раньше?! Сделай и себе!") Как минимум, гг ударили и надо изменить в интерфейсе его жизни. Да, можно каждый кадр проверять скок хп и... это не сильно ударит по производительности. Вообще. Но ты начинаешь потом еще проверки сувать в апдейты, и еще и еще. И вот тут начинаются лишние вычисления. Поэтому если 1 классу надо знать что что-то изменилось во втором, то первый создает событие и просто вызывает. по аналогии с ютубом прикинь автор каждому будет звонить и говорить что вышел новый ролик? ) Короче топ тема. Можешь прочесть про паттерн Observer (Наблюдатель ) если я не ошибаюсь. Чуть больше гемора в начале пока прописываешь кажется, но это окупается. ;)

@@AlexStraga согласен, если нет подписчиков, то и никому звонить не надо; и если ни на кого не подписан, а так обзванивать десятки каналов ..., ладно если несколько каналов или подписчиков, то можно и позвонить, иначе будет лень набирать

@@combine_soldier напрямую поле хп меняешь или через функцию? И ию аптечка меняет?

@@combine_soldier это тема тогда)

Создай SerializedField в классе и в Юнити повесь ссылку на своего игрока.

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

@@insaneone-7220 я мог бы прислать Вам проект на почту. Если хотите можете даже сделать на него обзор с оптимизацией или чем то ещё. Что скажете?

@@user-hp3kt3ot7d можно попробовать) Почта в разделе "О канале" на странице канала, можно на неё отправить

Ну, точка зрения "я уже юзаю и вроде бы работает" говорит о том, что стоит подробнее изучить вопрос, если это интересует конечно) Обычные ивенты и юнити ивенты похожи, но это немного разные вещи. Юнити-ивенты медленнее работают, например. Обычные ивенты есть в самом C# и при переносе кода в другое приложение, смогут работать и без юнити. В твоём примере укороченный делегат сделан через лямбду с помощью конструкции () =>. Да, так можно, но мне же надо было в уроке сказать о том, как это делается без синтаксического сахара? :) Singleton это обычный и самый лёгкий паттерн проектирования для доступа к конкретному и единственному экземпляру объекта через статичную переменную, на канале есть видео про его. Для понимания этого видео знать про него, в общем, не обязательно. Надеюсь, стало чуть понятнее)

@@insaneone-7220 ,вот как. Да,стало чуть яснее. Значит методы из самого языка работают быстрее чем методы которые есть в движке? О.о Это как-то объясняется? Как например не юзать camera.main и FindObjectsType? Потому что это всё немного путает. Мол,зачем тогда они вообще нужны,если только делают хуже? На самом деле вопросов у меня много. Скорей всего потому-что я новичок в Юнити. И если не ответишь,то я пойму. Не охота лишний раз напрягать человека,которому может не интересно мне всё разжовывать. Заранее,спасибо за предыдущий ответ.

@@tonicoders991 да, ивенты из языка быстрее тех, что в движке. Можно конечно это объяснить тем, что ивенты из юнити удобнее и доступны ещё и из редактора, но на самом деле это не объясняет их медлительности. Возможно, команда юнити недостаточно хорошо их реализовала.

Потому что это в его классе, похоже, он объявлен, просто нам не показали.

Да. Самое правильное, пожалуй - в методе, подписанном на событие нажатия кнопки, вызвать другое событие. Так вызывать можно сколько угодно событий)

@@insaneone-7220 а ларчик просто открывался...

@@insaneone-7220 а ещё вопрос: а как сделал Player.singelton?

@@insaneone-7220 день добрый, присоединяюсь к вопросу. Что такое синглтон в принципе понял, но как оформить это как свойство класса?

Можно в OnDisable, но тогда и подписываться лучше в OnEnable. В случае подписки в Start, можно в OnDestroy попробовать.

Можно, но лучше так не делать. И синглтон лучше не использовать, вообще не использовать.. если все спроектировано нормально, необходимость в синглтонах стремится к нулю

UnityEvent работает медленнее шарповых и единственное, чем он удобнее - возможность настраивать из редактора. Но если он больше нравится - ничто не мешает им пользоваться :)

@@insaneone-7220 там ещё идёт автоматическая отписка при Destroy. Так что, я так понимаю, если игра не особо нагружена, легче использовать UnityEvent, чтобы не было лишних ошибок

Да, про отписку стоило сказать, согласен, но никаких двойных срабатываний не будет, если правильно выстраивать архитектуру кода. Повторные срабатывания будут лишь тем, где необходимы. Вот в примере из видео событие по сбору монет должно вызываться всегда в текущей игровой сессии. А при смене уровня они все автоматически удалятся вместе с объектами.

@@insaneone-7220 согласен зачем создавать событие и сразу после этого события отписываться, для того чтобы оно не сработало второй раз

Публичные поля в Unity пишутся с маленькой буквы, и если писать свои с большой, код будет неконсистентен. Не вижу ни одной причины использовать private кроме лишнего удлинения кода, я перенастроил райдер на обратный кодстайл. Сама такая возможность говорит, что нет единственно верной истины. RequireComponent не требуется, если есть своя, более удобная реализация автоматической настройки компонентов, в данном случае это просто не нужно, т.к. урок не об этом. Насчёт Action действительно стоило сказать. Про UnityEvent я уже писал в закреплённом комментарии. По поводу "я хз" - без комментариев.

@@insaneone-7220 Понял))

Скрипт стал активным, подписался, его улалили или сделали неактивным - отписался. Поэтому в onEnable/disable самое то подписки мутить.

@@insaneone-7220 Что в каком код стайле ПУБЛИЧНЫЕ поля пишутся с маленькой буквы? Что за дичь и ересть? С github официального microsoft, "Names of classes, methods, enumerations, public fields, public properties, namespaces: PascalCase."

@@insaneone-7220 Изучи код конвенсию от майкрософта раз пишешь на C#.