Обычно юзается addTo при подписках. То есть, простое правило: написал subscribe, пиши addTo. В р3 запись выглядит так: ...Subscribe().AddTo(ref disposable); Добавился реф.
@@savaslive Хмм, почему-то AddTo не хочет принимать IDisposable, нет такой перегрузки метода. Вместо этого передал туда CompositeDisposable, причем без ref.
Очень полезно! Для понимания концепции "реактивного" программирования, как мне кажется, хорошо подходит привычный всем Excel. Мы же привыкли, что пишем в ячейке формулу и эта формула сработает не только в момент когда мы её пишем, но и в тот момент, когда данные в ячейках, которые участвуют в вычислениях - изменятся. Вот она и проявляется сама суть реактивщины. Вот как это применять для "удобства" именно в игре ? если на изменение и здоровья и брони и всего чего угодно вызывать много раз обработчик - это не то что нужно для регистрации наносимого урона. Для выстраивания последовательностей во времени - это да, наверно удобно, но мне кажется что основная идея самого метода не в этом. Хотелось бы пример для чего это удобно применять.
Автор, хочу отметить, что ты молодец. У меня к тебе нет никаких претензий, всё изложено грамотно и понятно. Однако у меня возникает вопрос: зачем? Эта библиотека создана для тех, кто не умеет работать с generics? Или для тех, для кого асинхронное программирование кажется чем-то запредельно сложным? Такой функционал (без преувеличения) реализуется довольно легко и быстро. Если я вдруг увижу в вакансии требование знания чего-то вроде R3, я сразу буду её пропускать (хотя такого, скорее всего, не случится, так как я работаю с C++). Я буду избегать таких вакансий, потому что сразу станет ясно: там работают одни джуниоры, которые совершенно не разбираются в оптимизации. Почему я говорю об оптимизации? Потому что работа с асинхронным программированием и передачей контекста требует глубоких знаний. Мы должны понимать, что такие вещи нужно делать грамотно, ведь любая ошибка в манипуляции контекстами между потоками может привести к длительным простоям основного потока. Это особенно критично для мобильных устройств, где ресурсы ограничены. Использование подобной библиотеки, на мой взгляд, обесценивает профессию программиста. Она позволяет даже человеку с минимальными знаниями и IQ около 40 работать с такими вещами, не углубляясь в суть. Я бы не рекомендовал её использовать, если цель - повышение своей квалификации и углубление знаний. Лучше разбираться в основах и писать код осознанно, чем полагаться на упрощённые инструменты, которые не способствуют профессиональному росту.
А как эта штука устроена под капотом? Как сильно это может повлиять на производительность? Если куча скалярных пропертей объектов сами становятся объектами?
Observable это ссылочной тип, несомненно, и он придуман не для того, чтобы создавать объекты каждый кадр. Нет, создал и пользуйся. Сама задача (уведомление об изменении) не подходит под вопрос оптимизации, ты либо используешь события, либо обёртка, либо сравнения и т.д.
@@SSholger оно хорошо подходит там, где нужно следить за изменениями. Самый простой и известный аналог в юнити и с# - это Action, на который нужно подписываться и отписываться. Условно: ХП игрока поменялось - вызвать событие и уведомить всех подписчиков, что ХП поменялось. Здесь похожая история, но возни меньше, а понимания больше
Я установил все точно так же как в видео, но почему то IDisposable не видит в R3, IDE предлагает только из библиотеки System.IDisposable, нормально ли использовать для R3 IDisposable из System?
@@gamedevlavka просто из комментариев было про AddTo(ref disposable), попробовал с IDisposable из System, у меня это не сработало. Ну да ладно, думаю это не так важно. Спасибо тебе за то что ты делаешь) Я по учебе делаю игру параллельно с твоим проектом Пилим Игру, ты мне очень помогаешь! Надеюсь доделаю и поделюсь в ТавернеРазработчика)
@@7shockk редко, но используется. Реактивные свойства в целом уменьшают надобность в отдельных событиях, но не совсем их убирают. Плюс сохраняется консистентность для подписки-отписки, что лучше читается
Здравствуйте, как вы боролись с выгоранием во время учёбы? Каждый раз после того как позанимаюсь , чувствую себя самозванцем и думаю что стоит все бросить. С трудом перебарываю такие мысли
Извини за непрошенный совет, просто меня тоже посещают подобные мысли. Я в таких случаях просто говорю себе про свой код: "да пофиг, работает - и ладно" 😁 В конце концов, самое первое и главное требование к коду, которое всегда было, есть и будет - это чтобы код корректно выполнял свою работу. При том, что я, само собой, не пишу "на отъе..ись", а стараюсь каждый раз выжимать из себя по максимуму качества, на которое способен. Но всё равно же путь к профессионализму лежит через мегабайты говнокода, - это неизбежность 😁 Еще можно вспоминать (и даже просматривать) код, который ты писал полгода или год назад. Там сразу первые мысли: "Фу, ну и навалил же я тогда кринжа, сейчас бы я ни в жизнь не написал такое убожество, я бы сделал вот так и так, - это было бы намного лучше". И вторая мысль: "хм, ну, значит, прогресс-то есть, - и, судя по всему, немаленький". Главное - не броситься тут же переписывать его, чтобы не тратить время зря 😁 Ну и, в целом, поскольку "синдром самозванца" очень часто меня беспокоит вообще абсолютно во сферах жизни - далеко не только в программировании 😁- у меня сложилась такая своеобразная тактика борьбы с ним. Мой внутренний голос часто требует от меня "рассудить" ситуацию по "справедливости" типа "А достоин ли я вообще того-то и того-то?" И я научился быстро "включать циника" и переключаться на мысли типа: "Мне всё равно: если я смог что-то себе урвать, - значит, я это заслужил. И неважно, справедливо это или нет." Как-то так, в общем. Еще раз извини за непрошенный совет.
@@igor_mutny В дополнение. Сначала надо заставить свой код работать, потом уже приводить его к адекватному виду. Так всегда было и есть, попытка написать сразу идеальную архитектуру на боевом проекте приведет к выгоранию, медленной разработке, увольнению (если это в компании), потому что там основная задача - закрывать таски, а не тешить свое эго
@@bigbimba2448 а существует ли она, эта идеальная архитектура? А то есть подозрение, что это что-то наподобие идеальной сферы. Типа можно какой-нибудь деревянный шарик шлифовать до бесконечности, но он все равно никогда не станет идеальной сферой. Рано или поздно всё равно нужно махнуть рукой и сказать: "Ладно, так сойдет!" 😁
Выгорание - вещь стремная. Я много лет страдал от выгорания, и пару лет исследовал эту проблему. Пришёл к выводу, что оно происходит, когда долго не видишь результата. То есть делаешь чёт делаешь, не знаешь, правильно или нет, плюс вообще не понятно, когда кончится все это и все, уже ничего не хочешь. В общем, для профилактики выгорания, сокращаешь задачки: и общее количество, и сами задачки по продолжительности. Например, вместо большой системы диалогов, перепрыгиваешь на вёрстку UI, делаешь пару кнопок и довольный идёшь отдыхать. А система диалогов потом доделать, когда состояние востановится
Нужно не саму ссылку репозитория копировать. Спустись ниже, там под How do I install NuGetForUnity? будет правильная ссылка. Для версий Unity 2019.3 и выше
@@issatay8876 и R3 и UniTask существуют для одной задачи - асинхронное программирование, но работают совершенно по разному. Так что концептуально, да, но эти видео не совсем добавят понимание
Спасибо за видео! Очень интересно про реактивное программирование. А также про Nuget для Unity )
Огромное спасибо! Канал очень помогает развиваться.
Спасибо большое за видео
Обычно юзается addTo при подписках. То есть, простое правило: написал subscribe, пиши addTo. В р3 запись выглядит так: ...Subscribe().AddTo(ref disposable);
Добавился реф.
Да, кстати, совсем забыл об этом
это значит, что слева от выражения не обязательно приваивать к IDisposable, вместо этого addTo?
@@7shockk да, это взаимозаменяемые варианты. С addTo покороче, компактнее.
@@savaslive Хмм, почему-то AddTo не хочет принимать IDisposable, нет такой перегрузки метода. Вместо этого передал туда CompositeDisposable, причем без ref.
@@7shockk у меня так-же
Очень полезно! Для понимания концепции "реактивного" программирования, как мне кажется, хорошо подходит привычный всем Excel. Мы же привыкли, что пишем в ячейке формулу и эта формула сработает не только в момент когда мы её пишем, но и в тот момент, когда данные в ячейках, которые участвуют в вычислениях - изменятся. Вот она и проявляется сама суть реактивщины.
Вот как это применять для "удобства" именно в игре ? если на изменение и здоровья и брони и всего чего угодно вызывать много раз обработчик - это не то что нужно для регистрации наносимого урона. Для выстраивания последовательностей во времени - это да, наверно удобно, но мне кажется что основная идея самого метода не в этом.
Хотелось бы пример для чего это удобно применять.
Автор, хочу отметить, что ты молодец. У меня к тебе нет никаких претензий, всё изложено грамотно и понятно. Однако у меня возникает вопрос: зачем? Эта библиотека создана для тех, кто не умеет работать с generics? Или для тех, для кого асинхронное программирование кажется чем-то запредельно сложным? Такой функционал (без преувеличения) реализуется довольно легко и быстро. Если я вдруг увижу в вакансии требование знания чего-то вроде R3, я сразу буду её пропускать (хотя такого, скорее всего, не случится, так как я работаю с C++). Я буду избегать таких вакансий, потому что сразу станет ясно: там работают одни джуниоры, которые совершенно не разбираются в оптимизации.
Почему я говорю об оптимизации? Потому что работа с асинхронным программированием и передачей контекста требует глубоких знаний. Мы должны понимать, что такие вещи нужно делать грамотно, ведь любая ошибка в манипуляции контекстами между потоками может привести к длительным простоям основного потока. Это особенно критично для мобильных устройств, где ресурсы ограничены.
Использование подобной библиотеки, на мой взгляд, обесценивает профессию программиста. Она позволяет даже человеку с минимальными знаниями и IQ около 40 работать с такими вещами, не углубляясь в суть. Я бы не рекомендовал её использовать, если цель - повышение своей квалификации и углубление знаний. Лучше разбираться в основах и писать код осознанно, чем полагаться на упрощённые инструменты, которые не способствуют профессиональному росту.
Ура! Новый видос
Спасибо!
Все то вы знаете)
♥
А как эта штука устроена под капотом? Как сильно это может повлиять на производительность? Если куча скалярных пропертей объектов сами становятся объектами?
Observable это ссылочной тип, несомненно, и он придуман не для того, чтобы создавать объекты каждый кадр. Нет, создал и пользуйся. Сама задача (уведомление об изменении) не подходит под вопрос оптимизации, ты либо используешь события, либо обёртка, либо сравнения и т.д.
@@gamedevlavka то есть, оно хорошо подходит для чегото что вызываеться редко, например ХП и еще чтото. я прав?
@@SSholger оно хорошо подходит там, где нужно следить за изменениями. Самый простой и известный аналог в юнити и с# - это Action, на который нужно подписываться и отписываться. Условно: ХП игрока поменялось - вызвать событие и уведомить всех подписчиков, что ХП поменялось. Здесь похожая история, но возни меньше, а понимания больше
@@gamedevlavka окей спасибо
Не рассмотрено ReactiveCommand :(
Я установил все точно так же как в видео, но почему то IDisposable не видит в R3, IDE предлагает только из библиотеки System.IDisposable, нормально ли использовать для R3 IDisposable из System?
@@Erosrolf так так и должно быть) IDisposable из System используется
@@gamedevlavka просто из комментариев было про AddTo(ref disposable), попробовал с IDisposable из System, у меня это не сработало. Ну да ладно, думаю это не так важно. Спасибо тебе за то что ты делаешь) Я по учебе делаю игру параллельно с твоим проектом Пилим Игру, ты мне очень помогаешь! Надеюсь доделаю и поделюсь в ТавернеРазработчика)
Я так понимаю, пример №4 не особо используется?
Ибо, зачем это, если это буквально шарповский ивент?
@@7shockk редко, но используется. Реактивные свойства в целом уменьшают надобность в отдельных событиях, но не совсем их убирают. Плюс сохраняется консистентность для подписки-отписки, что лучше читается
Здравствуйте, как вы боролись с выгоранием во время учёбы? Каждый раз после того как позанимаюсь , чувствую себя самозванцем и думаю что стоит все бросить. С трудом перебарываю такие мысли
Извини за непрошенный совет, просто меня тоже посещают подобные мысли.
Я в таких случаях просто говорю себе про свой код: "да пофиг, работает - и ладно" 😁 В конце концов, самое первое и главное требование к коду, которое всегда было, есть и будет - это чтобы код корректно выполнял свою работу. При том, что я, само собой, не пишу "на отъе..ись", а стараюсь каждый раз выжимать из себя по максимуму качества, на которое способен. Но всё равно же путь к профессионализму лежит через мегабайты говнокода, - это неизбежность 😁
Еще можно вспоминать (и даже просматривать) код, который ты писал полгода или год назад. Там сразу первые мысли: "Фу, ну и навалил же я тогда кринжа, сейчас бы я ни в жизнь не написал такое убожество, я бы сделал вот так и так, - это было бы намного лучше". И вторая мысль: "хм, ну, значит, прогресс-то есть, - и, судя по всему, немаленький". Главное - не броситься тут же переписывать его, чтобы не тратить время зря 😁
Ну и, в целом, поскольку "синдром самозванца" очень часто меня беспокоит вообще абсолютно во сферах жизни - далеко не только в программировании 😁- у меня сложилась такая своеобразная тактика борьбы с ним. Мой внутренний голос часто требует от меня "рассудить" ситуацию по "справедливости" типа "А достоин ли я вообще того-то и того-то?" И я научился быстро "включать циника" и переключаться на мысли типа: "Мне всё равно: если я смог что-то себе урвать, - значит, я это заслужил. И неважно, справедливо это или нет."
Как-то так, в общем. Еще раз извини за непрошенный совет.
@@igor_mutny В дополнение. Сначала надо заставить свой код работать, потом уже приводить его к адекватному виду. Так всегда было и есть, попытка написать сразу идеальную архитектуру на боевом проекте приведет к выгоранию, медленной разработке, увольнению (если это в компании), потому что там основная задача - закрывать таски, а не тешить свое эго
@@bigbimba2448 а существует ли она, эта идеальная архитектура? А то есть подозрение, что это что-то наподобие идеальной сферы. Типа можно какой-нибудь деревянный шарик шлифовать до бесконечности, но он все равно никогда не станет идеальной сферой. Рано или поздно всё равно нужно махнуть рукой и сказать: "Ладно, так сойдет!" 😁
Выгорание - вещь стремная. Я много лет страдал от выгорания, и пару лет исследовал эту проблему. Пришёл к выводу, что оно происходит, когда долго не видишь результата. То есть делаешь чёт делаешь, не знаешь, правильно или нет, плюс вообще не понятно, когда кончится все это и все, уже ничего не хочешь.
В общем, для профилактики выгорания, сокращаешь задачки: и общее количество, и сами задачки по продолжительности. Например, вместо большой системы диалогов, перепрыгиваешь на вёрстку UI, делаешь пару кнопок и довольный идёшь отдыхать. А система диалогов потом доделать, когда состояние востановится
@@gamedevlavka спасибо за ваш совет!
Error adding package: (url})
Unable to add package [(url)]
url копирую правильно. Не работает вообще ни на каком пакете
Нужно не саму ссылку репозитория копировать. Спустись ниже, там под How do I install NuGetForUnity? будет правильная ссылка. Для версий Unity 2019.3 и выше
Можно ли R3 заменить UnitTask?
@@issatay8876 и R3 и UniTask существуют для одной задачи - асинхронное программирование, но работают совершенно по разному. Так что концептуально, да, но эти видео не совсем добавят понимание
я оба плагина в своих проектах юзают, сочитаются они великолепно
Только у меня звук немного шипит?