Люблю встречать что-то эдакое в коде, обычно не свойственное для С#. Указатели как раз такой зверь, который встречается не часто. Их применение на мой взгляд не оправдано, потому что можно обойтись без них. Что характерно для их использования? Они работают в блоках unsafe кода. Это такие участки кода, где среда CLR не может отследить использование памяти и собрать мусор. Эта задача ложится на программиста. Потенциально опасное место для утечек и ошибок, особенно когда код пишется руками разных программистов.

Что можно сделать с помощью указателей? Например, грубо выражаясь, можно заставить value-объект вести себя как ссылочный.

int* pointer;
int anyValue = 100;
point = &pointer; // теперь указатель pointer ссылается на ту же область памяти, где записано значение anyValue
anyValue += 100;
Debug.Log($”{*pointer}”); // 200
*pointer = 500;
Debug.Log($”{anyValue}”); // 500

Ещё с помощью указателей можно получить адрес памяти, куда ссылается указатель, но это очень специфично. И конечно можно ссылать один указатель на другой, но здесь я ещё больше радуюсь данной возможности, но совсем не могу придумать применение в нашей сфере.

На самом деле мы работаем с указателями в шарпах чаще всего другими способами:
- Когда создаём объект через операцию new, которая возвращает указатель на объект после выделения памяти и вызова всех конструкторов
- Когда используем оператор as, среда проверяет совместимость типов и возвращает либо указатель, либо null. Warrior unit = wizard as Warrior;
- Когда пишем ключевое слово this мы обращаемся к указателю
- При упаковке значимых типов, они записываются в кучу и получают свою ссылку, то есть указатель
- При передачи параметров в методы мы можем использовать ключевые слова ref и out для значимых типов, где компилятор будет генерировать метаданные, описывающие параметр как передаваемый по ссылке
- Когда назначаем делегат - фактический назначаем указатель на функцию.
- Ну про ссылочные типы и говорить нечего…

Если у вас есть примеры из практики, где вы используете указатели в unsafe коде - поделитесь, интересно.
#техничка

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

Если у вас есть пара любимых мемов - киньте в коменты.

@cat_and_code #мем

Какую мысль можно вынести из скандала с Unity? На данный момент они начирикали в Твиттере X, что извиняются, но не понятно за что. Толи за весь сыр-бор, толи за то, что не смогли нормально "продать" свою новую систему сборов и вернутся к нам, когда подготовят презентацию получше.

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

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

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

Как действовать в таких условиях? Можно отнестись к этому, как к толчку, который мы давно ждали. Кому-то его не хватало, чтобы начать изучать Unreal и C++, Godot, серверный стек или что-то ещё. Не потому что корабль тонет и сейчас надо паниковать, а потому, что всегда стоит держать в голове, что рынок может поменяться, и нужно иметь план Б. Сейчас просто яркое напоминание об этом.

Какие-то технологии уходят, и на их место приходят новые. Можно вспомнить взлёт и падение популярности Xamarin. А также знания разных инструментов помогают подбирать эти инструменты под задачи, а не делать все одним и тем же молотком. Такие перемены всегда некомфортны, но для нас, как для специалистов, это возможность для развития.
#новость

На этом канале обсуждаем техническую сторону разработки игр, говорим про особенности Unity и C#, общаемся на профессиональные темы программистов, про личные проекты и гик-хобби автора.

Привет! Меня зовут Дмитрий Котиков, я:
- Разработчик игр и консультант
- Lead\Senior Unity Developer в Panoramik games
- Программист и технический продюсер в студии Rayonist
- Соведущий подкаста «Компьютер задавал стиль всей комнате»
- Основатель и бывший владелец школы рисования Sketch Park

А Горюшко вслед собакою… - наша игра в Steam, атмосферное и эмоциональное приключение о юной почтальонке

Основные теги:
#девлог@cat_and_code - про разные проекты, которыми занимаюсь
#техничка@cat_and_code - про программирование, код и Unity
#мем@cat_and_code - развивающаяся коллекция IT-мемов на разные ситуации
#игры@cat_and_code - мои небольшие обзоры про специфические игры в которые играю
#события@cat_and_code - про митапы, лекции и хакатоны, где я бываю

Буст канала:
https://t.me/boost/cat_and_code
Клон канала в MAX:
https://max.ru/join/bA-0X_SuYCG_MQiuAu4iqHm22Lw3TuvNVYc84LjbSbI

Я чаще всего играю, сидя на диване, а не за столом. Меня особенно расстраивает, когда игры не имеют поддержки геймпада. И поэтому в нашей собственной игре (GVS) не может быть такого недочёта. Наконец-то дошла очередь, и я переделал "старую" систему ввода Unity на "новую", и теперь мы можем позволить себе настраивать управление как захочется. Так что в релизе оно точно будет.

А также я добавил настройку для подстройки дрифта стиков, потому что второе, что меня расстраивает, если в игре все-таки есть поддержка геймпада — это отсутствие такой настройки.
#девлог

Студия Nival
Выпуск про легендарную студию, зародившуюся в далёкие 90ые. Поговорим про их путь, проекты и выдающихся выходцев, которые во многом помогли сформировать геймдев в России.

Ссылки выпуска:
Аллоды: Печать тайны
Сайт Нивала

Автор: @cat_and_code
#подкаст 1

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

Давайте поиграем в ответы на вопросы с собесов. Пишите свой ответ в комментариях.

Почему в профайлере памяти может быть такая картинка?

ComponentLurker

Классный инструмент для поиска по скрипту. Можно найти все префабы в проекте, где накинут выбранный скрипт. Дополнительно можно указать условие и найти префбы, где выбранное поле в скрипте имеет определённое значение. Например найти все префабы где ничего не прокинуто в интересующее поле.

https://github.com/vksokolov/ComponentLurker/

Паттерн "Команда"
Обсуждаем один из наиболее используемых паттернов программирования и разбираем примеры применения.

Автор: @cat_and_code
#подкаст 2

Новые посты пишут те, у кого старые плохие долго думал я. 🌚

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

Когда нам нужен класс с данными, который в логике приложения нужно сравнивать с другими. Сделан для того, чтобы экономить время и не заниматься переопределением кучи методов: операторы == и !=, GetHashCode, Equals, ToString и конструктор.

Как он работает? Компилятор сам создаёт переопределения для всех необходимых методов. Что по сути превращает record в новых вкусный сахар.

Создание record, способ №1:

public record Name(int Value, string Str);
var n1 = new Name(1, “name1”);

В этом примере свойства под капотом создаются get. Но есть синтаксис, который все-таки позволяет менять значения после создания экземпляра.

n1 = n1 with { Value = 3 }; 

Что делает эта строчка? Создаётся новый экземпляр и записывается в n1, то есть запись выше равносильна такой:

n1 = new Name(3, n1.Str);

Способ №2, сразу с настройкой свойств как вам нужно. Тут уже без проблем можно присваивать новые значения через “=”.

public record Name(int Value, string Str)
{
  public int Value {get; set;} = Value;
}

var n2 = new Name(2, “name2”);
n2.Value = 3;

В обоих случаях компилятор за нас сгенерирует конструктор и создаст все перегрузки методов сравнения. Сразу можно пользоваться:

if (n1 == n2) 
   …

Повторюсь, что record - это сахар, разворачивается в class, поэтому есть поддержка всего, что мы любим:
- Наследование
- Могут быть abstract
- Могут быть sealed
- Поддерживают реализацию интерфейсов

#техничка
@cat_and_code

Чет прям в голос, жизненно))
@cat_and_code #мем

9го дня был на лекции от создателей игры Василиса и Баба Яга. Прям чего-то нового не услышал, но смог лично сказать девчонкам, что графика у них получается очень крутая. Трейлер в VK.

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

Игра на Steam

Как-то сталкивался с ситуацией, что некоторые даже сильно опытные разработчики не могли ответить на вопрос “Что такое .Net?”. Думаю дело тут в том, что многие привыкнув работать на уровне игр\приложений не задумываются на чем оно строится и за счёт чего работает. Пробежимся, краткая сводка, буквально на 30 секунд.

.Net - это платформа, которая позволяет писать, компилировать код и запускать приложения, написанные на C# и других языках. Содержит совокупность ресурсов отладки, набор программ для запуска приложений на разных платформах.

Раскроем:
- Поддержка языков программирования - C#, F#, Visual Basic, IL ассемблер
- Обширные библиотеки классов, основные из них можно перечислить: System, System.Collections, System.IO, System.Net, System.Linq, System.Threading. По этим неймспейсам вполне можно понять, что в них и что мы привыкли использовать как должное.
- Компилятор на базе Roslyn, это опенсорс платформа, разрабатываемая Microsoft, что в ней для нас важного: компиляторы и средства для анализа кода.
- Компилятор - переводит исходный код ЯП в промежуточный IL-код и наборы метаданных. Затем IL-код будет выполняться в CLR.
- Различные фичи наподобие проверки синтаксиса и предложения по исправлению кода реализуются как раз за счёт использования Roslyn.
- Основная ягодка .Net - это CLR (Common Language Runtime), неотъемлемая часть платформы, в неё входит:
- Загрузчик сборок
- Функционал обработки исключений
- Управление потоками
- Управление памятью
- Сборщик мусора
- Механизм контроля совместимости типов
- JIT-компилятор (Just-in-Time), который работает с IL кодом и переводит его в исполняемый машинный код.

#техничка
@cat_and_code

Мне на одном из рабочих проектов понадобилось сильно сократить размер билда под WebGL. Специфика задачи еще была в том, что параллельно из игры нужно было выпилить часть больших фичей, поэтому получились не очень валидные данные ДО и ПОСЛЕ, но даже без удаления фичей вполне можно добиться x0.5 от начального размера. У меня результат 133 Мб → 36 Мб.

Топ по эффективности:
- Компрессия текстур. У меня на проекте она почти отсутствовала, текстуры либо не были пожаты вообще, либо были размеры текстур не кратные 4м и компрессия снова не работала. Так что привести все к размерам и выставить сжатие (для WebGL мы ставим RGB(A) Compressed BC7)
- Если вы можете себе позволить - уменьшение размера текстур. Мы выбрали компромисс, такой что на FullHD мониторе смотрится нормально, а на 4K уже так себе.
- Пережать атласы, так чтобы в них не было пустого места. За пустое место в них тоже приходится платить мегабайтами.
- Удаление и стриппинг шейдеров. Зависит от проекта, но иногда даёт десятки мегабайт.
- Формат компрессии билда - Brotli. Само по себе дало профит примерно в 10% от размера билда в Gzip.
- Удаление лишних шрифтов. Сам шрифт и ассеты связанные с ними весят много. Это снова компромисс, так как такой приём влияет на дизайн. У нас их было 15, оставили 3, профит ~12 Мб .
- Пожатие звуков. Здесь просто шакалим звуки на сколько можно, определяя на слух что получилось.
- Стриппинг кода. Зависит от проекта - мне дало всего 1.5 Мб, на другом проекте давало десятки Мб. (ProjectSettings → Player → (Под конкретной платформой включить галку Strip Engine Code и Managed Stripping Level поставить в High)
- Чистка менеджера пакетов и ручная чистка файла manifest. В том числе от модулей Unity. Например, можно дропнуть физику или тайлмапы, если вы их не используете.

Ну и главное правило: смотреть билд репорт. Иногда бывают сюрпризы. Например, вы можете обнаружить что какие-то мусорные префабы тянут за собой массу ресурсов в сборку.

#техничка
@cat_and_code