#Практика

Если нужно отключить 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 и то больше из-за ностальгических ощущений.

#Идеи

Как часто бывает что вы прорабатываете механики во сне?

Мне сегодня приснился анализ механики отступления в пошаговой средневековой стратегии)
Суть такая при выборе бегства из боя ваши пешие солдаты закидывают в телеги свою броню и оружие, что увеличивает их скорость\дальность перемещения по глобальной карте. Однако при этом при повторном нападении им нужно потратить очки хода на то что бы добежать до повозок и одеть амуницию. Без неё они с характеристиками "крестьян".
С одной стороны это прикольный реализм, но насколько это может сломать баланс?...

Каджит качает ближний бой

Побывал вчера на митапе Prototype vol. 1/23

Ниже опишу впечатления...

И так, митап Prototype...

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

Об организации

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

О лекциях

Были подняты темы о том, что сейчас с геймдевом в России, как найти издателя и инвестиции (на мой взгляд очень актуальная тема, особенно с учётом того, что на встрече в основном были инди и стартапы). Так же был отдельный за для инди разработчиков и зал дня киберспортсменов и около того. Я лично слушал лекции как в главном зале, так и в инди, ибо мне это близко.
Ведущие по итогу лекции выбирали лучший вопрос от зрителей и награждали их за активность. Увы на вопросы было выделено не так много времени и многие не смогли задать свой вопрос спикерам.
Те, кто не смог послушать лекции по тем или иным причинам, могут посмотреть запись трансляции (огромный плюс оргам!) - https://prototype.ru

О гостях

Было, на мой взгляд, около 500 человек. Разношёрстных, но в основном молодых. Большинство из тех, с кем познакомился были либо студентами, либо только-только начали работать по профессии в стартапе или в инди команде.
Но также были и люди с опытом и те, кто уже основал свой стартап или небольшую студию.
Народ очень быстро разбился по группам и общался внутри своей малой группы весь день. К вечеру мои силы на социальную активность кончились, и я начал замечать, что народ сам не идёт на контакт. Возможно, у остальных тоже закончились силы или же это побочка работы в IT…

Итог

Мероприятие понравилось. Получил новую инфу на лекциях и успел познакомиться с новыми людьми и встретить знакомых из индустрии.
Кто не был, советую посмотреть лекции и если будет повторение митапа, то сходить)