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

Добро пожаловать в 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 - примеры плохой практики. Того как делать не стоит.

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

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

#Идеи

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

#Теория

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

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

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

Когда не оплачивают переработки, но менеджмент просрал сроки)

#Теория

Паттерн "Singleton"\"Одиночка"

Это порождающий паттерн, т.е. создающий экземпляр объекта.
Пример:
public class MyClass
{
public static MyClass Instance
{
get{return this;}
}
}

Используется для создания глобальной точки доступа к публичным методам\переменным класса. Этот паттерн гарантирует, что у класса будет только один экземпляр.

Для чего можно применять?
- Как подключение к базе данных. Т.е. вы из любой точки кода можете запросить данные из БД или отправить новые данные в БД.
- Точка доступа к настройкам. Т.е. получение данных от UI и возможность использовать эти данные в других классах, без прокидывания ссылок на эти классы.
- Логирование. Вместо создания нового логгера каждый раз, когда нужно что-то залогировать, мы записываем всё в один объект.
- Пул ссылок. Синглтон может быть неким хабом для хранения ссылок на объекты, к которым нужно получать доступ из других классов не создавая прямой зависимости. Например: в синглтоне хранится ссылка на Transform игрока и враги должны понимать где находится игрок, что бы добежать до него для атаки. Что бы не передавать каждый раз к новому объекту врага ссылку на Transform игрока, можно сразу прописать что бы враг брал трансформ через синглтон.

Минусы использования:
- Доступность. Это нарушение первого принципа SOLID - объект не инкапсулирован в классе, а является доступным из любой части кода
- Единственный экземпляр. Это нарушение третьего принципа SOLID - нет возможности использовать подтипы, ибо этот паттерн может быть только один.
- Отсутствие разделение интерфейсов. В синглтоне обычно не используются интерфейсы, ибо это единственный экземпляр с уникальной логикой. Это нарушение четвёртого принципа SOLID
- Зависимость на конкретики. Нарушение последнего принципа SOLID, говорего о необходимости создавать зависимости от абстракций.
- Препятствуют автоматическому тестированию - экземпляры не могут быть созданы заново для каждого тестового примера

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

#Обзор

Поиграл на днях в новую для себя игрулю...

Grounded – выживачь от Obsidian в сеттинге фильма «Дорогая, я уменьшил детей».

В нём вам предстоит играть за ребёнка, которого уменьшила некая корпорация. Вам предстоит выяснить каким образом вас уменьшили и как вернуться к нормальному размеру.

Всё происходит на заднем дворе дома учёного, о котором так же предстоит узнать из схода сюжета.
Во время исследования на вас то и дело будут нападать местные жители: муравьи, жуки, пауки да мушки. Живности достаточно что бы вы о ней не забывали. Очень хорошо поработали геймдизы – каждые 40 сек что-то происходит: либо вы натыкаетесь на новую постройку, либо вас пытается сожрать здоровый паук, что в 2 раза вас выше. Арахнофобам не советую в это играть, хоть там и есть настройки уменьшения ужасного вида пауков.

Как выживачь вполне не плох – необходимо постоянно следить за уровнем еды и воды, однако нет необходимости во сне или отслеживании температуры, болезней и прочего и ваша смерть от голода или жажды, как и любая другая просто перенесёт вас на бузе без каких-либо дебаффов, разве что придётся бежать к своему рюкзаку за оставленными вещами.
Возможно «лишнюю» реалистичность убрали, ибо игра больше направлена на детей, а им и в реальной жизни не всем удаётся адекватно за всем этим следить (кто у нас не носит шапку зимой? 😉 ).

Ночные прогулки по травяному лесу – это отдельный хоррор. Многие животинки выходят на ночную прогулку, а атмосфера заставлять следить за каждым кустом, особенно пока на вас нет топового шмота.

Вообще сам сеттинг мне понравился, вернул в детство, когда смотрел фильм, на котором основана идея игры, да и в то время сильно увлекался насекомыми. Но малый выбор персонажей, и никто из них не похож на моё альтер эго😊

Система строительства, крафта и развития основана на геноциде – уничтожай всех, кого видишь и получишь либо еду, либо вещи. Всё что ты используешь (не считая основы для строительства) – плоть других существ, с которыми ты встречаешься.

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

Ставлю ей 4 жопки красного муравья🐜 из 5 и то больше из-за ностальгических ощущений.