Ахахах) Видимо перед постами надо всё же пить чашку кофе XD Так красиво написал. А ссылку забыл :) Вот конечно же сниппет :) https://pastebin.com/FiU3KcUV

Ставьте 👍 если подобные сниппеты полезны :) Чтобы понимать нужно ли делать такую рубрику :)

Rider Flow https://www.jetbrains.com/riderflow/

Просто шикарный плагин для Unity от JetBrains, как и многое от джетбрейнс :) В этом обзоре можно посмотреть на его фичи :) https://youtu.be/iUIjiKtILUc

Я же могу сказать, что я пробовал много IDE, и это всегда холиварная тема для программистов :) Кто-то любит вижак, кто-то вижуал студию код, кто-то до сих пор не смог выйти из Vim :) Я же уже 4 года как пересел на райдер с вижуал студии и он просто прекрасен. Но дело даже не в райдере, прекрасен не он, прекрасен решарпер. Основной причиной перехода 4 года назад стало то, что решарпер в вижуал студии дико тормозил, а в райдере просто летал :) Поэтому новая штука от брейнсов — это всегда круто :)

Прикольный туториал по ретро эффекту. Не уверен конечно в подходе к пикселизации картинки, хотя можно все артефакты на стиль, и основной плюс этого метода, что рендерить такого размера кадр сможет любой калькулятор https://www.youtube.com/watch?v=3Ccu3UtiSdw

Я когда-то игрался с подобными трюками, но для другого. С рендером в отдельное RT. Для блума. Но это же классический скринспейс эффект скажете вы) И будете правы, даже в постпроцессинге есть, а так же куча его вариаций на просторах интернета. Базируется он всегда на блюре. Только вот он достаточно прожорлив на производительность. А задача была завести сай-фай сцену на телефоне за 7к рублей :) Ну а какой сайфай без блума? Самый быстрый придуманный трюк прост в своей гениальности. Все светящиеся объекты рендерились отдельной камерой с разрешением в 3 раза ниже оригинальной) Получался достаточный эффект для разрешения телефона за 7к рублей, и всё летало :) Собственно так же в RT с альфа каналом рендерился кадр со светящимися объектами, а сортировка не ломалась, так как в шейдерах информация о Z не отбрасывалась :)

Паттерн Наблюдатель

Я долго думал, какой пример сделать для этого паттерна. Применяется он повсеместно. Неважно знаете вы об этом или нет) Потому что, как только вы пишете что-то вроде public event Action вы автоматически делаете наблюдателя) Поэтому любой пример с явным определением интерфейса IObserver и IObservable как указано тут https://metanit.com/sharp/patterns/3.2.php мне казался высосанным из пальца :)

Самым ярким представителем использования паттерна наблюдатель являются ReactiveProperty из https://github.com/neuecc/UniRx В целом реактивная парадигма, даже в том же React.js во многом построена на идее того, что наблюдатель едет через наблюдателя. Всё на событиях, все друг друга оповещают, причём часто без прямых зависимостей)

В общем в юнити наблюдатель, как паттерн используется плюс минус постоянно. Вам нужно при обновлении счёта, обновлять UI панельку, делать отлетающий текст + записывать что-то в аналитику — вы делаете наблюдателя. Вам нужно при ударе наносить урон, списывать сустейн с оружия, а также писать в журнал событий что игрок за время в игре нанёс 100500 урона — вы делаете наблюдателя:)

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

Прошлые разборы паттернов:
1. Команда — https://news.1rj.ru/str/dyadichenkoga/76
2. Декоратор — https://news.1rj.ru/str/dyadichenkoga/82

Тесты производительности

https://www.youtube.com/watch?v=d3kHuY99BW0 прикольный ролик, циферки это всегда классно и такие вещи смотреть любопытно. Автор молодец, что проделал такую работу, но этому тесту строго говоря — нельзя верить) Так как там столько нюансов на самом деле. Бенчмаркинг — это очень сложно) Можно посмотреть ролики Акиньшина на эту тему :)

Просто всегда показывая такие тесты производительности, помимо скриптинг бекенда нужно указывать платформу и железо, и число запусков. При этом указывать ещё максимальное, минимальное и среднее :) Потому что какие существуют нюансы :)

1. Во что компилируется код под платформу

Это прям далеко не всегда одно и тоже под разные платформы. Помню когда я ещё ходил по собесам мне несколько раз задавали вопрос про разницу между a + b + c и string.Concat(a, b, c) где abc это строки. Я надеюсь, что в современном юнити под все платформы разницы нет. Типа если коротко, тезис был в том, что явное задание конката лучше, так как конкат аллоцирует "abc", а суммирование "ab" и "abc". Я удивился, что компилятор умеющий разворачивать foreach в for не умеет обрабатывать такой случай. Пришёл домой, скомпилил, посмотрел ил. И увидел кое-что ещё круче. Что конкат вообще зло, так как + это синтаксический сахар, и иногда он оптимизурется в string.Intern (хотя я думаю про интернирование строк многие даже не в курсе) И у всего этого был один нюанс — под десктопом. Потом мы как-то сидели и болтали с кем-то из Unity, и он предложил скомпилировать под IOS) И там в IL результате внезапно была разница :) Хотя в целом компилятор шарпа умный, и сейчас ещё больше сахара напишет оптимальнее вас

2. Нюансы работы процессора

Разные процессоры под разными платформами в зависимости от поколения работают по разному. Вы скажете и что? Да дело в том, что ваш тест может быть написан так, что вам "неповезло" и вы получили скажем кешлайнсплит на каком-нить тайгер лейке, поэтому операция работает медленнее. А на m1 его не будет, так как там банально другой размер и организация кеша процессора :) Поэтому бывают иногда странные пики, которые потом возводят в ранг теории заговора, что "вот автопроперти в 30 раз медленнее, чем филды" :) И это довольно трудно учитывать

3. Нюансы окружения

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

Автор в любом случае молодец, что проделал такую работу. И допустим факт про кеширование Camera.main в 2019.3 я думаю многие не знают. Проблема правда, когда такую инфу начинают на собеседованиях использовать не до конца разобравшись в вопросе :) Но я скажу так. Такую информацию можно слушать "по-приколу", иметь ввиду, но не "мы переписываем весь проект, ваш код говно, ты что дурак не кешировать?" :)

Базовое правило — не тормозит, не трогай. И писать лучше в стиле, где меньше лишнего кода. От того, что вы выиграете 100 нано секунд — ничего не изменится в программе. Оптимизировать нужно только тогда, когда тормозит. И только с профайлером. Есть некое базовое правило, так как вы не управляете сборкой мусора — не сорить в память, так как это непредсказуемые тормоза. А остальное тормоза по большей части предсказуемые :)

Оптимизация игр для мобильных браузеров

https://zen.yandex.ru/media/id/6228b6ba8fdf75139f835258/optimizaciia-igry-na-unity-dlia-mobilnyh-brauzerov-62400d2eddce146b7a2fbc2b

Классная статья про то, как уменьшить вес игры. Многие советы тут применимы не только для мобильных браузеров, но и в целом, как базовые принципы оптимизации веса. Да и в целом много интересных советов касающихся WebGL и Unity)

Я бы общий список советов дополнил бы фразой, что "в целом UI лучше делать на нативном вебе". Просто потому что в юнити не работают инпутфилды нормально на мобилках в вебе, и много что ещё :)

Очень красивый торнадо на Unity :)

https://vimeo.com/404298626

Хоть я и работаю с Unity, как же можно пропустить новость о том, что Unreal Engine 5 вышел :) И он очень крут :) https://youtu.be/7ZLibi6s_ew

Конечно Unity слишком родной, и я его не брошу + мне в работе мало толку от «графена» Я больше работаю с мобильным AR, стилизацией и 2дшкой последнее время в плане продюсируемых проектов :) Иногда с графикой, но стремление к фотореализму как таковому там нет :)

Но, люмен и наниты — это кайф. Для другого спектра задач и другого пайплайна я бы может даже задумался :) Конечно у юнити тоже есть шейдеры и неплохие ролики, но с этой магией, на мой вкус, это не сравниться :) Вопрос не в том, что и там и там можно добиться одинакового визуального результата :) Можно) И кто говорит, что на анриале лучше графика просто не разбирается в компьютерной графике, и том как она работает в принципе :) Вопрос где красота достигается быстрее и проще :) И вот теперь есть ощущение, что на UE5 фотореализм достигается в разы быстрее :)

Я конечно за гонку вооружений, и пусть вероятно юнити нагонят) А для разрабов это просто означает новые крутые технологии, что всегда классно :) Главное, чтобы в этой гонке юнитеки не растеряли свои крутые инструменты для работы с 2д и многое другое, чего нет в анриале, сместив фокус на гонку графена :) Ну поживём — увидим :)

Комменты и код

Тут я скажу крамольную вещь. Комменты не нужны и быть их почти не должно в коде в принципе. Но тут есть нюансы)

1. Комментировать блоки кода чтобы использовать потом

Это то, что не должно попадать в гит. В рамках одной задачи, пока вы копаетесь, так делать можно, нужно и удобно. Так как зачем морочиться с целыми коммитами, чтобы откатывать мелочи. Но гит и возможность логировать файлы в нём позволяют не "разводить грязь" в коде. Так как художественного смысла в огромных закоментированных блоках кода — нет. Во времена, когда мы можем посмотреть полный лог по файлу и любую его версию

2. Комментировать каждый метод, вызов, строчку

Если у вас нет автогенерации документации — они вам тоже не нужны. Иногда ещё я скажу бывает "валидной магией, которую тяжело поддерживать" комменты для кодогенерации, которые по сути являются сервисными. Но я никогда не пойму зачем нужно комментить методы вроде GenerateMap(int width, int height) //генерирует игровую карту. width — ширина, height — высота. Возможно я чего-то не понимаю и в этом есть сакральный смысл, но вроде в названии метода и переменных написано ровно тоже самое. Поэтому это просто лишние строки текста в файле с кодом, которые нужны ни за чем)

Что же нужно комментить?

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

1. Алгоритмы

Их нужно комментить без кавычек, так как они бывают сложными и неочевидными. Но правда лучше не писать простыню текста в коде, а писать source link откуда алгоритм взят)

2. Контракты

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

3. Неочевидное поведение

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

4. TODO

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


И на этом всё. Весь остальной код должен быть понятен без комментариев. Если у вас такая сложная зависимость, фабрика через фабрику фабричным методом погоняя. И вам нужны комментарии, да и даже документация чтобы это объяснить. Вероятно вы делаете что-то не так. Для любого мидл+ специалиста лучшая документация — это код, который должен быть понятен без комментариев, что у нас класс на 150 строк, превращается в 250, так как там ещё 100 строк комментов) Хотя как инструмент для сервисных целей комменты штука удобная конечно :)

Некоторые эффекты на Unity конечно для меня выглядят как чистая магия. При этом они сложные в основном не технически, а творчески :) Ну чтож, надо же нарабатывать насмотренность :) https://realtimevfx.com/t/thomas-denis-sketch-18-hologram/6507

Прикольный и довольно простой в своей сути эффект :) Френель, эмиссия на границах пересечения, вращающаяся текстура, да партиклы :) Но выглядит прям хорошо :) https://mobile.twitter.com/bbbn192/status/1464302229536620547?s=12

Работая с графикой, даже если вы занимаетесь чисто разработкой, хорошо иметь насмотренность в контенте. Нет, не для того, чтобы советовать что-то дизайнерам :) А чтобы придумывать себе упражнения и думать «хммм, а как это сделать» или «а как это сделать быстро?» :) Поэтому даже если вы разработчик, советую смотреть так же в сторону контента и очень много изучать в целом, это выводит на совершенно другой уровень :) Собственно прикольный дайджест статей по анимациям в интерфесах :)

https://medium.muz.li/20-really-useful-ui-animation-tutorials-every-designer-should-know-c302085245d6

Бизнесу не нужен идеальный код

Но и плохой тоже не нужен :) Я всегда считал, что люди работающие в компании должны понимать мышление бизнеса и пытаться в нём разобраться. Просто потому что так проще воспринимать любые задачи и требования, и приходить к единому пониманию вопроса)

Неважно инди это, небольшая студия и корпорация. Делается это системно, по наитию, всё само собой получается. У вас всегда будут выстраиваться процессы. Что такое процесс? По сути легко повторяемый набор действий. Самое простая аналогия — метагейм в игре, когда есть некий общий скелет, от которого идут частности. От заказа документов до процессов разработки и производства)

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

А что же нужно бизнесу? Воспроизводимый процесс и предсказуемость. Самое лучшее, что может иметь бизнес в качестве некоего продакшена — это предсказуемый продакшен. Его можно забюджетировать, заложить риски, прикинуть сроки и т.п. Что важно при разработке вообще любого продукта. И в эту схему никак не ложится "идеал", так как в любой фигне можно сказать, что нет предела совершенству :)

Но главный вопрос даже не в этом. Если очень хочется что-то сделать, и это касается и оптимизации, и рефакторинга и т.п. "Что это даст?" В некоторых студиях допустим запрет на рефакторинг (так как нет системы автотестирования в первую очередь), и это я считаю не совсем верным. Если кодовую базу периодически в критических местах не рефакторить и не обновлять, она рано или поздно начнёт сыпаться) Правильно на мой взгляд, договариваться с бизнесом на рефакторинг, но при этом приходить с ответами на два вопроса: "Что это даст?" и "Какие риски?". И в этом случае, когда особенно это говорится понятными категориями (деньги, сроки и т.п.) — это можно обсуждать. Главное бизнесу объяснить по сути — "зачем нам нужно тут улучшать код, если сейчас он работает" :)

Эргономика VR/AR интерфейсов

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

AR/VR в тренажёрах, в подсказках при переборе двигателя автомобиля, для визуальной навигации — кайф. Но подобные вещи как гуй в воздухе конечно красивые, но абсолютно бессмысленные :) Поэтому в AR важен контекст применимости того или иного интерфейса взаимодействия :) И с VR во многом тоже :) И да, контроллер может быть в огромном количестве задач в разы удобнее рук :)

Когда-нибудь я правда составлю список литературы :) Но в целом всем разработчикам работающим с графикой и т.п. очень рекомендую эту книжку Real-Time Rendering, Fourth Edition, by Tomas Akenine-Möller, Eric Haines, Naty Hoffman, Angelo Pesce, Michał Iwanicki, and Sébastien Hillaire. Если её прочесть от начала и до конца даже по диагонали (так как сейчас многое из материала движки делают за вас) она даёт отличное понимание, как работает рендер в целом :) Что весьма полезное знание хоть в 2д, хоть в 3д :)

Сложность программирования

На мой взгляд многие переоценивают сложность программирования. Особенно «обычного программирования». В обычном программировании нет вообще ничего сложного, там нет супер математики или чего-то ещё. Большая часть энтерпрайс работы называется «возьми библиотеку и встрой» :) Такова реальность, и я ничего не имею против) В свои-то 28 чего мне кряхтеть: «Вот раньше мы писали ассемблерные вставки, пирамидальную сортировку руками. Да вы вообще Кнута хоть нюхали, юнцы. Ты хоть квиксорт без гугла то написать сможешь?» Нет, инструменты совершенствуются и это прекрасно. Но я именно что важно отметил «в обычной разработке»

Когда же ты работаешь в инновациях, высокотехнологичных проектах и т.п. Ты в аду) И такое бывает и в играх) Я уже не знаю, сколько я прочитал подобных работ (эта кстати довольно любопытная) https://liris.cnrs.fr/Documents/Liris-2422.pdf Но вот там зубодробительная математика, нужно уметь читать научные тексты, исследования, понимать низкий уровень и т.п. Подобные задачи неплохо прокачивают, но их конечно в разработке процентов 2-3 :) Так что не стоит переживать и думать, что программировать сложно. На 98% это относительно простая дициплина и скилл :) Не элементарный конечно, но всё познаётся в сравнении :)

А в целом к сегодняшней книге есть замечательный "список литературы на лето" чтобы знать прям очень много про графику) Не скажу что там маст хэв знания для Unity разработчиков, но в целом на досуге фоном можно почитывать :) Так как когда понимаешь на какие технологии и математику опираешься, проще оценивать что возможно, а что нет :) https://github.com/Gforcex/GPU-Book

Паттерн Прокси https://metanit.com/sharp/patterns/4.5.php

Ну для полноты картины нужно разобрать все паттерны, так что возьмём и прокси. Прокси — тот паттерн, который довольно редко используется в игровой разработке. И тут можно поговорить о том, чем геймдев и юнити отличается от энтерпрайса. Геймдев похож на энтерпрайс в очень крупных проектах, у которых есть бекенд) Потому что на клиентском коде сложно представить задачу, которую разумно решать проксёй) Потому что прокся по своей сути требует определённого подхода к проектированию

Сама прокся по похожа на декоратор, но выполняют они совершенно разные цели. Прокси бывают нескольких видов, но в целом в большинстве случаев используются для расширения функционала (или доступа) к реальному объекту. Главное отличие между прокси и декоратором, что декоратор нужен для динамического расширения функциональности.

В обычном случае прокся может расширять функциональность объекта, добавив скажем кеширование:

Например представим, что вы в проекте используете sqlite и храните там игровые предметы. Обращение в БД это всегда дорого и за это должен отвечать класс SQLiteConnector или типа того, а выше мы можем сделать SQLProxy, которая уже когда-либо запрошенные из бд объекты будет сохранять в словарь Dictionary<long, GameItemBase> где у нас ключов выступает id предмета, а значением базовый предмет. И когда запросы летят в проксю, мы сначала спросим наш словарь, чтобы не лезть в базу

Но ещё есть 3 специальных случая, о которых также стоит сказать:

Удалённый прокси (remote proxy) — везде описан очень плохо. По сути как раз то самое кеширование, так как какую проблему он решает. У нас есть сервер, запрашивать у него данные долго и дорого, поэтому лучше это делать один раз на инициализации объекта. По сути прокси позволяет архитектурно не создавать объекты и делать чеки, а обращаться к прокси объекту, а он у же сам дальше будет не на сервер ходить, а брать копию объекта в памяти

Виртуальный прокси (virtual proxies) — описания много где тоже довольно странные. Частый кейс использования это ленивая инициализация реального объекта. Представим немного виртуальный пример. Фильтр мата для игрового чата. Есть высокочастотные слова, которые мы просто хардкодим. Кешировать все матные корни и слова ни к чему и дорого, поэтому если у нас в список "быстрого набора" скажем слово "бля", то он не идёт в базу, а берёт сразу из памяти. В остальных случаях делает чек по БД. По сути "умной проксёй" называется то, что делает какую-то полезную работу и достаточно сложную. Многопоточность и подсчёт ссылок на метаните — это тоже частный кейс

Защищающий прокси (protection proxies) — самый простой пример, используется для разграничения доступа пользователей. В клиентской разработке применимо, в играх меньше, так как там редко бывают "роли" в смысле доступа к функциям. Но как пример — премиум аккаунты и их чеки. В базовом случае прокси объект ссылается на один реальный объект, но в целом нет никакой проблемы расширить его на пару объектов, и смотря в прокси роль пользователя вызывать уже внутри прокси либо создание "премиум" интерфейса, либо обычного. По сути позволяет в коде избавиться от кучи "if(user.role == "premium")" — довольно удобная штука, позволяющая программу в целом делать простой, если в игре есть какая-нить премиум подписка. Так как разделение зашито в проксю, а поведение в реальные объекты

Важно понимать! Это разделение не является строгим и все его трактуют по своему, так как оно условно "народное, а не формальное". Но в целом зато позволяет привести несколько интересных примеров использования прокси

Прошлые разборы паттернов:
1. Команда — https://news.1rj.ru/str/dyadichenkoga/76
2. Декоратор — https://news.1rj.ru/str/dyadichenkoga/82
3. Наблюдатель — https://news.1rj.ru/str/dyadichenkoga/105

Если вы не знаете, кто такой Keijiro Takahashi, то советую узнать и подписаться на его гитхаб. Он часто выкладывает что-то крутое и за ним очень интересно следить. Вот и свежий репозиторий с процедурными градиентами)

https://github.com/keijiro/CosineGradient