Лучшая работа в мире...

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

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

Но я попробую показать в чём проблема примера хорошего кода. И что ко всему легко докопаться в статье про инвентарь. Как по вашему, это интересная тема? Ставьте 🔥 если да :)

Поговорил про AR технологии
https://tproger.ru/articles/tehnologija-ar-kak-rabotaet-i-na-chjom-sozdat-proekt/

Тут не так давно вышла статья где я помогал с редактурой с технической стороны. Можно почитать про AR и всякое такое. Да и в целом получилась неплохая обзорная статья :)

Работает — не трогай?

И да, и как бы нет. Если проект не развивается, мёртв, никто его не тестирует и в целом "что-то работает и ладно". То лучше его не трогать. Один мой друг рассказывал смешную историю о том, как работа нескольких отделов встала, так как отдел разработки выключил VPN. Потому что никто не знал зачем он был нужен. Поэтому трогать такое бывает опасно. Да даже у меня бывало такое, когда я думаю что что-то работает (систему не трогали 3-4 месяца), отправляю клиенту, а потом узнаю что нет.

А вот если проект живой и меняется, то я работал в компаниях, где было правило "мы не занимаемся рефакторингом". И это путь к тому, что через 1-1.5 года разработка просто утонет в тех. долге. Потому что число багов будет превышать число задач. Подход "мы не рефакторим" я считаю провальным по чисто бизнес причинам, потому что в конце концов проект просто рассыпится и бизнес попадёт на большие деньги, нежели если разрешит выделять некоторые спринты на чистый рефакторинг :)

Почему стоит делать градиенты шейдерами?

Недавно вышел ролик про градиенты на шейдерграфе. Там конечно супер простой пример, но на мой взгляд там недостаточно раскрывается почему так стоит делать. Когда-то я писал целую статью про это. Но думаю стоит ещё раз упомянуть коротко и тезисно. Почему стоит делать градиенты шейдерами?

Они плохо компрессируются

Чаще всего алгоритмы сжатия типа того же ETC2 делают условно "лесенку" на градиентах. В целом посмотреть на разные артефакты можно в этой статье от nvidia по ASTC.

Они много весят

Опять таки текстура в хорошем разрешении для мобильной игры на телефоне с стандартным сжатием, чтобы весь градиент не пошёл лесенкой будет весить 1-2 мб. Шейдер же несколько килобайт и при этом даст идеальное качество.

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

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

Собственно в репозитории можно посмотреть реализацию. Там повтор всех фигмовских градиентов. Хотя не во всём удобный. https://github.com/Nox7atra/Unity-Figma-Gradients

Менее общее решение, но так же "валидное" с сохранением батчинга можно сделать через кастомный UI элемент. Это элементарно для того же линейного градиента. Дело в том, что шейдер используемый в UI для цвета использует информацию из Vertex Color (и то, что вы видите в компоненте Image, просто переписывает VertexColor меша. Поэтому можно через механизмы вроде Vertex Helper генерировать кастомный меш, написав в вершины нужные цвета, а дальше интерполяция всё решит за вас. И это будет вместе с батчингом и стоить +- ничего, ни по весу, ни по производительности, относительно классического подхода с UI.

Ассеты это хорошо, но не всегда

На самом деле я почти всегда считаю, что если что-то можно купить дешевле это купить. Это же касается ассетов. Зачем разрабатывать свой AVPro если он стоит всего 400$ или же какой-нить FinalIK за 100$, да даже пакеты графики, какие-то простые эквалайзеры. Но есть одно но :)

Даже в таких крупных ассетах как Spine всё не так удобно. Я сейчас делаю достаточно много веб проектов (под заказ и для себя) и там я прям упарываюсь в оптимизацию. Сегодня-завтра таки выкачу новую игру для вайтлейбла. Так вот. Физика весит 1мб кодовой базы, и спайн неизбежно тянет её. Там нет define который убирает зависимости на физику или на ещё что-то, если вдруг они билду не нужны. А не всем нужна 3д физика в 2д проекте (точнее почти никому). Но в вебе каждый мб важен, так как иначе и получается, что проект грузит долго. Ту игру, которую я ща делаю, получилось запихать в 5 мб веса. Хотя мне кажется, что если подумать, то можно уместить в 4. Правда чтобы вырезать 1мб физики нужно было полезть в пакет спайна и удалить все зависимости на 3д физику.

А в некоторых случаях даже не захочется так лезть, так как вот нужно будет обновить ассет или пакет? И это поддерживать снова вырезанные куски. Так что ассеты не всегда в действительности так экономят время и удобны, но всё же чаще проще купить ассет. Особенно для прототипирования :)

Самый полезный из всех докладов Unite 2022
https://www.youtube.com/watch?v=rkstfoeZprM

Честно говоря я даже немного разочарован Unite 2022. Скучно. Для разработчиков. Видео про "модульный воркфлоу" — вообще ни о чём. Мысли верные, только ничё непонятно и ничё особо интересного в нём нет. Lightning Environments про HDRP, и не знаю как вы, а я им почти не пользуюсь. Шоукейсы, как всегда красивые. Кейноут — вообще ничё нового. Много рекламы своих сервисов. Но доклад про советы по работе с вокфлоу я считаю полезным. Простой, обзорный по разным фичам Unity, много полезных советов которые вы могли пропустить.

И новый вид доклада. "Посмотрите какие мы молодцы" вообще без объяснений. Для того, чтобы посмотреть "что возможно" может полезно. Но я помню времена, когда доклады на Unite были такими.

P.S. Ничего не имею против художников, просто хочется немного больше информации для технарей :)

Даже стало интересно, как работают донаты в телеге

На самом деле забавно. Штука добровольная и абсолютно необязательная, но если кто вдруг захочет поддержать канал — мне будет приятно. Но хочется сказать о другом. Функции для редактирования публикации и в целом по тому, как оно подключается выглядят конечно своеобразно. Особенно часть с "отправьте ключевое слово". Я перед публикацией прям боялся "что же будет, а вдруг я туплю" с каналом на почти 1к человек. В целом контент всё равно остаётся бесплатным, я не буду вводить платные функции, подписки, посты за деньги, так как не для того я канал создавал. Но кто-то захочет поддержать канал, это конечно же приветствуется и теперь есть такая возможность :) Я стараюсь делать качественный контент по сложным темам, вы угощаете меня кофе. По-моему вполне хорошая сделка. Не хотите, нет возможности, платного контента "для випов" у меня нет и не будет :) Можете просто читать про то, о чём я пишу, если вам это интересно :)

Strip Engine Code

Ох уж этот Strip Engine Code. В статье про UnityWebGL + React меня обвиняли во всех смертных грехах за него. Но есть простое правило. Чтобы делать такую оптимизацию, надо "думать как Unity". И вот банальный пример из сегодняшнего)

Есть у нас проект с ARFoundation, но так как камеру на старте интерфейсного приложения запрашивать плохо и моветон, то это сделано в том месте, где пользователю потребуется этот функционал. Собственно по этой причине для запроса разрешения на IOS используется Application.RequestUserAuthorization. Окей, запускаем. Не работает. Но так как я старый боец с Unity, я прост пишу строчку в классе. private WebCamTexture _DummyDependency; Она не делает ровным счётом ничего, но всё работает. Хотя казалось бы зачем? Мы же используем камеру в ARFoundation? Должна же быть зависимость? Ну вот по мнению Unity не должна) И в Unity много таких приколов. Поэтому надо учиться думать как Unity в некоторых местах, если пользоваться галочкой Strip Engine Code :)

Интересное видео про SDF
https://www.youtube.com/watch?v=xQfqtR7bbT8

SDF или Signed Distance Fields довольно удобная штука. По своей сути это практически 3д текстура, которая в каждом текселе хранит информацию до ближайшей поверхности объекта. Вне объекта — это положительные значения, внутри отрицательные. Используются они в основном в VFX или в рассчёте коллизий скажем в деформируемых объектах, таких как ткани или же другие сложные объекты. То есть по сути SDF описывают геометрию объекта.

Одним из главных недостатков SDF против описания геометрии мешами заключается в производительности. Но в GPU Gems 3 есть прикольная статья на эту тему. А в видео просто показывают прикольное применение этой техники в Unity. Хотя для конкретно того, что в видео (кроме sdf raymarching по сути) я бы лучше использовал Vector Fields.

Ну и то что в VFX Graph есть SDF ноды. Посмотреть можно тут.

Забавный факт про JSON Utility

Вот никогда им не пользовался, а тут чёт решил (ну не хорошо в статью пихать ньютонсофт) Сижу, кручу сериализацию, чтобы она была симпатичной. И вдруг сохранения выдают какой-то супер великий трюк. У меня полный инвентарь предметов. Я начинаю искать в чём проблема. И казалось бы, что могло пойти не так? А вот знать надо, что JsonUtility.ToJson(user) скажем не просто сериализует объект, но ещё и по сути вызывает new в каждом сериализуемом поле. И на выходе мы получаем полностью проинициализированный объект. Причём изменяется именно оригинальный объект. То есть мы пытаемся сохранить строку, а Unity такое "мы тебе все нулы заменили объектами, тебе же это было надо"

Почему? Зачем? Загадка юнити сериализации. Но как я ей не пользовался, так и не буду пользоваться. Где там мой ньютонсофт, чтобы добить инвентарь)

Чтож, как и просили, я написал
https://habr.com/ru/post/700272/

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

P.S. В каждом классе я что-то переписывал по 2-3 раза, чтобы результат меня устроил :)

Спасибо всем, кто скинул вчера на кофеёк :) Всё долго, капсул на неделю мне точно хватит XD

Иногда забавно, как работает уверенность в себе

Я уже прожил синдром самозванца. Он у меня был когда в далёком 2017 я работал в KamaGames с особым обострением, когда я неделю не мог локализовать баг, так как это был баг Unity. Хотя каму я всегда буду вспоминать с теплом и любовью. И конечно меня каждый раз немного задевает негативная реакция на всякие мои фразы, которые звучат самонадеянно :) Типа этой статьи. Или подписи на хабре Master Of Unity3d, к которой прицепился человек в комментах к сегодняшней статье.

Как победить синдром самозванца? Что ты начинаешь принимать такие фразы или ситуации не очень близко к сердцу?) Кроме банальный фраз в стиле «не критикуют тех, кто ничего не делает». Мне помогло закрыть больше 70 проектов за 3 года с совокупным бюджетом больше 100 миллионов рублей. Я не беру те случаи, где я работал в компаниях с проектами в разы больше нашего среднего проекта :)

Помимо запуска всяких экспериментов, своих продуктов и проектов, которые вполне работают и пока большая часть как бы там ни было коммерчески эффективная :) Я не считаю себя лучшим разработчиком. Я даже знаю ребят в разы сильнее меня в шейдерах, в архитектуре, в ии, да и в бизнес логике (и это всё разные люди). Я считаю только, что лучший в скоростной разработке неведомой херни. И просто делюсь с вами своим опытом работы в 10 лет. Где я был и со стороны инди, и со стороны корпората, и со стороны средней компании, со стороны стартапера, и со стороны аутсорс студии :) Представителем разработки, бизнеса, маркетолога и чем я только не занимался за эти годы) По обложкам в статьях даже видно, как “круто” я дизайню в фотошопе XD Так что я вероятно не лучший, но повидал некоторое дерьмо :)

Форум по всем темам компьютерной графики в TG

Мой знакомый запустил экспериментально форум по разным темам из области компьютерной графики ТГ. Так что кто интересуется темой — подписывайтесь и выбирайте топик, который больше интересен вам :)

Я наконец-то обогнал Plarium XD

По вкладу в хаб Unity на хабре XD Правда они давно туда ничего не пишут)

Прикольная статья с примером async/await в Unity
https://habr.com/ru/post/699212/

Я как-то пропустил эту статью, но хорошее описание кастомного Awaiter'a. Мне чуть структура текста не нравится, но это не важно и вкусовщина. Главное суть. Писать асинхронный код в разы удобнее, чем колбеки. Но для того же WebGL чистый Task лучше не использовать, так как юнити там не поддерживает многопоточность. И когда async/await использует thread pool под капотом, то оно не работает. Да же пользуюясь великолепным UniTask надо внимательно прочесть вот эту часть в его Read me

Most UniTask methods run on a single thread (PlayerLoop), with only UniTask.Run(Task.Run equivalent) and UniTask.SwitchToThreadPool running on a thread pool. If you use a thread pool, it won't work with WebGL and so on.

UniTask.Run is now deprecated. You can use UniTask.RunOnThreadPool instead. And also consider whether you can use UniTask.Create or UniTask.Void.

Про «хаки» редактора в Unity
https://blog.unity.com/technology/advanced-editor-noscripting-hacks-to-save-you-time-part-2

В блоге Unity недавно выходила заметка про хаки. Советую не бросать после первого пункта. Первый пункт (а точнее хак про реквайр компонент) звучит как нечто базовое, но дальше есть пару действительно интересных мыслей. С темплейтами — прикольно. С csv понятно и интересная идея. Конечно сейчас чаще данные игровые хранятся на сервере, чем на клиенте. Зависит от масштаба игры конечно. Про такой концепт я знал, но в таком ключе не думал. При поставке ассет бандлами контента и данных может быть даже полезно :)

Нюансы Drag EventSystem

Есть ещё один забавный нюанс Unity EventSystem про который я не написал в статье с инвентарём в части с Drag&Drop. Вдруг это кому-то когда-то сэкономит время. При реализации драга, если использовать только IBeginDragHandler и IEndDragHandler без IDragHandler, то они не будут работать. Забавное решение, что другие интерфейсы зависят от подключения интерфейса, весьма «очевидное» поведение :)

В общем так как на это я потратил минут 20, как всегда, стоит про это написать :) Хотя про это написано в документации :)

Забавный эффект с трекингом головы
https://80.lv/articles/a-neat-anamorphic-illusion-set-up-in-ar-with-unity/

Когда-то я тоже делал аналогичный прототип, надо бы откопать. Только мне не совсем понятно для чего тут квест. Так как концепция сама элементарная с единственной проблемой — эффект действует только на одного пользователя. Берёшь любой трекинг головы (тот же OpenCV с 3д трекингом или медиа пайп) И ставишь камеру в точку между глаз пользователя. Получается такой забавный эффект :) Но визуально конечно всё равно смотрится эффектно :)