Как дебажить в Unity? Поиск и отладка ошибок. Бонус: почему UnityEvent - плохо
Vložit
- čas přidán 13. 09. 2024
- Поддержи канал, бро!
paypal.me/game... - мир
boosty.to/game... - рф
И даже криптой (пока только Ethereum):
0x7a53325D1C36Eea7BbE8C6a8D00f2a0efd580e77
Вопрос о дебаге на собеседованиях возникает редко. А все потому, что этот навык настолько базовый, что про него даже спросить забывают. Тем не менее, многие не знают, как дебажить в Unity эффективно. Чтобы отладка тратила меньше времени и нервов.
Видео подходит, конечно, для начинающих больше. Тех, кто задается вопросом: как попасть в геймдев? Ну и там небольшой бонус для всех - почему UnityEvent - это зло, боль и страдания, и почему я рекомендую никогда им не пользоваться. Смотрим, комментим, лайкаем, подписываемся!
__________
Таверна разработчика - наш ламповый чат:
t.me/gamedevta...
Не менее ламповый дискорд сервер:
/ discord
Подписуйся на другие соц. сети:
Telegram: t.me/gamedevlavka
Twitter: / gamedevlavka
Twitter (личный): / vavilichevgd
0:00 Вступление, и вообще все видео, аг
Про UnityEvent
На них можно подписываться в ручную без инспектора. Тогда такие вещи, как переименование методов не будет болью.
К тому же, как уже верно написали их могут использовать люди, которые обычно в код не лезут. Но опять же, для таких целей я бы написал отдельный компонент, внутри которого происходила бы подписки-отписки. Я, например, стараюсь не пользоваться такими не надёжными вещами, как UnityEvent в инспекторе. Лучше все ручками делать.
Видос классный!
Очень хороший и полезный урок! Вот если бы сюда еще следующим уроком добавить тестирование, вообще было бы шикарно
Имеется ввиду юнит-тесты?
Угу, людям, которые не знают про дебаг, рассказывать про тесты. Тогда уж сразу про TDD 😀😀😀
@@gamedevlavka они самые, чтобы многие ошибки предотвратить еще на стадии написании кода и не дебажить впоследствии)
Да было бы неплохо какой нибудь небольшой ролик а может и большой
В формате поверхностного экскурса
Когда их использовать
Какие использовать
И как
@@Sumrov на канале Infallible Code был ролик про тестирование применительно к Unity. Тоже достаточно обзорный и на инглише.
Сумасшедше нужные видео! Спасибо большое.
В последнее время выступаю "онлайн-консультантом" для одного школьника. Вроде, шарит и пытается разобраться. Для меня стало культурным шоком, что он не знает про дебаг. Всегда думал, что это совершенно базовый инструментарий, без которого никак. Если бы с ним не пообщался, уже бы строчил комментарий по типу "для кого это видео с очевидными вещами?" 😀😀😀 Кстати, в студии можно сделать удобный финт. Когда встал на точке останова, можно поводить мышкой над строками. Перед ними появляется зеленый значок play. Можно ткнуть этот play, "промотав" несколько строчек. Удобно, если не хочешь заходить в какой-нибудь цикл.
Йо, оболденный материал. Спасибо) Го unit тесты может на какое-то следующее видео?
Похоже что будет)
Спасибо за видео!
Вот бы возродить серию про интерфейс... ;)
Что-то конкретное интересует?
@@gamedevlavka там всё остановилось на визуале и словах, что будем потом скриптбл обжект делать)
Просто интересно как оно дальше пойдет)
@@StratoCatster это какое видео? Что-то я подзабыл)
@@gamedevlavka если память не изменяет, то разговор был вот тут czcams.com/video/IMsOJgwcG4I/video.html
@@StratoCatster оу май) у меня есть мысль переработки инвентаря (именно бизнес логики), но сначала отсниму новый цикл по архитектуре, чтобы проще понимать суть вещей
Урок полезный. Но мне пришлось пересмотреть начальную часть видео повторно, чтобы понять, что именно мы поменяли. При всей полезности этого урока - он был бы гораздо понятнее, если бы изначально не было никаких подписок OnEnable, OnDisable. Они же не имеют никакого отношения к Unity-эвентам. Просто оставил бы один метод и всё. И тогда было бы понятно, что к чему. Изменили название - Unity Event "поломался". А дальше - добавляем поле для кнопки и подписываемся вручную. И всё работает гораздо надёжнее и безопаснее. Вот и всё.
Лайк и коммент в поддержку канала!
как то раньше и не задумывался в чем разница между шагом с заходом и обходом. типа куда это он собирается обходить и зачем)) а оно вон как работает
Мне говорили, что лучше не делать подписку на кнопки через ивенты юнити, но никто так и не обяьснил нормально почему? Теперь я понимаю почему и что это действительно гемор.
Спасибо за видео, было очень полезно!
а если нужно прокинуть переменную? в onClick можно а через подписку как?
Спасибо, крутой канал почему пол года тебя не рекомендовало
"Используйте подписку, лайк и колокольчик" :)
оч полезное видео, для меня особенно про юнити эвенты
Вопрос не по видео: что-то решил по поводу своего курса? Я бы взял с удовольствием
Он будет, но скорее всего не скоро, мало времени на проработку, поэтому делаю совсем понемногу (
11:53 Написать Debug.Log обычно гораздо быстрее, чем пользоваться отладчиком визуалки или райдера.
Да, со сниппетом еще быстрее. Например,
Debug.Log($" {$123$} ");
$END$
Но для более подробной и всеобъемлющей информации о поведении кода нужно запускать отладчик.
Оно "быстрее", когда у тебя очень простой алгоритм, и тебе нужно установить сам факт срабатывания метода. Если есть какая-то сложная логика, то ты на каждую строчку Debug.Log не поставишь.
@@andrey_aka_skif если логика сложная, согласен. Просто в ролике как-то категорично прозвучало, мол не надо дебажить строками.
@@servalstar это просто у вас второго монитора нету ))))
@@servalstar это просто у вас второго монитора нету ))))
В вижуалке работают только те кто не когда не работал в райдоре. Райдер лицензионный дорогой но есть триал на месяц который можно обновить новой почтой, все настройки райдера сохраняются и не чего после смены акка в райдере не меняется.
Эх, после райдера я не смог вернутся обратно в вижуалку и вернусь только в 2х случаях: 1. Если райдер прекратят поддерживать. 2. Если вижуалка станет намного лучше райдера.
Да, все так и по моему мнению тоже. Но знаю, что большинство работает в студии, пришлось стряхнуть пыль, так сказать. Чертовски неудобно код писать
У меня случился когнитивный диссонанс. Некий чувак в интернете уверенно вещает об удобстве инструмента, и складывается ощущение, что он прям профи и ему есть, с чем сравнивать. Однако у тебя запоминающаяся аватарка. Помню, какие благоглупости ты неделю назад вопрошал на Unity OK, и делаю вывод, что твои скилы и опыт не позволяют тебе быть компетентным в вопросе. Я Райдером не пользовался, но периодически посматриваю ролики, в которых авторы им пользуются. Не заметил чего-то принципиально необходимого, чего нет в VS 2022. Даже интересно, какого же функционала тебе не хватило в Студии?
@@andrey_aka_skif да там всё по мелочам, дизайн, удобство, райдер шустрее работает с юнити чем вижуалка (у меня мак на м1 , на винде хз) еше в райдере есть кнопочка explore в которой ты видешь расположение скриптов и можешь как удалять так и создавать новые что дублируется в юнити и это ОЧЕНЬ как удобно, также райдер очень удобно подвязан с гитом и если ты работаешь в команде ты можешь почти в реалтаме изменять код у себя и у команды что тоже очень экономит кучу времени, также в юнити можно открыть новый проект и открыть новый скрипт и он откроется в окне и в новой вкладке райдера где ты работал с предыдущем проектом - это очень сильно упрощает заимствование механик из старых проектов. Когда ты юзаешь юневские или дотнетовские функции со своими переменными то перед перемеными показывается сереньким цветом какие значение принимает переменная что не дает забыть флот это или инт переменная (мелочь но бывает что забываешь когда возвращаешься к коду через неделю и приятно что не нужно скролить в верх или команд лефтМ нажимать, да и лишний раз не отвлекаешся). В райдере можно выбирать цвет дравлайна) не кодом на бирать а имено цвет который конвертится в код, да и просто можно красить объекты навешивая матерьял и выбирать цвет в райдере...
Опять жи, это все мелочи но их много и я перечислил только что я часто использую. Если сравнивать райдер и вижуалку то к примеру : райдер это микрософтВорд, а вижуалка это блокнот.
@@Tumanop как и ожидалось, ты просто не умеешь пользоваться инструментом. Давай по пунктам:
- "всё по мелочам, дизайн, удобство" - это субъективное бла-бла-бла;
- "быстрее" - допустим;
- "кнопочка explore" - а в Студии типа нету? В Обозревателе решений меняешь режим отображения на Представление папки и получаешь то же самое;
- "подвязан с гитом" - а в Студии гита из коробки (и с отдельным пунктом меню) нету, ага. Приплыли. Выбор гит-клиента это крайне субъективная вещь. Кому-то CLI нравится, кому-то GitHub Desctop, кому-то ещё сотня на выбор. Мне Sourcetree нравится. Однако, git-клиент в студии есть. При этом не очень понятно, что ты собрался изменять в реалтайме. Сдается мне, что пул-реквесты не ваш метод?
- "в новой вкладке, где ты работал" - на любителя;
- "перед переменными показывается значение" - значение или тип? Тоже на любителя. Не люблю захламление вещами, которые я не писал. Да и куда скролить? Мышу навел на переменную и посмотрел тип. А если нужно скролить, то тут уже вопрос к дизайну классов и методов, а не к IDE;
- "можно выбирать цвет etc" - мало того, что полезно в незначительном числе случаях, так ещё и в целом откровенно вредно. Ибо поощряет тащить вьюхи в бизнес-логику;
- "Word vs блокнот" - ладно бы ты VS Code назвал блокнотом. Он им и является без расширений. Но студию? Я хз, как с тобой серьёзно разговаривать.
Короче, часть "лучшестей" сугубо субъективна, а часть присутствует в Студии из коробки. И ни слово не сказано, какой офигенный IntelliCode подвезли в 22-ю Студию.
@@andrey_aka_skif я вижуалку уже год не юзал, хз что там с ней. Да вобще пофиг что не нравится или нравится, все вольны выбирать что им подходит. Всё устраивает в вижуалке, да ради бога. Ты спросил, я ответил. Я выписал свои фичи что бросаются в глаза которые меня заставили пересесть.
Начнём с того, что весь смысл инспектора - это возможность работать с проектом, не забираясь в код. И это, в первую очередь, тулинг для разного рода дизайнеров, которым не стоит лезть в код. Это не безопасно как для кодовой базы, так и для психики дизайнеров. И Unity Event - это про то же. У любой игры есть бизнес-логика и представление. И всё, что касается инспектора, относится к уровню представления. И на этом уровне не может быть никаких важных для логики вещей и подписок. И тем более подписок на проектный доменный код, который имеет свойство меняться.
Если идёт разработка визуальной части какого-то модуля и оставляются UnityEvent на разного рода чихи по типу "нажато то-то", "открыто то-то", "такой-то прогресс-бар заполнен", то дизайнеры скажут вам спасибо, ведь они могут на эти вещи навешать запуск каких-то частиц или прочих визуальных приблуд, не бегая постоянно к программистам, и могут итерировать этот процесс сколь угодно долго. И цеплять они будут юнитёвые или любые другие ThirdParty-компоненты, у которых даже при обновлении есть поддержка совместимости. И даже если что-то отвалится, то отвалятся только эти установленные частицы, наличие которых не несёт важности для логики. А если в проекте есть валидатор, то перед сборкой он ещё покричит о том, что callback в редакторе потерялся.
Всё остальное важное для логики барахло будет общаться на делегатах, которые будут иметь корректный уровень доступа и не будут доступны для дизайнеров. У всего есть свои границы применения.
И говорить, что UnityEvent - плохо, сродни тому, что жаловаться на то, что банка с огурцами плохо забивает гвозди.
Про дизайнеров и тулзы для них - это в точку, согласен на 100%. И UnityEvent очень хорошо подходят для быстрого прототипирования, где по сути так и нужно: бизнес логика - суперважно, а обертка - не очень.
Но если проект крупный, то там и обертка важна. И если у тебя отвалятся какие-то частицы, то это может существенно повлиять на доходы игры, если это ftp. И если на этапе тестирования, или даже после релиза версии обнаружится, что отвалились какие-то важные частицы, то придут к разработчику, а не дизайнеру. Поэтому, возвращаясь к вопросу о тулзах для дизайнеров: на больших проектах пишутся свои тулзы для дизайнеров, пишется дока, и все работает как надо, и если что-то отвалится - это должно быть на виду.
@Лавка Разработчика ну давайте разбираться.
1) Если какая-то визуальщина отвалилась, то это не руинит проект. Добиться играбельного и стабильного релиза - это первостепенная задача. Остальное - мелочи разного пошиба с ощутимо меньшими издержками. Если отвалившаяся визуальщина как-то влияет на работоспосбность билда, то было проведено неверное деление между логикой и представлением. Это не беда UnityEvent, а беда проектирования.
2) Если какая-то визуальщина крайне важна, то она добавляется в релизный чек-лист. И если она будет отсутствовать в релизе, то в первую очередь пойдут к QA. Во вторую к исполнителю этой фичи. Причём исполнителем не обязан быть программистом. Тут я могу только посочувствовать тем, у кого принято валить все грехи человечества на дев-отдел. И только потом уйдут к дев, чтобы пропылесосить историю коммитов. Тоже никаких бед с UnityEvent.
3) QA - люди. И могут просмотреть. В целом и эффект пропал чисто по человеческой ошибке. Как и появляются все баги в проекте. В таком случае на любом крупном проекте есть автоматизация. Какой-нибудь Appium может наделать скриншотов с важным визуалом. Или какой-нибудь AltUnity поможет отследить активность тех или иных элементов в нужные моменты. Если проект не крупный, то и даже вручную это отловить уже не представляет крупной сложности.
4) А что разработчики? А разработчики на любом крупном проекте имеют какие-никакие тесты и инструменты валидации проекта. На крупном проекте сборки делаются в CI, который сам прогонит все тесты с этапом валидации и заруинит билд. Если нет CI, то в интересах разработчиков запустить это хотя бы вручную. Если ни тестов, ни валидации нет, то повод задуматься о применении хотя бы второго. Как минмум, это намного менее трудозатратно. Особенно, если есть какой-нибудь ThirdParty валидатор. Потерянные колбэки, ссылки, компоненты и прочее отлавливается очень просто и быстро.
5) Ну хорошо. Допустим, мы сдались и начинаем оборачивать всё, что видим, тратить силы на написание своего вакуумного "движка в движке" (очень утрируя). Ну уберём мы UnityEvent. Скроем все события под слоями абстракции. Но мы вынуждены оставлять какие-то настройки в инспекторе. Иначе дизайнеры будут напрямую работать с кодом. Ну будут это не UnityEvent, а сериализуемые типы. Ну забудет дизайнер галочку нужную поставить и снова никакого эффекта в билде. В цепочке исчезло какое-либо упоминание UnityEvent, но моё сообщение можно снова начать читать с п1, заменяя слова UnityEvent на какой-нибудь bool. И что, теперь bool - плохой?
У любого инструмента своё поле для применения. Понятно, что если применять UnityEvent там, где оно не подходит, то ничего хорошего из этого не выйдет. Если по каким-то причинам UnityEvent не гарантирует вам нужного уровня безопасности или функционала, то вы просто меняете инструмент. Вы ведь не будете использовать дальше молоток, если вместо гвоздей придётся начать "вбивать" шурупы? Вы возьмёте что-нибудь из области отвёрток.
Но в то же время бессмысленно человеческую невнимательность и неосторожность перевешивать на какой-то тип данных. На месте UnityEvent может быть что угодно. И это что угодно можно абсолютно так же неуместно использовать. И будет очень разумным подстраховаться, потому что на всех стульях усидеть невозможно: либо всё очень безопасно и с этим сложно работать, либо с этим удобно работать, но есть некоторые "дыры". И для подстраховки существуют тесты, валидаторы и анализаторы.
Если разобрать пример из видео и отстраниться от того, что это пример некорректного использования, то где вы видели, чтобы на крупном проекте применяли VS? А RIder при попытке переименовать метод, который используется как колбэк для UnityEvent, быканёт, что делается опасная операция. И предложит посмотреть сначала ассеты, где этот метод задействован. И даже если переименование случится, то метод в Unity успешно обновится. И всё будет работать как работало. Спасибо анализатору и автоматизациям JetBrains, которые подстраховали.
Вашей терпимости можно позавидовать, поэтому, в первую очередь, хочу поблагодарить за столь подробный комментарий.
Целиком и полностью поддерживаю, что в крупных проектах имеются автотесты и прочие системы автоматизации, которые не позволят проскочить подобному. Однако, автотесты и прочие тулзы также настраиваются людьми, и качество зависит от ресурсов, которые есть у компании. Качественные специалисты, бюджет и т.д. На моем опыте тех, кто может себе такое позволить - единицы, что означает, что вероятность попасть на крупный проект без автотестов достаточно велика. QA - тоже люди, как вы и сказали, они тоже могут кое-что пропустить. Вообще ситуаций может быть великое множество, почему отвалилась та или иная фича. На каждый кейс существует свое решение, и в случае использования UnityEvent, и проблем, возникающих с ним по тем или иным причинам, я предпочитаю не использовать UnityEvent ввиду неудобного поиска причин возникновения проблем в существенном количестве кейсов.
@@myownchannellol вот это ты ультанул) Спасибо, было интресно почитать
как всегда супер
Где взять окна внизу VS, у меня их нет. Как пробить почему нет возвращения из корутины?
Ну плюс того что ты метод привязываешь к кнопке, она может принимать в себе какой то аргумент.
А такая штука очень удобная! и много юзаю в своих проектах.
Пример: Есть магазин скинов. И кнопка выбора скинов... вот только скинов много, а метод то один.
По этому к кнопке привязываю Индекс (скина). Все по индексу обращаемся к массиву и от туда получаем наш скин.
Вроде бы элегантно и без порева :3
класс)👍
Понятно почему используется вижуалка, в райдере когда с зажатым командом на маке или контрлом на винде кликаешь левой кнопкой на метод то показывается все классы и методы которые слушают или ссылаются на метод на который кликнул.
Понял, что UnityEvent- плохо, но не понял, как сделать подругому
Если выразится колхозно
То в данном случае он это сделал через onClick.AddListener
Если нужны события, то просто использовать шарповские эвенты и экшены. То же самое, только в редакторе не светятся. И можно пройти по ссылкам, если их кто-то использует.
ЮнитиЭвенты фу, подписка на канал. Лайк поставил :)
А нельзя для переименования использовать ctrl+ r ×2? Вроде ведь тогда во всех классах переименуется ивент
Он вроде и использует Ctrl + R + R. Ты сам попробуй переименовать таким образом, а потом расскажи - изменилось у тебя имя эвента в настройках кнопки в редакторе или нет.
А если я захочу поменять цвет кнопки или картинку на ней? То как к ней обращаться внутри метода OnScriptButtonClick?
Debug это практически последнее что меня интересует в unity, и у меня вопрос эта важная тема?
Поиск и исправление ошибок - важная тема? Конечно да! Это большая часть работы разработчика, в Unity в том числе. Многие уделяют недостаточно внимания этому вопросу, и отсюда рождается множество вопросов, ответы на которые можно найти чуток приложив усилия.
@@gamedevlavka Спасибо что мне это написал, попробую уделить этой теме больше времени чем уделял раньше
Поиск и исправление ошибок - это САМАЯ ВАЖНАЯ тема в любом программировании. Ибо ошибки будут ВСЕГДА, независимо от стажа разработчика и его знания языков/инструментов. Все остальные темы являются вторичными, потому что если ты не можешь найти ошибку, и программа сваливается, то всё остальное уже не имеет значения.
При этом совершенно необязательно использовать всегда дебаг именно в таком виде. В некоторых случаях бывает быстрее (или проще) вставить куда-нибудь обычный Debug.Log("Выполнили что-то"); При этом программа продолжает работать, а в консоль выводится отметка о прохождении данной контрольной точки. Можно вывести значение переменной. Плюсом этого подхода является то, что у нас не блокируется экран Юнити. Всё работает как обычно. Тут уже по ситуации надо смотреть, как будет эффективнее искать.
А вообще поиск ошибок - это целое искусство. Что-то типа детектива))) Представь себя сыщиком или сотрудником контрразведки СМЕРШ в поисках опасного шпиона или диверсанта!
из этого на 70% состоит работа разработчика))))
Приходится смотреть на полуторной скорости. Почему нельзя заранее при монтаже ускорять?
Нет кнопки Подключить к Юнити. Есть кнопка Присоединение и она не работает как в видео.
sps
Всем привет, вопрос совершенно не по теме. Кто нибудь сталкивался с проблемой долгой компиляции скриптов в Unity. При чем проект совершенно пустой, создаешь скрипт и вылезает окошко "Reload Script Assemblies", вылезает буквально на пару секунд конечно, но все равно не понятно почему. Данная проблема на версии 2021.3.5f1. Компьютер новый и довольно мощный (i5 12400, 16gb, m2 ssd). Задаю вопрос здесь, так как в интернете ничего путного не нашел, и на русских и на зарубежных форумах. Если кто то знает в чем причина, пожалуйста ответье.
Аналогичная проблема. Задолбало.
Это не проблема, так и должно быть. У меня еще дольше
Сэнк ю
На самый главный вопрос так и не было ответа:) Как же узнать что произошло переименование метода, и в инспекторе пропала ссылка на него?
Когда пол дня работаешь над с проектом а потом тестировщик возвращает тебе репорт с багами))
Лайк и коммент в поддержку канала!
В последнее время выступаю "онлайн-консультантом" для одного школьника. Вроде, шарит и пытается разобраться. Для меня стало культурным шоком, что он не знает про дебаг. Всегда думал, что это совершенно базовый инструментарий, без которого никак. Если бы с ним не пообщался, уже бы строчил комментарий по типу "для кого это видео с очевидными вещами?" 😀😀😀 Кстати, в студии можно сделать удобный финт. Когда встал на точке останова, можно поводить мышкой над строками. Перед ними появляется зеленый значок play. Можно ткнуть этот play, "промотав" несколько строчек. Удобно, если не хочешь заходить в какой-нибудь цикл.