Приветствую тебя, путник!

Добро пожаловать в GameLab Notebook — место, где я делюсь своими исследованиями и практическим опытом в области разработки игр, программирования и архитектурных задач. Здесь вы найдете мои мысли по различным аспектам разработки, интересные находки, а также мемы и любопытные материалы, связанные с миром игровой индустрии.

Почему notebook? Потому что это скорее полевая записная книжка разработчика, где я делюсь своими находками и размышлениями: от дополнений к официальной документации движка/библиотеки/ассета и прочего до понравившихся мемов. В общем, буду сюда собирать всё что посчитаю ценными и делиться этим с вами.

Т.к. я работаю с движком Unity, большинство заметок будет именно про него и C#, хотя мы также будем рассматривать и другие технологии, которые могут быть полезны и интересны для наших читателей.

Если тебе интересно читать об играх глазами программиста, наблюдать за тем, как идёт процесс разработки, узнавать вместе с автором канала что-то новое и иметь возможность это обсудить в комментариях – добро пожаловать в мою небольшую лабораторию! Не забудь подписаться, чтобы не пропустить новые заметки 😉

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

#Практика

Когда разрабатываешь проект под WebGL в URP и у тебя подёргивается камера, а в коде всё хорошо - обрати внимание на настройки Color Space в Project Settings. Возможно проблема в том что там стоит Linear из-за чего камера не успевает отрисовывать из-за этой ошибки.

#Практика

Если нужно отключить Emission у материала, например у лампочки фонаря, при этом не отрубая emission у всех объектов с этим материалом необходимо:
Взять Render лампочки, у него взять материал/материалы и отключить у взятого материала с помощью следующего кода
lightMaterial.DisableKeyword("_EMISSION");
А для того что бы включить обратно
lightMaterial.EnableKeyword("_EMISSION");

Как модель то попердолило...

#Теория

Принципы ООП:

Абстракция — отделение концепции от ее экземпляра;
Полиморфизм — реализация задач одной и той же идеи разными способами;
Наследование — способность объекта или класса базироваться на другом объекте или классе. Это главный механизм для повторного использования кода. Наследственное отношение классов четко определяет их иерархию;
Инкапсуляция — размещение одного объекта или класса внутри другого для разграничения доступа к ним.

Как оно на практике в геймдеве:
Абстракция
Хорошо реализуется через 2 инструмента: абстрактный класс и интерфейсы.
В обоих случаях можно создать абстрактную логику без частной реализации и создать на этом взаимосвязь скриптов.
Например, наносим урон через метод TakeDamage(), который наследуется интерфейсом IDamageble. И, как пример, по коллизии проверяем есть ли на объекте IDamageble и если есть то вызываем метод TakeDamage(). Сама же реализация метода может быть индивидуальна и как следствие логика взаимосвязи является абстрактной.

Полиморфизм
Возможность вызывать одноимённый метод, но с разными вводными данными и как следствие разной реализацией.
Например, возьмём метод TakeDamage(int damage), где damage - кол-во урона. При вызове этого метода проходит уменьшение здоровье на значение damage. С помощью полиморфизма мы можем в этом же классе/интерфейсе создать метод TakeDamage(int damage, float speed) и при вызове TakeDamage(10, 1.2f) уже будет вызываться другая форма метода (не TakeDamage(int damage), а TakeDamage(int damage, float speed)) где помимо урона по здоровью будет ещё и урон по скорости.

Наследование
Позволяет написать метод в родительском классе и переиспользовать его без изменений или с небольшими изменениями (если это виртуальный класс).
Например, мы создаём класс Alive, в котором реализуем методы TakeDamage(int damage) и Healing(int health) с приписанием тела метода. Потом наследует от Alive класс Enemy. И при столкновении снаряда с объектом на котором висит класс Enemy мы можем вызвать метод TakeDamage(int damage) с уже имеющейся логикой.
Это позволит менять в одном месте логику нанесения урона, либо исцеления, изменяя её во всех дочерних классах разом. Таким образом не придётся скакать по классам внося изменения в каждым метод.

Инкапсуляция
Позволяет обезопасить методы или классы от вмешательства из вне. Например, что бы ваш коллега не мог нарушить архитектуру вызова метода Regenerate() из стороннего класса запустив его повторно и как следствие усилить регенерация в два раза.
Пример: Метода Regenerate() запускает корутину, которая каждые N времени восстанавливает здоровье на X единиц. Мы можем прописать логику в родительском классе и дописать к этому методу ключевое слово protected, указывающее на то что метод могу вызывать наследуемые классы, но при этом не может быть вызван из сторонних классов.

Легенда хэштегов

#Теория - теоретическая база разного уровня.

#Практика - мой личный или чужой опыт разработки, применения теоретических знаний или просто наблюдения сделанные на практике.

#Идеи - мысли в слух, размышления по любому поводу.

#Обзор - обзор на игру\фильм\книгу\статью. По сути моё мнение о том или ином произведении\труде\проекте.

#BadPractice - примеры плохой практики. Того как делать не стоит.

#Инструменты - описание любых инструментов для разработки. Не является рекламой

Легенда будет дополнятся по мере появления новых хэштегов

#Идеи

Планирую в ближайшее время, пока не надоест или пока не получу полное удовлетворение, экспериментировать с данным каналом во всех смыслах. Начиная от система организации знаний (добавил Легенду хэштегов для облегчения поиска материалов), до разбавление информационного потока об программировании и разработки игр в целом различным флудом (типо этого сообщения). Так же буду периодически изменять слог письма от около научного и официального, до повседневного и неформального.
Если у вас есть какие-то пожелания или мысли по улучшения канала - пишите в комментарии к этому (а можно и не только этому 😉) посту.

#Теория

Паттерны проектирования

Что такое паттерны?
Повторяемая архитектурная конструкция в сфере проектирования программного обеспечения, предлагающая решение проблемы проектирования в рамках некоторого часто возникающего контекста.
Простым языком: способ решения часто повторяемых задач при разработке.

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