Реактивное программирование в Unity. Разбираем на примере R3

[@premudriylis_yt7195]

Огромное спасибо! Канал очень помогает развиваться.

[@artemvah2210]

Спасибо за видео! Очень интересно про реактивное программирование. А также про Nuget для Unity )

[@dezoksiribonukleotid5011]

Спасибо большое за видео

[@DeadRabbitCanDance]

Очень полезно! Для понимания концепции "реактивного" программирования, как мне кажется, хорошо подходит привычный всем Excel. Мы же привыкли, что пишем в ячейке формулу и эта формула сработает не только в момент когда мы её пишем, но и в тот момент, когда данные в ячейках, которые участвуют в вычислениях - изменятся. Вот она и проявляется сама суть реактивщины. Вот как это применять для "удобства" именно в игре ? если на изменение и здоровья и брони и всего чего угодно вызывать много раз обработчик - это не то что нужно для регистрации наносимого урона. Для выстраивания последовательностей во времени - это да, наверно удобно, но мне кажется что основная идея самого метода не в этом. Хотелось бы пример для чего это удобно применять.

[@savaslive]

Обычно юзается addTo при подписках. То есть, простое правило: написал subscribe, пиши addTo. В р3 запись выглядит так: ...Subscribe().AddTo(ref disposable); Добавился реф.

[@gamedevlavka]

Да, кстати, совсем забыл об этом

[@7shockk]

это значит, что слева от выражения не обязательно приваивать к IDisposable, вместо этого addTo?

[@savaslive]

@@7shockk да, это взаимозаменяемые варианты. С addTo покороче, компактнее.

[@7shockk]

@@savaslive Хмм, почему-то AddTo не хочет принимать IDisposable, нет такой перегрузки метода. Вместо этого передал туда CompositeDisposable, причем без ref.

[@ВячеславСамуйленко-п1ш]

@@7shockk у меня так-же

[@kingofbattleonline]

Автор, хочу отметить, что ты молодец. У меня к тебе нет никаких претензий, всё изложено грамотно и понятно. Однако у меня возникает вопрос: зачем? Эта библиотека создана для тех, кто не умеет работать с generics? Или для тех, для кого асинхронное программирование кажется чем-то запредельно сложным? Такой функционал (без преувеличения) реализуется довольно легко и быстро. Если я вдруг увижу в вакансии требование знания чего-то вроде R3, я сразу буду её пропускать (хотя такого, скорее всего, не случится, так как я работаю с C++). Я буду избегать таких вакансий, потому что сразу станет ясно: там работают одни джуниоры, которые совершенно не разбираются в оптимизации. Почему я говорю об оптимизации? Потому что работа с асинхронным программированием и передачей контекста требует глубоких знаний. Мы должны понимать, что такие вещи нужно делать грамотно, ведь любая ошибка в манипуляции контекстами между потоками может привести к длительным простоям основного потока. Это особенно критично для мобильных устройств, где ресурсы ограничены. Использование подобной библиотеки, на мой взгляд, обесценивает профессию программиста. Она позволяет даже человеку с минимальными знаниями и IQ около 40 работать с такими вещами, не углубляясь в суть. Я бы не рекомендовал её использовать, если цель - повышение своей квалификации и углубление знаний. Лучше разбираться в основах и писать код осознанно, чем полагаться на упрощённые инструменты, которые не способствуют профессиональному росту.

[@whatareulookingat235]

Ура! Новый видос

[@firstvf]

Спасибо!

[@EugeneS88-RU]

Не рассмотрено ReactiveCommand :(

[@квадратя]

А как эта штука устроена под капотом? Как сильно это может повлиять на производительность? Если куча скалярных пропертей объектов сами становятся объектами?

[@gamedevlavka]

Observable это ссылочной тип, несомненно, и он придуман не для того, чтобы создавать объекты каждый кадр. Нет, создал и пользуйся. Сама задача (уведомление об изменении) не подходит под вопрос оптимизации, ты либо используешь события, либо обёртка, либо сравнения и т.д.

[@SSholger]

@@gamedevlavka то есть, оно хорошо подходит для чегото что вызываеться редко, например ХП и еще чтото. я прав?

[@gamedevlavka]

@@SSholger оно хорошо подходит там, где нужно следить за изменениями. Самый простой и известный аналог в юнити и с# - это Action, на который нужно подписываться и отписываться. Условно: ХП игрока поменялось - вызвать событие и уведомить всех подписчиков, что ХП поменялось. Здесь похожая история, но возни меньше, а понимания больше

[@SSholger]

@@gamedevlavka окей спасибо

[@neroduck]

Все то вы знаете)

[@Erosrolf]

Я установил все точно так же как в видео, но почему то IDisposable не видит в R3, IDE предлагает только из библиотеки System.IDisposable, нормально ли использовать для R3 IDisposable из System?

[@gamedevlavka]

@@Erosrolf так так и должно быть) IDisposable из System используется

[@Erosrolf]

@@gamedevlavka просто из комментариев было про AddTo(ref disposable), попробовал с IDisposable из System, у меня это не сработало. Ну да ладно, думаю это не так важно. Спасибо тебе за то что ты делаешь) Я по учебе делаю игру параллельно с твоим проектом Пилим Игру, ты мне очень помогаешь! Надеюсь доделаю и поделюсь в ТавернеРазработчика)

[@7shockk]

Я так понимаю, пример №4 не особо используется? Ибо, зачем это, если это буквально шарповский ивент?

[@gamedevlavka]

@@7shockk редко, но используется. Реактивные свойства в целом уменьшают надобность в отдельных событиях, но не совсем их убирают. Плюс сохраняется консистентность для подписки-отписки, что лучше читается

[@awdsasdaw742]

♥

[@Чебрик-ы3ы]

Здравствуйте, как вы боролись с выгоранием во время учёбы? Каждый раз после того как позанимаюсь , чувствую себя самозванцем и думаю что стоит все бросить. С трудом перебарываю такие мысли

[@igor_mutny]

Извини за непрошенный совет, просто меня тоже посещают подобные мысли. Я в таких случаях просто говорю себе про свой код: "да пофиг, работает - и ладно" 😁 В конце концов, самое первое и главное требование к коду, которое всегда было, есть и будет - это чтобы код корректно выполнял свою работу. При том, что я, само собой, не пишу "на отъе..ись", а стараюсь каждый раз выжимать из себя по максимуму качества, на которое способен. Но всё равно же путь к профессионализму лежит через мегабайты говнокода, - это неизбежность 😁 Еще можно вспоминать (и даже просматривать) код, который ты писал полгода или год назад. Там сразу первые мысли: "Фу, ну и навалил же я тогда кринжа, сейчас бы я ни в жизнь не написал такое убожество, я бы сделал вот так и так, - это было бы намного лучше". И вторая мысль: "хм, ну, значит, прогресс-то есть, - и, судя по всему, немаленький". Главное - не броситься тут же переписывать его, чтобы не тратить время зря 😁 Ну и, в целом, поскольку "синдром самозванца" очень часто меня беспокоит вообще абсолютно во сферах жизни - далеко не только в программировании 😁- у меня сложилась такая своеобразная тактика борьбы с ним. Мой внутренний голос часто требует от меня "рассудить" ситуацию по "справедливости" типа "А достоин ли я вообще того-то и того-то?" И я научился быстро "включать циника" и переключаться на мысли типа: "Мне всё равно: если я смог что-то себе урвать, - значит, я это заслужил. И неважно, справедливо это или нет." Как-то так, в общем. Еще раз извини за непрошенный совет.

[@bigbimba2448]

@@igor_mutny В дополнение. Сначала надо заставить свой код работать, потом уже приводить его к адекватному виду. Так всегда было и есть, попытка написать сразу идеальную архитектуру на боевом проекте приведет к выгоранию, медленной разработке, увольнению (если это в компании), потому что там основная задача - закрывать таски, а не тешить свое эго

[@igor_mutny]

@@bigbimba2448 а существует ли она, эта идеальная архитектура? А то есть подозрение, что это что-то наподобие идеальной сферы. Типа можно какой-нибудь деревянный шарик шлифовать до бесконечности, но он все равно никогда не станет идеальной сферой. Рано или поздно всё равно нужно махнуть рукой и сказать: "Ладно, так сойдет!" 😁

[@gamedevlavka]

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

[@Чебрик-ы3ы]

@@gamedevlavka спасибо за ваш совет!

[@issatay8876]

Можно ли R3 заменить UnitTask?

[@gamedevlavka]

@@issatay8876 и R3 и UniTask существуют для одной задачи - асинхронное программирование, но работают совершенно по разному. Так что концептуально, да, но эти видео не совсем добавят понимание

[@dezoksiribonukleotid5011]

я оба плагина в своих проектах юзают, сочитаются они великолепно

[@sagrgywejhxcvx]

Только у меня звук немного шипит?

[@trakschanel]

Error adding package: (url}) Unable to add package [(url)] url копирую правильно. Не работает вообще ни на каком пакете

[@darkdavet6604]

Нужно не саму ссылку репозитория копировать. Спустись ниже, там под How do I install NuGetForUnity? будет правильная ссылка. Для версий Unity 2019.3 и выше