Большое спасибо, полезно было узнать некоторые бонусные нюансы, как например с наведением. Толково, Есть конечно более лёгкие варики на "ф", Но твой ролик действительно даёт побольше логики
Супер!! Как всегда на высоте !! А Вот инвентарь очень жду !!! Тема очень интересная и сложная на самом деле! Но то как ты объясняешь.. думаю будет все понятно и как всегда на высоте! Ожидаем !
Крутой видос, очень понятно, но однако страшно делать какие либо похожие механики после приколов как Nintendo патентует чуть ли не все механики, а могут и другие компании так делать 😅
Ого Привет! Надеюсь у тебя все одлично, давно тебя не смотрел, интерестно тебя видеть в столь неожиданном амплуа чтоли )) У тебя круто получаеться, продолжай. Жду телеграм канал или дискорд хаха
Автору желаю удачи в развитие канала . Подписался и жду новых видео . Не знаю как там ютуб работает , надеюсь длины комментария для продвижения ролика хватит )
Дружище, спасибо за старания и прикольный туториал. ИМХО я бы все-таки использовал внешнюю сферу коллизии и внутреннюю или капсулу или бокс по направлению камеры с игнором всего, кроме канала интеракшин(на оверлап). И два виджета на картинки - моветон. Один виджет, картинки, как переменные, с нулевой видимостью по дефолту(избавишься от doonce и передачи виджетов). По бегиноверлап внешней коллизии ставишь визибилити на первую картинку и по бегиноверлап бокса меняешь визибилити на картинках, соответсвенно по эндоверлап меняешь визибилити наоборот - результат, не нужен локальный массив(в которых ты же сам и запутался), и не возникает баг с пересозданием виджетов(новичку выловить баг будет сложно - потому как все вроде работает) - логика построения проще и на стандартных евентах )).
@@olliverkatana4168 спасибо за такой развернутый комментарий. По поводу 2-х виджетов согласен. Да и на сколько я помню я говорил об этом. Все ты говоришь правильно. Подход который описал ты тоже имеет право быть. Особенно в рамках прототипирования. По сути тут вообще все что угодно можно делать лишь бы создавалась иллюзия механики. Однако я считаю, что мой подход чуть более оптимизирован. Сфир коллижены очень тяжёлые компоненты и они каждый тик обрабатывают если в них чтото попало, например пуля, другой объект интерактивный, пол, стул да что угодно. Магии нету, они ведь как то работают, даже чтобы определить что они должны это игнорировать и в этом плане обычная сфера гораздо проще. Это слова от разработчиков движка. На базе этого знания я и переработал дефолтный подход, который показывают всем. Так же мне кажется он немного интереснее просто сам по себе и в рамках обучения. Хотя даже здесь я могу ошибаться. Потому что я так же учусь. Я покапался в ассетах и на самом деле подходов вообще целая куча. У каждого свои плюсы и минусы. А так как я сейчас собираю все эти механики в виде прототипа для будущего проекта, то хочется заложить хоть чуть чуть оптимизации. Доработка механик, например избавление от двух виджетов будет на этапе когда это механика точно окажется в конечном проекте после тестов. Подойдёт ли она к моей игре или нет. Пока это просто прототипирование, не более. Еще раз спасибо за ценный комментарий.
@@Tistreza.project у тебя идет мультисфератрейс на таймере, затем также лайнтрейс на коллизию предмета тоже считай на тике и сама сфера коллизии предмета. вот уже считай три обработчика коллизии. То что я предлагаю - две коллизии и оверлап евенты они обрабатывают только по заданному каналу, время тика обработки ты тоже можешь выставить в настройках сфер тем самым снизив нагрузку на обработку. Не буду утверждать, но чисто интуитивно мне кажется, что нет разницы обрабатывать коллизию сферытрейса и сферыкомпонента (по кастомному времени тика). А по поводу "только учусь" - дык это бесконечный процесс )). Обращайся если что ))).
@olliverkatana4168 надо тестировать. Кстати на канале ask a dev об этом говорили, в смысле про тяжесть колиженов. Плюс не забывай, что необходимо добиться определённого результата. Ты должен получить эффект когда ты точно не попадаешь по объекту перекрестием. Твой подход рисует лишь виджеты. Тебе еще нужно как то взаимодействовать. А это значит что тебе придется использовать еще трейс. Плюс не забывай что надо еще как то будет синхронизировать длину трейса с внутренним колиженом и конкретным объектом. А что если объекты рядом находятся и твои колижены пересекаются?, как тогда? Мой трейс - это уже взаимодействие. Так что некорректное сравнение. У тебя два колижена у меня одна сфера. А трейс уже ловит объекты для взаимодействия и меняет картинку в виджете ( в идеале).
@@olliverkatana4168 да и еще мне кажется, что когда 100-ня(обекты на уровне) ждут одного(персонажа) и используют для этого функционал - это не очень с точки зрения архитектуры общей.
Крутое видео, очень все понравилось, но меня мучает вопрос о использовании On Begin Component Overlap (при использовании Collision Sphere) и Multi Sphere Trace by Channel. Так то конечно понятно, что begin overlap при 100 элементов на сцене будет обрабатывать каждый кадр на столкновение с игроком (и получается 100 * на 10 1000 элементов). А Multi Sphere Trace by Channel обрабатывается каждые 0.01 (или мы можем задать другое значение обновление сферы (скан)) Мне просто кажется, что то и другое по нагрузке одинаково (возможно конечно я ошибаюсь). Возможно ли где-то прочитать более подробно по данным компонентам ? На оф сайте на счет этого ничего не написаро) спасибо
@@ЕвгенийДубасов-ы1р вот и я толком не нашел. Опираюсь на канал ask a dev, там в туториале про радар было утверждение про "тяжесть" Сфир колижн, по сравнению с сфир трейсом
@@wertolotik блин да. То что я назвал парадигмой скорее является принципами или концепциями. Запутался, давненько я этими понятиями не оперировал. Спасибо за подсказку.
вот у меня очень важный вопрос почему халтурят выграх Resident Evil типо смотреш как сделаны обекты в роде красиво но нельзя ими пользоватся как в rust игре хоть это и юнити имею виду игры как бы сказать ватные можно сравнить просто посмотреть как выживают выгре как двигуюся предметы игроки и так далие возможно такое сделать игру rust на движке rust или есть какиэта ограничения ? сильно упадёт фпс ? или как ?
@@AnimeBOSTAN сегодня реализовать в рамках игрового проекта можно абсолютно все. Технических ограничений нету. Однако "все и сразу" не делают и тому наверняка есть причины. Я думаю, что при разработке той или йной мезаники стоит вопрос "а зачем? " Какую ценность она принесет. Стоит ли вкладывать деньги, время и усилие сотни человек, чтобы адаптировать ее в проект. Сделать просто чтобы было? Так себе идея. Каждый проект это высказывание, и надо оставить только то чтр будет подпитывать эти высказывания или цели. Я думаю это лишь малая часть причин.
@@Tistreza.project у меня есть хорошая идея какую игру можно сделать онлайн но боюсь будет кучя читеров так как движок плохой а вот в танках wot там есть Читы но там нету стрелять снаряд через всю карту и нету мелиард золота так как все находится на сервере вот или можно сделать там ток Читы есть но там на перезарядку противника и есть прицел афтонавидкние но и то он не идеален нету танков которые литают воздухе
Вот таких подробных и объемных уроков с долгими и внятными рассуждениями и не хватает! Продолжайте, это очень интересно!
Как всегда - пушка, спасибо за старания!
Надеюсь это действительно так) спасибо)
@@Tistreza.project жду продолжение, подбирание предмета, инвентаря, складывание в ящик, хы)))
Да очень хотелось бы осмотр предметов)
Это не очень сложно, думаю, что в ближайшее время)
Большое спасибо, полезно было узнать некоторые бонусные нюансы, как например с наведением. Толково, Есть конечно более лёгкие варики на "ф", Но твой ролик действительно даёт побольше логики
Отличная речь, отлично подан материал, разобрал по костям с указаниями на ошибки и дальнейшие косяки, ну просто кайф, спасибо за старания.
Спасибо за отзыв. Это важно. Скоро уже новое видео, думаю получится не хуже.
Шикарно, большое спасибо
Спасибо)
Отлично, очень полезно
Опачки. Новый видос. Спасибо за урок, как всегда всё разжёвано до мелочей, очень понятное объяснение. Удачи и продолжай в том же духе)
Хи-хи)
Очень круто❤ ждём ещё видео про повторение механик❤
Буит!)
Супер!! Как всегда на высоте !! А Вот инвентарь очень жду !!! Тема очень интересная и сложная на самом деле! Но то как ты объясняешь.. думаю будет все понятно и как всегда на высоте! Ожидаем !
Да у меня есть на примете общая логика инвентаря(не моя полностью). Я собираюсь с мыслями. Это прям супер глобальная задача.
@@Tistreza.project очень надеюсь, что будет еще урок с сохранениями
нужно ещё
будет еще.
Класно! Если будет осмотр предметов то вопще шик!
Будет) И кажется получается неплохо=)
Как всегда супер!)
Спасибо)
Спасибо)
Крутой видос, очень понятно, но однако страшно делать какие либо похожие механики после приколов как Nintendo патентует чуть ли не все механики, а могут и другие компании так делать 😅
Хотел бы я сказать "дану брось ты!)", но в сегодняшние времена все может быть)
Ого Привет! Надеюсь у тебя все одлично, давно тебя не смотрел, интерестно тебя видеть в столь неожиданном амплуа чтоли )) У тебя круто получаеться, продолжай. Жду телеграм канал или дискорд хаха
Автору желаю удачи в развитие канала . Подписался и жду новых видео .
Не знаю как там ютуб работает , надеюсь длины комментария для продвижения ролика хватит )
@@Denain007 ахах, спасибо)
Дружище, спасибо за старания и прикольный туториал. ИМХО я бы все-таки использовал внешнюю сферу коллизии и внутреннюю или капсулу или бокс по направлению камеры с игнором всего, кроме канала интеракшин(на оверлап). И два виджета на картинки - моветон. Один виджет, картинки, как переменные, с нулевой видимостью по дефолту(избавишься от doonce и передачи виджетов). По бегиноверлап внешней коллизии ставишь визибилити на первую картинку и по бегиноверлап бокса меняешь визибилити на картинках, соответсвенно по эндоверлап меняешь визибилити наоборот - результат, не нужен локальный массив(в которых ты же сам и запутался), и не возникает баг с пересозданием виджетов(новичку выловить баг будет сложно - потому как все вроде работает) - логика построения проще и на стандартных евентах )).
@@olliverkatana4168 спасибо за такой развернутый комментарий. По поводу 2-х виджетов согласен. Да и на сколько я помню я говорил об этом. Все ты говоришь правильно. Подход который описал ты тоже имеет право быть. Особенно в рамках прототипирования. По сути тут вообще все что угодно можно делать лишь бы создавалась иллюзия механики. Однако я считаю, что мой подход чуть более оптимизирован. Сфир коллижены очень тяжёлые компоненты и они каждый тик обрабатывают если в них чтото попало, например пуля, другой объект интерактивный, пол, стул да что угодно. Магии нету, они ведь как то работают, даже чтобы определить что они должны это игнорировать и в этом плане обычная сфера гораздо проще. Это слова от разработчиков движка. На базе этого знания я и переработал дефолтный подход, который показывают всем. Так же мне кажется он немного интереснее просто сам по себе и в рамках обучения. Хотя даже здесь я могу ошибаться. Потому что я так же учусь. Я покапался в ассетах и на самом деле подходов вообще целая куча. У каждого свои плюсы и минусы. А так как я сейчас собираю все эти механики в виде прототипа для будущего проекта, то хочется заложить хоть чуть чуть оптимизации. Доработка механик, например избавление от двух виджетов будет на этапе когда это механика точно окажется в конечном проекте после тестов. Подойдёт ли она к моей игре или нет. Пока это просто прототипирование, не более. Еще раз спасибо за ценный комментарий.
@@Tistreza.project у тебя идет мультисфератрейс на таймере, затем также лайнтрейс на коллизию предмета тоже считай на тике и сама сфера коллизии предмета. вот уже считай три обработчика коллизии. То что я предлагаю - две коллизии и оверлап евенты они обрабатывают только по заданному каналу, время тика обработки ты тоже можешь выставить в настройках сфер тем самым снизив нагрузку на обработку. Не буду утверждать, но чисто интуитивно мне кажется, что нет разницы обрабатывать коллизию сферытрейса и сферыкомпонента (по кастомному времени тика). А по поводу "только учусь" - дык это бесконечный процесс )). Обращайся если что ))).
@olliverkatana4168 надо тестировать. Кстати на канале ask a dev об этом говорили, в смысле про тяжесть колиженов. Плюс не забывай, что необходимо добиться определённого результата. Ты должен получить эффект когда ты точно не попадаешь по объекту перекрестием. Твой подход рисует лишь виджеты. Тебе еще нужно как то взаимодействовать. А это значит что тебе придется использовать еще трейс. Плюс не забывай что надо еще как то будет синхронизировать длину трейса с внутренним колиженом и конкретным объектом. А что если объекты рядом находятся и твои колижены пересекаются?, как тогда? Мой трейс - это уже взаимодействие. Так что некорректное сравнение. У тебя два колижена у меня одна сфера. А трейс уже ловит объекты для взаимодействия и меняет картинку в виджете ( в идеале).
Более того не забывай, что у тебя сотни объектов рисуют свои колижены на уровне, даже два колижена. А у меня только одна сфера у персонажа.
@@olliverkatana4168 да и еще мне кажется, что когда 100-ня(обекты на уровне) ждут одного(персонажа) и используют для этого функционал - это не очень с точки зрения архитектуры общей.
Хорошая работа! Можете сказать как вы учились разработке?
Крутое видео, очень все понравилось, но меня мучает вопрос о использовании On Begin Component Overlap (при использовании Collision Sphere) и Multi Sphere Trace by Channel. Так то конечно понятно, что begin overlap при 100 элементов на сцене будет обрабатывать каждый кадр на столкновение с игроком (и получается 100 * на 10 1000 элементов). А Multi Sphere Trace by Channel обрабатывается каждые 0.01 (или мы можем задать другое значение обновление сферы (скан)) Мне просто кажется, что то и другое по нагрузке одинаково (возможно конечно я ошибаюсь). Возможно ли где-то прочитать более подробно по данным компонентам ? На оф сайте на счет этого ничего не написаро) спасибо
@@ЕвгенийДубасов-ы1р вот и я толком не нашел. Опираюсь на канал ask a dev, там в туториале про радар было утверждение про "тяжесть" Сфир колижн, по сравнению с сфир трейсом
12:00 - "наследование это одна из парадигм объектно-ориентированного программирования"?
@@wertolotik ну инкапсуляция, наследование и полиморфизм.
@@Tistreza.project ООП это парадигма, а наследование это концепция внутри ооп)
@@Tistreza.project короч ты в терминах запутался походу, а так норм.
@@wertolotik блин да. То что я назвал парадигмой скорее является принципами или концепциями. Запутался, давненько я этими понятиями не оперировал. Спасибо за подсказку.
вот у меня очень важный вопрос почему халтурят выграх Resident Evil типо смотреш как сделаны обекты в роде красиво но нельзя ими пользоватся как в rust игре хоть это и юнити имею виду игры как бы сказать ватные можно сравнить просто посмотреть как выживают выгре как двигуюся предметы игроки и так далие возможно такое сделать игру rust на движке rust или есть какиэта ограничения ? сильно упадёт фпс ? или как ?
@@AnimeBOSTAN сегодня реализовать в рамках игрового проекта можно абсолютно все. Технических ограничений нету. Однако "все и сразу" не делают и тому наверняка есть причины. Я думаю, что при разработке той или йной мезаники стоит вопрос "а зачем? " Какую ценность она принесет. Стоит ли вкладывать деньги, время и усилие сотни человек, чтобы адаптировать ее в проект. Сделать просто чтобы было? Так себе идея. Каждый проект это высказывание, и надо оставить только то чтр будет подпитывать эти высказывания или цели. Я думаю это лишь малая часть причин.
@@Tistreza.project у меня есть хорошая идея какую игру можно сделать онлайн но боюсь будет кучя читеров так как движок плохой а вот в танках wot там есть Читы но там нету стрелять снаряд через всю карту и нету мелиард золота так как все находится на сервере вот или можно сделать там ток Читы есть но там на перезарядку противника и есть прицел афтонавидкние но и то он не идеален нету танков которые литают воздухе
Дай свой Дискорд пж мне нравятся твои видео