ОШИБКИ ДЖУНОВ
Под постом о различиях между Junior, Middle и Senior родилось бурное обсуждение, что очень радует. И мне захотелось вам рассказать топ ошибок, которые я совершал сам на позиции джуна.
Какого джуна можно назвать хорошим? Junior - это специалист, который уже должен быть готов к бою, но компания прекрасно понимает, что ему нужно помогать и дообучать, поэтому на 2-3 джунов в компании должен быть хотя бы 1 Middle, который будет помогать им и развивать их.
Но это была матчасть. А теперь про мои ошибки.
СТРАХ ЧЕГО-ТО НЕ ЗНАТЬ.
Как-то раз упала мне задача на плавное заполнения счётчика и наставник посоветовал сделать это при помощи корутин. С английским тогда были проблемы, пошерстил интернет и как мог нашёл инфу, документация в то время была слабая. Написал код, всё красиво, но при запуске корутины Unity просто крашилась. Из-за чрезмерной твердолобости я старался справится с проблемой сам и потратил на это весь день. В итоге проблема заключалась в фигне, я не указал yield return, на что и указал проходящий мимо наставник. Я боялся показать, что чего-то не знаю, и тратил время впустую, хотя мог спросить своего наставника и решить задачу гораздо быстрее. Не бойтесь признать, что вы чего-то не знаете, ибо вопрос приводящий к вашему росту не может быть глупым.
Получился лонгрид, чтобы вы не устали читать, я разбил его на две части. Вторая каминг сун, так сказатб.
Пишите, какие забавные ошибки допускали вы, когда только начинали кодить?
Под постом о различиях между Junior, Middle и Senior родилось бурное обсуждение, что очень радует. И мне захотелось вам рассказать топ ошибок, которые я совершал сам на позиции джуна.
Какого джуна можно назвать хорошим? Junior - это специалист, который уже должен быть готов к бою, но компания прекрасно понимает, что ему нужно помогать и дообучать, поэтому на 2-3 джунов в компании должен быть хотя бы 1 Middle, который будет помогать им и развивать их.
Но это была матчасть. А теперь про мои ошибки.
СТРАХ ЧЕГО-ТО НЕ ЗНАТЬ.
Как-то раз упала мне задача на плавное заполнения счётчика и наставник посоветовал сделать это при помощи корутин. С английским тогда были проблемы, пошерстил интернет и как мог нашёл инфу, документация в то время была слабая. Написал код, всё красиво, но при запуске корутины Unity просто крашилась. Из-за чрезмерной твердолобости я старался справится с проблемой сам и потратил на это весь день. В итоге проблема заключалась в фигне, я не указал yield return, на что и указал проходящий мимо наставник. Я боялся показать, что чего-то не знаю, и тратил время впустую, хотя мог спросить своего наставника и решить задачу гораздо быстрее. Не бойтесь признать, что вы чего-то не знаете, ибо вопрос приводящий к вашему росту не может быть глупым.
Получился лонгрид, чтобы вы не устали читать, я разбил его на две части. Вторая каминг сун, так сказатб.
Пишите, какие забавные ошибки допускали вы, когда только начинали кодить?
👍31🔥8🤔4
ОШИБКИ ДЖУНОВ 2
Здорово, ~boy~цы! Как и обещал, делюсь с вами второй частью ошибок (первая здесь), на которых тупил сам и вижу, как их допускают многие джуны сегодня.
ОТСУТСТВИЕ ТЕСТИРОВАНИЯ
Тестирование - вещь, которая сэкономит вам уйму времени. Бывали случаи, когда метод получал некорректные данные, и я не понимал, что же на это влияет. Долго шарился в коде, прыгая между тремя скриптами и анализируя каждую строку. В итоге проблема решилась в кратчайшие сроки после применения break point. Он позволяет построчно выполнить код и проверить данные на нужных участках кода. Это не всё тестирование, но его база, в которую должны уметь все.
НЕУМЕНИЕ ПРОГНОЗИРОВАТЬ
Прогнозирование и сроки - неотъемлемая проблема любого джуна, и я не был исключением. Очень тяжело дать чёткую оценку задаче, когда ты не замерял скорость своей работы. Решить её можно одним способом - замеряйте, сколько времени у вас уходит на реализацию механики, даже если вы делаете свой инди-проект. С каждой выполненной задачей вы будете четче понимать сроки её выполнения, а также увидите прирост скорости при наборе опыта.
Эх, эти беззаботные времена…
Накидайте 🔥, если вам заходит такой формат, и я запилю такой же пост о мидлах
Здорово, ~boy~цы! Как и обещал, делюсь с вами второй частью ошибок (первая здесь), на которых тупил сам и вижу, как их допускают многие джуны сегодня.
ОТСУТСТВИЕ ТЕСТИРОВАНИЯ
Тестирование - вещь, которая сэкономит вам уйму времени. Бывали случаи, когда метод получал некорректные данные, и я не понимал, что же на это влияет. Долго шарился в коде, прыгая между тремя скриптами и анализируя каждую строку. В итоге проблема решилась в кратчайшие сроки после применения break point. Он позволяет построчно выполнить код и проверить данные на нужных участках кода. Это не всё тестирование, но его база, в которую должны уметь все.
НЕУМЕНИЕ ПРОГНОЗИРОВАТЬ
Прогнозирование и сроки - неотъемлемая проблема любого джуна, и я не был исключением. Очень тяжело дать чёткую оценку задаче, когда ты не замерял скорость своей работы. Решить её можно одним способом - замеряйте, сколько времени у вас уходит на реализацию механики, даже если вы делаете свой инди-проект. С каждой выполненной задачей вы будете четче понимать сроки её выполнения, а также увидите прирост скорости при наборе опыта.
Эх, эти беззаботные времена…
Накидайте 🔥, если вам заходит такой формат, и я запилю такой же пост о мидлах
🔥93👍2😁2👎1
ПРОБЛЕМЫ UNITY
Недостаток Unity из коробки в том, что его базового функционала очень часто недостаточно. Вы скажете: “Да, но всегда есть Asset Storе, где я могу купить всё что мне нужно!”. Хмм… а что если я скажу вам, что в сторе есть далеко не всё, и я сам сталкивался с огромным количеством задач, решений для которых просто не было или они стоили каких-то космических сумм.
Расскажу на одном примере. Я столкнулся с проблемой настройки путей с развилками. Если коротко, то вручную расставить точки пути и настроить углы для кривых та ещё dark fantasy. Платить огромный прайс для решения одной задачи не хотелось да и финансы не позволяли.
И что делать?
И тут я вспомнил, что я ✨программист✨ и накидал расширение сам. Оно получилось клassное по функционалу, но в коде творилась дичь. Мою проблему это решило, самодельное расширение (которое обошлось мне в 0$) визуализировало все точки и пути до них и бонусом добавляло функционал для удобного создания и редактирования пути.
Это я всё к чему. Расширения допиливают "коробочный" Unity до идеала и сильно ускоряют разработку. Они упрощают и автоматизируют однотипные задачи, а также экономят кучу времени. Если вы умеете работать с расширениями Unity, то вместо того, чтобы долбиться с однотипными задачами (которые ещё и не каждый джун может решить), вы пишете расширение, которое частично автоматизирует, визуализирует и по итогу значительно упрощает задачу.
Если вам знакома эта боль, то накидайте реакций, и я расскажу, какими инструментами пользуюсь сам. И пишите в комментах самые тупые задачи, которые приходилось решать на Unity :)
Недостаток Unity из коробки в том, что его базового функционала очень часто недостаточно. Вы скажете: “Да, но всегда есть Asset Storе, где я могу купить всё что мне нужно!”. Хмм… а что если я скажу вам, что в сторе есть далеко не всё, и я сам сталкивался с огромным количеством задач, решений для которых просто не было или они стоили каких-то космических сумм.
Расскажу на одном примере. Я столкнулся с проблемой настройки путей с развилками. Если коротко, то вручную расставить точки пути и настроить углы для кривых та ещё dark fantasy. Платить огромный прайс для решения одной задачи не хотелось да и финансы не позволяли.
И что делать?
И тут я вспомнил, что я ✨программист✨ и накидал расширение сам. Оно получилось клassное по функционалу, но в коде творилась дичь. Мою проблему это решило, самодельное расширение (которое обошлось мне в 0$) визуализировало все точки и пути до них и бонусом добавляло функционал для удобного создания и редактирования пути.
Это я всё к чему. Расширения допиливают "коробочный" Unity до идеала и сильно ускоряют разработку. Они упрощают и автоматизируют однотипные задачи, а также экономят кучу времени. Если вы умеете работать с расширениями Unity, то вместо того, чтобы долбиться с однотипными задачами (которые ещё и не каждый джун может решить), вы пишете расширение, которое частично автоматизирует, визуализирует и по итогу значительно упрощает задачу.
Если вам знакома эта боль, то накидайте реакций, и я расскажу, какими инструментами пользуюсь сам. И пишите в комментах самые тупые задачи, которые приходилось решать на Unity :)
🔥64👍15👌2👏1🤔1
Как быть клassным разрабом или инструменты для создания расширений
Пишите крутые расширения и будете хорошим разработчиком. На чем писать? Вопрос хороший, поэтому выполняю обещание и рассказываю про те инструменты, которые юзаю сам:
1️⃣ CustomEditor - здесь пишем функциональный инспектор с кнопками под любые действия;
2️⃣ EditorWindow - здесь создаем отдельные окна и наполняем их функционалом;
3️⃣ OnSceneGUI + Handles - здесь визуализируем любые данные на сцене.
Какая структура должна быть у класса, который кастомизирует инспектор?
Я как-то в армии служил…Кхм, то есть был один случай, в котором кастомный инспектор сильно упростил мне жизнь. Была задача в мобильной игре со сборкой мусора: на полу должно лежать множество конфетти. Я решил спаунить конфетти зонами на этапе сборки уровня (так как в Awake заспаунить 150+ мелких обьектов not ♂smartass♂). И для удобства левел дизайнеров написал расширение, которое позволяет делать это без разработчика.
По пунктам:
Сначала создал класс, который будет унаследован от Editor (в библиотеке UnityEditor) и над ним указал атрибут, который говорит, что это кастомный редактор ConfettiSpawner.
@
В OnEnable получаем экземпляр класса, инспектор которого мы расширяем.
@
Переопределяем метод OnInspectorGUI. Внутри него мы можем описать все нужные для нового инспектора поля и кнопки. Порядок размещения элементов в инспекторе напрямую зависит от положения элемента в коде.
@
Перерисовка происходит каждый кадр, но не стоит этого бояться, ведь в билд эти скрипты не тянутся.
Профит: очень маленькое расширение упростило работу и помогло в оптимизации проекта.
Если вам интересна тема расширений, то реактите 👍 и в следующем посте расскажу о расширениях, которые мы делаем в Azur Games.
Пишите крутые расширения и будете хорошим разработчиком. На чем писать? Вопрос хороший, поэтому выполняю обещание и рассказываю про те инструменты, которые юзаю сам:
1️⃣ CustomEditor - здесь пишем функциональный инспектор с кнопками под любые действия;
2️⃣ EditorWindow - здесь создаем отдельные окна и наполняем их функционалом;
3️⃣ OnSceneGUI + Handles - здесь визуализируем любые данные на сцене.
Какая структура должна быть у класса, который кастомизирует инспектор?
Я как-то в армии служил…Кхм, то есть был один случай, в котором кастомный инспектор сильно упростил мне жизнь. Была задача в мобильной игре со сборкой мусора: на полу должно лежать множество конфетти. Я решил спаунить конфетти зонами на этапе сборки уровня (так как в Awake заспаунить 150+ мелких обьектов not ♂smartass♂). И для удобства левел дизайнеров написал расширение, которое позволяет делать это без разработчика.
По пунктам:
Сначала создал класс, который будет унаследован от Editor (в библиотеке UnityEditor) и над ним указал атрибут, который говорит, что это кастомный редактор ConfettiSpawner.
@
В OnEnable получаем экземпляр класса, инспектор которого мы расширяем.
@
Переопределяем метод OnInspectorGUI. Внутри него мы можем описать все нужные для нового инспектора поля и кнопки. Порядок размещения элементов в инспекторе напрямую зависит от положения элемента в коде.
@
Перерисовка происходит каждый кадр, но не стоит этого бояться, ведь в билд эти скрипты не тянутся.
Профит: очень маленькое расширение упростило работу и помогло в оптимизации проекта.
Если вам интересна тема расширений, то реактите 👍 и в следующем посте расскажу о расширениях, которые мы делаем в Azur Games.
👍59🔥13🥰2👏1
Привет, котаны :3 Я тут для вас приготовил кое-что!
Короткая предыстория: когда создавал тг, я долго думал о формате, чтобы поймать баланс, не стать википедией в телеге и не скатиться в обычные it-мемасы, и вот, кажется, нащупал кое-что.
Я стал ментором для “усредненного джуниор программиста”.
Мы начали заниматься, и я увидел у него те же ошибки, которые когда-то допускал сам.
И тут в голове складывается 2+2 и я понимаю, что это именно то, что может быть вам интересно. На реальных примерах разбирать те ошибки, которые мешают ему сейчас и которые когда-то не давали мне самому стать уверенным мидлом.
Мы с ним занимаемся уже неделю и прогресс налицо. Если вам нравится идея, то покажите это активом и я сразу дропну разбор первой из его ошибок
З.ы. Это не @rsakutin 😂
Короткая предыстория: когда создавал тг, я долго думал о формате, чтобы поймать баланс, не стать википедией в телеге и не скатиться в обычные it-мемасы, и вот, кажется, нащупал кое-что.
Я стал ментором для “усредненного джуниор программиста”.
Мы начали заниматься, и я увидел у него те же ошибки, которые когда-то допускал сам.
И тут в голове складывается 2+2 и я понимаю, что это именно то, что может быть вам интересно. На реальных примерах разбирать те ошибки, которые мешают ему сейчас и которые когда-то не давали мне самому стать уверенным мидлом.
Мы с ним занимаемся уже неделю и прогресс налицо. Если вам нравится идея, то покажите это активом и я сразу дропну разбор первой из его ошибок
З.ы. Это не @rsakutin 😂
👍88🔥11🥰2🤩2❤1👌1
ПРОКАЧИВАЕМ ДЖУНА
Ваша активность под прошлым постом реально♂so horny♂ горяча❤️🔥
Короче, я решил не ждать и уже сегодня поделиться кодом нового джуниора на менторстве.
👉Начнем с простенького класса, который отвечает за отключение звука. В скрытых методах здесь только подписка и отписка.
Пишите в комментах, какие увидели ошибки и какая из них самая страшная?
Завтра расскажу, как мы это исправили)
Ваша активность под прошлым постом реально
Короче, я решил не ждать и уже сегодня поделиться кодом нового джуниора на менторстве.
👉Начнем с простенького класса, который отвечает за отключение звука. В скрытых методах здесь только подписка и отписка.
Пишите в комментах, какие увидели ошибки и какая из них самая страшная?
Завтра расскажу, как мы это исправили)
🔥14👍6🤯2
CODE-REVIEW
В комментах к прошлому посту вы указали почти на все ошибки, давайте добью и перечислю весь список, который увидел. Кстати, самый полный список написал @thomas_in_the_dark, красавчик!
Итак, ТОП 10 ошибок кода джуниор программиста. Шучу, никакого топа, но часть из них реально критичны:
1) Именование класса. Нейминг - это важно, имя класса должно отражать его функционал и ответственность. В данном случае класс ничего не отслеживает и не может называться Tracker;
2) Именование полей и переменных. Нейминг - это важноХ2. Мне в свое время очень помогло простое правило - по названию должно быть понятно назначение конкретной ячейки;
3) Порядок полей - SerializeField надо бы выше private поставить;
4) Излишние булевые флаги - сам когда-то страдал от такого и ловил некорректные состояния в булевом поле. Чисто по опыту, в 90% случаев от bool поля можно избавиться));
5) Свойство IsGameAudioOn - такой же булевый флаг, только открытый на чтение. Я бы привязал значение к состоянию AudioListener;
6) OnInBackgroundChange - прослойка для переключения флага. После удаления которого метод станет бесполезным;
7) Методы - это действия, а действия - это глаголы (да, я учился в 5 классе и проходил глаголы, дайте хоть где-то это использую). Короче, метод именуем с глагола и точка;
8) Switch методы - результат выполнения таких методов непредсказуем, они просто переворачивают состояние. Я заменяю на методы включить/выключить и кайфую;
9) Комментарии - в данном случае они обусловлены целевой платформой и тонкостями работы с ней, но я их не оставляю. Код это же как книга, если без комментариев от автора не прочесть, то с книгой что-то не так;
10) Переключение звука после показа рекламы и при помощи вызова метода - разделены на 2 разных значения. Возвращаемся к пункту 8, в SwitchAudio сильно переусложнено переключение состояния.
Неплохой списочек вышел, однако 🌚
Пишите, как бы вы исправили этот код, ну и накидывайте 🔥 и будем вникать дальше. Уже сегодня вечером я покажу вам, как мы исправили этот код)
В комментах к прошлому посту вы указали почти на все ошибки, давайте добью и перечислю весь список, который увидел. Кстати, самый полный список написал @thomas_in_the_dark, красавчик!
Итак, ТОП 10 ошибок кода джуниор программиста. Шучу, никакого топа, но часть из них реально критичны:
1) Именование класса. Нейминг - это важно, имя класса должно отражать его функционал и ответственность. В данном случае класс ничего не отслеживает и не может называться Tracker;
2) Именование полей и переменных. Нейминг - это важноХ2. Мне в свое время очень помогло простое правило - по названию должно быть понятно назначение конкретной ячейки;
3) Порядок полей - SerializeField надо бы выше private поставить;
4) Излишние булевые флаги - сам когда-то страдал от такого и ловил некорректные состояния в булевом поле. Чисто по опыту, в 90% случаев от bool поля можно избавиться));
5) Свойство IsGameAudioOn - такой же булевый флаг, только открытый на чтение. Я бы привязал значение к состоянию AudioListener;
6) OnInBackgroundChange - прослойка для переключения флага. После удаления которого метод станет бесполезным;
7) Методы - это действия, а действия - это глаголы (да, я учился в 5 классе и проходил глаголы, дайте хоть где-то это использую). Короче, метод именуем с глагола и точка;
8) Switch методы - результат выполнения таких методов непредсказуем, они просто переворачивают состояние. Я заменяю на методы включить/выключить и кайфую;
9) Комментарии - в данном случае они обусловлены целевой платформой и тонкостями работы с ней, но я их не оставляю. Код это же как книга, если без комментариев от автора не прочесть, то с книгой что-то не так;
10) Переключение звука после показа рекламы и при помощи вызова метода - разделены на 2 разных значения. Возвращаемся к пункту 8, в SwitchAudio сильно переусложнено переключение состояния.
Неплохой списочек вышел, однако 🌚
Пишите, как бы вы исправили этот код, ну и накидывайте 🔥 и будем вникать дальше. Уже сегодня вечером я покажу вам, как мы исправили этот код)
🔥34👍7🤩1
ИСПРАВЛЯЕМ КОД
Я для себя выработал правило, что код должен быть простым. Я могу сравнить код с книгой, а программиста с её автором. Чтобы понять хорошую книгу, не надо общаться с автором или читать его комментарии. С кодом тоже самое, поэтому сейчас расскажу, как мы изменили этот код, чтобы он стал “открытой книгой”:
1) Переименовали класс в Background Audio, убрали из имени несуществующую ответственность;
2) За ненадобностью убрали bool isBackground;
3) Переименовали свойство из IsGameAudioOn в лаконичный Muted. Вместо смены состояния вручную значение свойства теперь зависит от состояния AudioListener, что полностью исключает проблему некорректного состояния;
4) Непредсказуемый SwitchAudio сменили на четкий SetState с указанием состояния в параметре;
5) Выделили 2 публичных метода, включение/выключение, что позволило нам избавиться от SwitchGameAudio и OnInBackgroundChange;
6) Т.к. обработчики в данном случае являлись лишь прослойкой, которые вызывали смену состояния, решили избавиться от них и подписать напрямую методами Mute и Unmute. С точки зрения BackgroundAudio не так важно, что реклама закончилась или началась, нам гораздо важнее, что мы включаем или выключаем звук в ответ на это.
Вот такой код вышел. Мне кажется, что он стал меньше, логичнее и понятнее. Весь скрипт легко прочитать и без напряга понять, что за что отвечает и как он работает.
Если вам понравился такой формат, то покажите это бурными 👍, и я буду пилить эту рубрику дальше :)
Пишите в комментариях, что для вас самое главное в коде 👇
Я для себя выработал правило, что код должен быть простым. Я могу сравнить код с книгой, а программиста с её автором. Чтобы понять хорошую книгу, не надо общаться с автором или читать его комментарии. С кодом тоже самое, поэтому сейчас расскажу, как мы изменили этот код, чтобы он стал “открытой книгой”:
1) Переименовали класс в Background Audio, убрали из имени несуществующую ответственность;
2) За ненадобностью убрали bool isBackground;
3) Переименовали свойство из IsGameAudioOn в лаконичный Muted. Вместо смены состояния вручную значение свойства теперь зависит от состояния AudioListener, что полностью исключает проблему некорректного состояния;
4) Непредсказуемый SwitchAudio сменили на четкий SetState с указанием состояния в параметре;
5) Выделили 2 публичных метода, включение/выключение, что позволило нам избавиться от SwitchGameAudio и OnInBackgroundChange;
6) Т.к. обработчики в данном случае являлись лишь прослойкой, которые вызывали смену состояния, решили избавиться от них и подписать напрямую методами Mute и Unmute. С точки зрения BackgroundAudio не так важно, что реклама закончилась или началась, нам гораздо важнее, что мы включаем или выключаем звук в ответ на это.
Вот такой код вышел. Мне кажется, что он стал меньше, логичнее и понятнее. Весь скрипт легко прочитать и без напряга понять, что за что отвечает и как он работает.
Если вам понравился такой формат, то покажите это бурными 👍, и я буду пилить эту рубрику дальше :)
Пишите в комментариях, что для вас самое главное в коде 👇
👍74🔥9
Котаны, я увидел, что тема прокачки Unity вам зашла! И вы просили подробнее рассказать о работе с инструментами.
Мы с Ромой подумали и решили, что будет классно замутить интенсив. У меня в Azure скоро отпуск, и я решил целую неделю провести с вами.
Да, анонс!
с 6 по 11 декабря я буду в онлайне 24/7:
- Только живое общение;
- Трушный Code-review. Разберу код для вас на стриме;
- 2 лекции по вечерам 6 и 8 числа с 19:00 до 21:00 (МСК);
- В остальное время - проверка домашек и общение с вами в дискордике;
И самый сок 10 и 11 декабря: на два полных выходных мы разобьём вас на команды, чтобы вместе решать сложную техническую задачу, и параллельно будем давать Code Review.
p.s. Специальным гостем будет Рома, он также будет давать вам обратную связь)
Короче, по сути, замутим 5-дневную пыточную для вас.
ВАЖНО! Возьму только 40 человек, хотел бы больше, но не вывезу. Я хочу быть уверен, что проработаю все фишки индивидуально с каждым. Поэтому кто не успеет, прошу понять и простить.
По прайсу: 9 900 руб. Чекайте всю инфу на сайте.
Жду всех желающих, будет жарко 🔥
Мы с Ромой подумали и решили, что будет классно замутить интенсив. У меня в Azure скоро отпуск, и я решил целую неделю провести с вами.
Да, анонс!
с 6 по 11 декабря я буду в онлайне 24/7:
- Только живое общение;
- Трушный Code-review. Разберу код для вас на стриме;
- 2 лекции по вечерам 6 и 8 числа с 19:00 до 21:00 (МСК);
- В остальное время - проверка домашек и общение с вами в дискордике;
И самый сок 10 и 11 декабря: на два полных выходных мы разобьём вас на команды, чтобы вместе решать сложную техническую задачу, и параллельно будем давать Code Review.
p.s. Специальным гостем будет Рома, он также будет давать вам обратную связь)
Короче, по сути, замутим 5-дневную пыточную для вас.
ВАЖНО! Возьму только 40 человек, хотел бы больше, но не вывезу. Я хочу быть уверен, что проработаю все фишки индивидуально с каждым. Поэтому кто не успеет, прошу понять и простить.
По прайсу: 9 900 руб. Чекайте всю инфу на сайте.
Жду всех желающих, будет жарко 🔥
👍12🔥6⚡3
ПРОИЗВОДИТЕЛЬНОСТЬ В ИГРАХ
Меня бесит стандартный профайлер. Мне нужно больше цифр, больше данных о том, как работает моя игра. Иначе сидишь и тупо тыкаешь пальцем вслепую, пытаясь нащупать: “А чо вообще докрутить-то надо, куда жмать. Работай б**ть”.
И тут на днях вижу видос. Не от Сакутина, конечно, а от Unity (но тоже неплохо), и в нем рассказывают, как можно кастомизировать Unity Profiler. Давайте расскажу вам о своем видении всей этой истории
Вообще, кастомизация профайлера возможна в 3-х направлениях:
- Маркеры;
- Счетчики;
- Модули.
Для работы с кастомизацией я использую пакет profiling.core.
ОЧЕНЬ краткий гайд: в Package Manager нажимаем на добавление, выбираем пункт “Add package by name” и указываем com.unity.profiling.core в качестве имени.
Не хочу долбить вас многобуквием, поэтому сегодня только о маркерах:
У стандартного кода Unity очень много специальных маркеров, с которыми можно оценить время выполнения различных блоков кода и определить, какой блок требует оптимизации.
При помощи Profiling.Core я вставляю в свой код маркеры, которые отображаются в профайлере всего за 3 шага:
I. Подключить Unity.Profiling
II. Создать экземпляр маркера и указать в качестве аргумента имя маркера, отображаемое в профайлере.
Также возможна передача данных с маркером при помощи ProfilerMarker<Type>
III. При помощи using (_findPathMarker.Auto()) и фигурных скобок мы определяем область для проведения анализа скорости выполнения.
После этого в профайлере появляется маркер с данными о времени выполнения. Ну и всё, теперь есть 100%-я инфа о том, какая часть кода грузит систему больше всего, значит с ней и работаю дальше.
Это я всё к чему? Unity даёт разработчикам (занавес) всё больше возможностей для кастомизации, и те, кто используют их, чувствуют себя гигачадами с крутым инспектором и самописными расширениями. Хотите стать таким же классным? А у меня тут как раз скоро интенсив, где мы разберем ОТ и ДО, как создавать расширения для Unity.
👇 Пишите в комментариях, как вы оцениваете производительность в проектах. Накидайте реакции и совсем скоро поговорим о счетчиках (за ЖКХ естессна). Всех обнял :)
Меня бесит стандартный профайлер. Мне нужно больше цифр, больше данных о том, как работает моя игра. Иначе сидишь и тупо тыкаешь пальцем вслепую, пытаясь нащупать: “А чо вообще докрутить-то надо, куда жмать. Работай б**ть”.
И тут на днях вижу видос. Не от Сакутина, конечно, а от Unity (но тоже неплохо), и в нем рассказывают, как можно кастомизировать Unity Profiler. Давайте расскажу вам о своем видении всей этой истории
Вообще, кастомизация профайлера возможна в 3-х направлениях:
- Маркеры;
- Счетчики;
- Модули.
Для работы с кастомизацией я использую пакет profiling.core.
ОЧЕНЬ краткий гайд: в Package Manager нажимаем на добавление, выбираем пункт “Add package by name” и указываем com.unity.profiling.core в качестве имени.
Не хочу долбить вас многобуквием, поэтому сегодня только о маркерах:
У стандартного кода Unity очень много специальных маркеров, с которыми можно оценить время выполнения различных блоков кода и определить, какой блок требует оптимизации.
При помощи Profiling.Core я вставляю в свой код маркеры, которые отображаются в профайлере всего за 3 шага:
I. Подключить Unity.Profiling
II. Создать экземпляр маркера и указать в качестве аргумента имя маркера, отображаемое в профайлере.
Также возможна передача данных с маркером при помощи ProfilerMarker<Type>
III. При помощи using (_findPathMarker.Auto()) и фигурных скобок мы определяем область для проведения анализа скорости выполнения.
После этого в профайлере появляется маркер с данными о времени выполнения. Ну и всё, теперь есть 100%-я инфа о том, какая часть кода грузит систему больше всего, значит с ней и работаю дальше.
Это я всё к чему? Unity даёт разработчикам (занавес) всё больше возможностей для кастомизации, и те, кто используют их, чувствуют себя гигачадами с крутым инспектором и самописными расширениями. Хотите стать таким же классным? А у меня тут как раз скоро интенсив, где мы разберем ОТ и ДО, как создавать расширения для Unity.
👇 Пишите в комментариях, как вы оцениваете производительность в проектах. Накидайте реакции и совсем скоро поговорим о счетчиках (за ЖКХ естессна). Всех обнял :)
👍20🔥5⚡2❤1
РАСШИРЕНИЯ В РЕАЛЬНЫХ ПРОЕКТАХ
“А чо ты в Azur Games-то делаешь?” (cпойлер: крутые вещи). Если серьезно, то одна из задач моего отдела - это создание плееблов. Если вы подумали о чем-то формата "вытащи палочку, чтобы Фредди выплыл из GYM", то нет. Мы делаем крутые плееблы от Dungeon Masters, которые могут 1 в 1 повторять сложную механику оригинальной игры. Из недавнего - мы перенесли точь-в-точь механику Perfect Cream в плеебл без провисаний. Между прочим, это генерация меша на ходу, которая запускается на мобилке и весит 2.2мб!
Сам в восторге, но не всегда всё было так круто. Давайте об одной из проблем, с которыми мы сталкивались: минимальным разрешением считается 890х1920, и это нужно было учитывать при расстановке GO, особенно в проектах со статичной камерой. По итогу, мы разработаем под минимальное разрешение, а на более широком девайсе зона с игровыми объектами останется всё также узкая.
Проблема понятна. Что делать? Расширение вызвался сделать мой коллега, Илья Константинов. Спойлер: оно получилось очень удобным и красивым, и мне очень захотелось похвастаться мощью наших ребят.
Он написал систему сохранения информации о расположении, повороте и размере объектов в сцене. При смене пропорций экрана система переключалась между сохраненными данными. Причем она позволяет динамически изменять объекты на базе Transform и RectTransform. Зафиналили это всё написанием кастомного инспектора, который позволяет задать любому объекту на сцене желаемые значения трансформа для различных пропорций, тем самым добившись оптимального положения объектов для любого устройства.
Если вы хотите научиться писать такие же сексуальные расширения для редактора как и Илья, то вам повезло, ведь у меня тут как раз скоро интенсив, где мы с вами разберемся, как их создавать.
“А чо ты в Azur Games-то делаешь?” (cпойлер: крутые вещи). Если серьезно, то одна из задач моего отдела - это создание плееблов. Если вы подумали о чем-то формата "вытащи палочку, чтобы Фредди выплыл из GYM", то нет. Мы делаем крутые плееблы от Dungeon Masters, которые могут 1 в 1 повторять сложную механику оригинальной игры. Из недавнего - мы перенесли точь-в-точь механику Perfect Cream в плеебл без провисаний. Между прочим, это генерация меша на ходу, которая запускается на мобилке и весит 2.2мб!
Сам в восторге, но не всегда всё было так круто. Давайте об одной из проблем, с которыми мы сталкивались: минимальным разрешением считается 890х1920, и это нужно было учитывать при расстановке GO, особенно в проектах со статичной камерой. По итогу, мы разработаем под минимальное разрешение, а на более широком девайсе зона с игровыми объектами останется всё также узкая.
Проблема понятна. Что делать? Расширение вызвался сделать мой коллега, Илья Константинов. Спойлер: оно получилось очень удобным и красивым, и мне очень захотелось похвастаться мощью наших ребят.
Он написал систему сохранения информации о расположении, повороте и размере объектов в сцене. При смене пропорций экрана система переключалась между сохраненными данными. Причем она позволяет динамически изменять объекты на базе Transform и RectTransform. Зафиналили это всё написанием кастомного инспектора, который позволяет задать любому объекту на сцене желаемые значения трансформа для различных пропорций, тем самым добившись оптимального положения объектов для любого устройства.
Если вы хотите научиться писать такие же сексуальные расширения для редактора как и Илья, то вам повезло, ведь у меня тут как раз скоро интенсив, где мы с вами разберемся, как их создавать.
👍16🔥5⚡1😁1🤔1
Привет, котаны 🌚
У меня тут скоро интенсив начинается, а в комментариях и в личку прилетают вопросы по типу "Я не так давно изучаю Unity, но хотел бы записаться на интенсив, какие знания нужны для прохождения?"
Написание расширений для Unity - это не та тема, которая входит в большинство курсов, ведь не является обязательной для трудоустройства.
Можно сказать, что это отдельная ветка прокачки Unity-специалиста с несколькими перками, которая открывает для него уйму новых возможностей, а также разблокирует перк для собеса под названием "Повыпендриваться своими расширениями и показать, что ты полезнее, чем кажешься на первый взгляд", ведь нужда в расширениях есть всегда, а пишут их далеко не все.
Что же нужно для лучшего усвоения интенсива?
Сверим темы по чек-листу:
- Поля и свойства (Куда без них?)
- ENUM
- Коллекции
- Методы
- Желание впитывать большое количество информации 🧠
- События
- Работа с записью и чтением файлов (на самом деле, не обязательно, я расскажу)
- Статичные классы и методы
- Чуточку понимания наследования
- Боевой настрой 🦾
Как вы могли заметить, великим программистом для понимания расширений быть не нужно, но по мере прокачки навыка программирования вы сможете найти больше применений для расширений и легко выбить сочный райз!
Кстати говоря, программа получается довольно сочной, накидайте 🔥 и я расскажу вам о ней во всех подробностях!)
У меня тут скоро интенсив начинается, а в комментариях и в личку прилетают вопросы по типу "Я не так давно изучаю Unity, но хотел бы записаться на интенсив, какие знания нужны для прохождения?"
Написание расширений для Unity - это не та тема, которая входит в большинство курсов, ведь не является обязательной для трудоустройства.
Можно сказать, что это отдельная ветка прокачки Unity-специалиста с несколькими перками, которая открывает для него уйму новых возможностей, а также разблокирует перк для собеса под названием "Повыпендриваться своими расширениями и показать, что ты полезнее, чем кажешься на первый взгляд", ведь нужда в расширениях есть всегда, а пишут их далеко не все.
Что же нужно для лучшего усвоения интенсива?
Сверим темы по чек-листу:
- Поля и свойства (Куда без них?)
- ENUM
- Коллекции
- Методы
- Желание впитывать большое количество информации 🧠
- События
- Работа с записью и чтением файлов (на самом деле, не обязательно, я расскажу)
- Статичные классы и методы
- Чуточку понимания наследования
- Боевой настрой 🦾
Как вы могли заметить, великим программистом для понимания расширений быть не нужно, но по мере прокачки навыка программирования вы сможете найти больше применений для расширений и легко выбить сочный райз!
Кстати говоря, программа получается довольно сочной, накидайте 🔥 и я расскажу вам о ней во всех подробностях!)
🔥47👍4⚡1🤔1
УЛУЧШАЕМ ИНСПЕКТОР БЕЗ РАСШИРЕНИЙ
Для каждого инспектора написать расширение нереально. Несмотря на все плюсы, это овер до*уя кода, а значит много работы. Это факт, грустный, но факт. И что делать? А чо насчёт атрибутов)
Атрибуты - это маркеры, указывающие на особое поведение. Их размещают над классами, методами и полями. Сегодня без лонгридов и по делу расскажу только про атрибуты, которые влияют на инспектор и размещаются над полями.
Ловите список тех, которые я сам юзаю в работе:
- SerializeField - отображает приватное поле в инспекторе;
- Range[Min,Max] - делает из числового поля слайдер с диапазоном значений от Min до Max;
- Multiline - расширяет текстовое поле, добавляя возможность писать более 1 строки текста;
- Header("Name") - создает заголовок с текстом Name, которым вы сможете разграничить несколько смысловых блоков с полями;
- Space(Height) - создает пустое пространство перед полем.
👇 Делитесь в комментах атрибутами, которые используете чаще всего
Для каждого инспектора написать расширение нереально. Несмотря на все плюсы, это овер до*уя кода, а значит много работы. Это факт, грустный, но факт. И что делать? А чо насчёт атрибутов)
Атрибуты - это маркеры, указывающие на особое поведение. Их размещают над классами, методами и полями. Сегодня без лонгридов и по делу расскажу только про атрибуты, которые влияют на инспектор и размещаются над полями.
Ловите список тех, которые я сам юзаю в работе:
- SerializeField - отображает приватное поле в инспекторе;
- Range[Min,Max] - делает из числового поля слайдер с диапазоном значений от Min до Max;
- Multiline - расширяет текстовое поле, добавляя возможность писать более 1 строки текста;
- Header("Name") - создает заголовок с текстом Name, которым вы сможете разграничить несколько смысловых блоков с полями;
- Space(Height) - создает пустое пространство перед полем.
👇 Делитесь в комментах атрибутами, которые используете чаще всего
🔥28👍7🤔2🥴1🐳1
Доброго дня и хороших выходных, котаны)
У нас с Ромой скоро стартует интенсив. Ваша активность под недавним постом о навыках просто 🥰
Выполняю обещание и рассказываю поподробнее про программу курса👇
У нас будет 2 лекции + закрепление материала через дз и 2 дня практики:
Лекция №1 - Написание расширений для редактора при помощи CustomEditor и визуализация данных с OnSceneGUI + Handles
За два часа разберем:
- Структуру расширений редактора;
- Все возможные элементы, которые используются в кастомном инспекторе;
- GUILayoutOption для более точной настройки элементов;
- Немного GUI. skin для создания сочных отдельных блоков;
- Горизонтальные и вертикальные группы;
- Создание красивых кнопок с любыми иконками или значками;
- Создание блоков с возможностью их сворачивания;
- Визуализация данных при помощи OnSceneGUI + Handles;
- Практическая отработка навыков на 2-3 примерах.
В конце отвечу на все ваши вопросы)
Лекция №2 - Написание расширений в отдельных окнах при помощи EditorWindow.
За 2-3 часа разберем:
- В чем отличие кастомизации инспектора от написания отдельных окон;
- Как создать дополнительные окна Unity, которые открываются из меню;
- Как зонировать окно;
- Модификацию внешнего вида окна;
- Пак небольших уникальных элементов;
- Как построить сетку и рисовать внутри окна;
- Напишем 3 расширения для Unity
Ну и, конечно, отвечу на все вопросы.
Практические дни
На два полных выходных (10 и 11 декабря) мы разобьём вас на команды, которые будут решать сложную техническую задачу. Параллельно с этим Code Review ваших работ на протяжении всего дня.
А ещё всем закину свой pdf, в котором собрал всю документацию по разработке расширений)
Пост выходит слишком большим и пришлось чуть сократить, в курсе будет ещё больше приятностей :3
Как вам план? Уже во вторник стартует жесткая и плотная работа в Dungeon, не призываю, но и не хочу, чтобы потом кто-то обижался, из 40 мест осталось совсем немного. Все подробности здесь
У нас с Ромой скоро стартует интенсив. Ваша активность под недавним постом о навыках просто 🥰
Выполняю обещание и рассказываю поподробнее про программу курса👇
У нас будет 2 лекции + закрепление материала через дз и 2 дня практики:
Лекция №1 - Написание расширений для редактора при помощи CustomEditor и визуализация данных с OnSceneGUI + Handles
За два часа разберем:
- Структуру расширений редактора;
- Все возможные элементы, которые используются в кастомном инспекторе;
- GUILayoutOption для более точной настройки элементов;
- Немного GUI. skin для создания сочных отдельных блоков;
- Горизонтальные и вертикальные группы;
- Создание красивых кнопок с любыми иконками или значками;
- Создание блоков с возможностью их сворачивания;
- Визуализация данных при помощи OnSceneGUI + Handles;
- Практическая отработка навыков на 2-3 примерах.
В конце отвечу на все ваши вопросы)
Лекция №2 - Написание расширений в отдельных окнах при помощи EditorWindow.
За 2-3 часа разберем:
- В чем отличие кастомизации инспектора от написания отдельных окон;
- Как создать дополнительные окна Unity, которые открываются из меню;
- Как зонировать окно;
- Модификацию внешнего вида окна;
- Пак небольших уникальных элементов;
- Как построить сетку и рисовать внутри окна;
- Напишем 3 расширения для Unity
Ну и, конечно, отвечу на все вопросы.
Практические дни
На два полных выходных (10 и 11 декабря) мы разобьём вас на команды, которые будут решать сложную техническую задачу. Параллельно с этим Code Review ваших работ на протяжении всего дня.
А ещё всем закину свой pdf, в котором собрал всю документацию по разработке расширений)
Пост выходит слишком большим и пришлось чуть сократить, в курсе будет ещё больше приятностей :3
Как вам план? Уже во вторник стартует жесткая и плотная работа в Dungeon, не призываю, но и не хочу, чтобы потом кто-то обижался, из 40 мест осталось совсем немного. Все подробности здесь
🔥21👍4🤡2👏1🤔1👌1
ЗАВТРА СТАРТУЕМ
Котаны, час Х близок. Уже завтра начнём прокачивать Unity, и врата вВАЛЬХАЛЛУ 5-дневный напильник для вас откроются.
Осталась пара свободных мест, кто хочет залететь, ещё есть шанс ворваться. Все подробности здесь!
А я пойду завершать финальные приготовления, страдать х*йней эту неделю я вам точно не дам 🔥
Котаны, час Х близок. Уже завтра начнём прокачивать Unity, и врата в
Осталась пара свободных мест, кто хочет залететь, ещё есть шанс ворваться. Все подробности здесь!
А я пойду завершать финальные приготовления, страдать х*йней эту неделю я вам точно не дам 🔥
🔥13👍3👌2🤔1🤡1
Фух, привет, котаны 😼
Потерялся на неделю, но не из-за безделья. Плотно поработал с ребятами на тренинге по созданию расширений для Unity. Рассказываю, как все прошло:
Я подготовил материала на 4 часа по два на каждую лекцию (ага, если бы…), но так получилось, что на первой лекции за 3 часа я объяснил только процентов 80 из всего материала.
Пришлось в срочном порядке провести ещё одну часовую лекцию сверху на следующий день, из-за чего финальная лекция сдвинулась на пятницу, впритык к практикуму.
Наученный опытом первой лекции, я переработал вторую, и уже она прошла прям з*бись, от ребят прилетел хороший фидбек!
Дальше была ПРАКТИКА. Распределили всех на команды, каждая из которых должна была запилить своё расширение для постройки уровня. Суть расширения: Префабы закидываются в специальную сгенерированную папку, расширение их вытягивает и строит грид с превьюшками, из которого можно выбирать устанавливаемый префаб, причем у нас таких каталогов может быть несколько, переключаются при помощи тулбара.
Ребята бились над задачей как львиные тигры, а я 2 дня нон-стоп был на саппорте и помогал разруливать проблемы, с которыми команды сталкивались.
Вобщем, все ребята были реально толковые, очень заряжали меня и друг друга. Но самое крутое, что все вовлеклись в интенсив и е*ашили от души.
Кстати говоря, больше всего ребятам зашла командная работа. Некоторые сработались настолько, что задумались над совместным проектом после интенсива.
Мне приятно работать с такими людьми, а код-ревью в онлайне порадовал ещё больше, не без ошибок, конечно, но за все работы мы проговорили много крутых приемов. Накидайте🔥и я разберу пару кейсов с интенсива.
В общем и целом ребята оценили тренинг по достоинству, о чем говорят душевные отзывы, которые греют сердце. Всем спасибо, было пизд*то! :3
Потерялся на неделю, но не из-за безделья. Плотно поработал с ребятами на тренинге по созданию расширений для Unity. Рассказываю, как все прошло:
Я подготовил материала на 4 часа по два на каждую лекцию (ага, если бы…), но так получилось, что на первой лекции за 3 часа я объяснил только процентов 80 из всего материала.
Пришлось в срочном порядке провести ещё одну часовую лекцию сверху на следующий день, из-за чего финальная лекция сдвинулась на пятницу, впритык к практикуму.
Наученный опытом первой лекции, я переработал вторую, и уже она прошла прям з*бись, от ребят прилетел хороший фидбек!
Дальше была ПРАКТИКА. Распределили всех на команды, каждая из которых должна была запилить своё расширение для постройки уровня. Суть расширения: Префабы закидываются в специальную сгенерированную папку, расширение их вытягивает и строит грид с превьюшками, из которого можно выбирать устанавливаемый префаб, причем у нас таких каталогов может быть несколько, переключаются при помощи тулбара.
Ребята бились над задачей как львиные тигры, а я 2 дня нон-стоп был на саппорте и помогал разруливать проблемы, с которыми команды сталкивались.
Вобщем, все ребята были реально толковые, очень заряжали меня и друг друга. Но самое крутое, что все вовлеклись в интенсив и е*ашили от души.
Кстати говоря, больше всего ребятам зашла командная работа. Некоторые сработались настолько, что задумались над совместным проектом после интенсива.
Мне приятно работать с такими людьми, а код-ревью в онлайне порадовал ещё больше, не без ошибок, конечно, но за все работы мы проговорили много крутых приемов. Накидайте🔥и я разберу пару кейсов с интенсива.
В общем и целом ребята оценили тренинг по достоинству, о чем говорят душевные отзывы, которые греют сердце. Всем спасибо, было пизд*то! :3
🔥44👍6🤯2⚡1