Лавка Разработчика
3.36K subscribers
406 photos
43 videos
16 files
641 links
Мы тут игры пилить будем, или как?

YouTube: https://youtube.com/@gamedevlavka

Автор: @vavilichev

Все контакты: https://linktr.ee/vavilichev
Download Telegram
Использовать регионы для удобства работы с кодом

Любой класс можно условно разделить на участки кода, объединённые общим свойством. Такие участки кода удобно обрамлять тегами, которые позволяют "свернуть" участок кода.

Далее представлены типичные регионы, которые я обычно выделяю в коде.

1. CONSTANTS - участок кода с объявлением констант.
2. EVENTS (1) - участок кода с объявлением событий.
3. LIFECYCLE - участок кода с нативными методами MonoBehaviour (пр. Awake(), Start(), OnEnable() и др.).
4. EVENTS (2) - участок кода, с обработкой событий, на которые подписан текущий класс.

___
#лр_хороший_код
👍2
Показывай в инспекторе не публичные поля

Почти
во всех видеоуроках (даже моих), курсах, туториалах и т.д. для настройки какого-то поля в инспекторе, в классе его помечают как public,

public Transform myPivot;

У этого подхода есть явный минус: он слабо выдерживает проверку на инкапсуляцию (принцип прячь все, о чем не должны знать другие).
Возьмем для примера код выше. Он подразумевает, что я из другого класса могу поменять пивот при помощи примерно такого кода:

someClass.myPivot = newPivot;

Для начинающих разработчиков такой подход - очень частое явление. Скорее всего, после такого изменения что-то сломается. Поэтому необходимо спрятать переменную, но при этом оставить возможность положить ссылку в редакторе. Объявление становится таким:

[SerializeField] private Transform myPivot;

Доступ извне закрыт. Все хорошо.
Если доступ извне нужен на чтение, рекомендуется дополнительно использовать свойство, немного изменив название приватной переменной:

[SerializeField] private Transform m_myPivot;

public Transform myPivot => this.m_myPivot;

В таком случае, нежелательное изменение исключено, а доступ на чтение есть.

___
#лр_хороший_код
👍2
Почему я использую this, когда это совсем не обязательно

Вот уже несколько месяцев я пишу ключевое слово this перед переменными и методами класса. Важно отметить, что this можно писать только указывая на объекты текущего класса, и которые инициализированы при сборке, а не созданы во время выполнения методов (см. пример 1 ниже).

С одной стороны, каждый раз вписывать this - это лишнее время, доли секунды, но тем не менее. Однако, это даёт следующие плюсы:

1. Удобочитаемость. Когда я вижу ключевое слово this, я понимаю, что переменная или метод объявлены при сборке, в случае переменных - в начале класса. То есть, я знаю, где искать начало, и что где-то задано их значение по умолчанию. Я об этом не задумываюсь. Особенно, когда смотрю на код спустя пару месяцев.
2. Возможность не тратить силы на придумывание и написание имен для параметров публичных методов (см. пример 2 ниже). При отсутствии ключевого слова this, придётся называть переменную в параметрах метода как-то отлично от локальной переменной. От этого может пострадать понятность кода, что самое главное.

Не бойтесь тратить на this время. При должном количестве практики, вы привыкнете к этому слову и не будете замечать его написание. И будете рады, что пользуетесь им, взглянув на свой код спустя несколько месяцев.

___
#лр_хороший_код
👍4👎2
Примеры 1 и 2 для предыдущего поста (не влезли)
Пользуйся словарями (Dictionary) - это удобно

Новички часто сторонятся использовать Dictionary. Это происходит по разным причинам, но в основном из-за того, что не до конца понимают его работу.

Если не погружаться в тонкости, то Dictionary - это таблица с двумя столбцами: ключ и значение.
- Одна строка этой таблицы - это один элемент (ключ + значение).
- И ключ и значение могут быть любыми типами данных.
- Нельзя вставить в один Dictionary два одинаковых ключа - выпадет исключение.
- Можно вставлять одинаковые значения с разными ключами.

Dictionary удобно использовать при хранении квестов, продуктов, скинов, инвентаря и других перечисляемых массивов.

P.S. В название переменной типа Dictionary в конце я всегда приписываю ~Map, так при подсказках IDE моментально становится понятно, какой это тип данных и при, начиная набирать map, интеллектуальный набор будет давать подсказки в виде уже существующих Dictionary. Просто и удобно!

___
#лр_хороший_код
👍1
Короче методы - понятнее код

Эта тема уже достаточно изжевана в книгах, однако, не все читают книги, поэтому вкратце расскажу.
Важно помнить, что наравне с тем, что у каждого класса должна быть одна ответственность, каждый метод также должен выполнять одно действие. Правда, не стоит пускаться в разнос и писать методы в одну строчку.

Есть правило: метод должен быть таким размером, чтобы он умещался на одном экране по высоте. То есть программист должен видеть на экране метод целиком, без прокручивания вниз или вверх.

___
#лр_хороший_код
👍1
Для качественной видеозаписи геймплея игры используй нативный Unity Recorder.
Устанавливается через Package Manager. Работает как часы!

___
#лр_советы
Недавно меня бесил момент, что у меня нет нормальной системы наград, которая могла бы кочевать из проекта в проект, была бы очень гибкой и удобной, чтобы я мог в качестве награды использовать вообще любую сущность.

Done!
https://github.com/vavilichev/RewardsSystem
___
#vavilichevgd #gamedev #Unity
1
This media is not supported in your browser
VIEW IN TELEGRAM
Залетаю в шейдеры с двух ног (нет). Написал простенький шейдер для эффекта блюра в пространстве UI. Mobile friendly, все дела.

https://github.com/vavilichev/MyUnityShaders/tree/main/Assets/VavilichevGD/Shaders/MaskedUIBlur
___
#лр_шейдеры
This media is not supported in your browser
VIEW IN TELEGRAM
Запилил ассет с процедурными анимациями объектов в UI. Для сбора монеток, сундуков - да чего угодно, что появляется в случайной точке и улетает в другую точку на экране, независимо от разрешения экрана.
https://github.com/vavilichev/UnityUserful/tree/main/Assets/VavilichevGD/FX/UI
___
#лр_ассеты