Чем мы занимались последние годы?
https://www.youtube.com/watch?v=yjWZHJTndGk

Наконец-то мы доделали небольшой рил с нашими работами, которые не за 10 печатями тайны. Тут конечно далеко не все проекты и не всё, что мы сделали за 4 года работы. Но тем не менее теперь будет проще кидать кому-либо видео и объяснять "чем мы занимаемся". И когда смотришь на такие вещи прям ностальгия по тому, как делался каждый проект :)

А то пишу я тут много в канал, а чем я вообще занимаюсь то может быть многим непонятно XD Да и на сайте давно уже не все проекты, которыми можно похвастаться :)

И ещё про моё понимание плохого кода

Плохой код — это не тот который сложно расширять в первую очередь. Сложно расширяемый код может быть вполне себе норм. Просто не рассчитанный под такое резкое изменение бизнес требований. Плохой код — это тот который сложно понять и сложно переписывать. Я знаю, что некоторые лиды истерят на тему скажем вызовов Camera.main в апдейте, и считают это плохим кодом. Это тупо ошибка, но которая правится легко, обнаруживается легко. Дал пару раз человеку линейкой (хорошей такой, металлической) по рукам и всё хорошо. А когда человек считает, что он непризнанный гений и строит очень сложные конструкции потому что "он так видит". Это в разы опаснее. Можно нарушить SOLID, писать не по паттернам и код всё равно будет понятным. А можно по солиду такое чудовище искусства абстракционизма построить, что прийдётся идти за бутылкой джина, чтобы разобраться "а как это вообще работает то?"

Собственно в обсуждении плохого кода я показал неплохой пример своего "плохого кода", который может запутать в своей реализации. Так как единственный вопрос который может возникнуть по причине разделения паузы и состояния "А нахрена?" Но это ещё "ласковый" пример. Так как класс в 200 строк и в целом легко понять, что он в общем делает. А я прошу понять и простить, так как проект нужно было сдать за 7 дней, у меня была температура 38, и я был в целом не в себе :) А делать проект должен был уметь оооочень много. Но всё это делать он должен был всего два дня, так что как бы и ладно. Вот пример: https://pastebin.com/a9t7cFLX

Второй же пример. Хороший. Я опишу на словах, так как там нужно выкладывать репозиторий коммерческого проекта в паблик, чтобы объяснить всё элегантность решения. А так делать нельзя :) Есть у меня допустим проект по визуализации графов. И там используется подход того, что есть сторадж с данными о графах. Сам граф, вершины графа, алгоритм укладки знает только айди вершин и связи. Допустим вам нужна таблица всех вершин. Вы передаёте айди в скроллер, скроллер передаёт его карточкам, а карточки идут в сторадж чтобы забрать данные и их отрисовать. Тоже самое скажем с окном информации о вершине. Вы кликаете на вершину, вершина отдаёт айди окну, окно идёт в сторадж, забирает по айди объект и отрисовывает окно информации о вершине. То есть система вообще ничего не знает о характере данных. Вчера это был социальный граф, завтра это граф транзакций между пользователями. И для того, чтобы что-то изменить нужно просто будет переписать окна. А не переписывать во всей системе ссылки. Так как общая система манипулирует какими-то неизвестными циферками. Эта иллюстрация уже к примеру из публикации выше про "пробрасывать глубоко ссылки не стоит".

Просто часто плохим кодом почему-то называют ребята, особенно из других сфер, код который им непривычен и не нравится. Я встречал критику "что это за хрень" про Dirty Flag, хотя это вполне удобная себе штука в контексте Unity и является особенностью, а не плохим кодом. И пока я консультировал множество кампаний я повидал некоторое дерьмо. Самый ужасный код который я видел был для одной сине-голубой компании, в которой предыдущий подрядчик построил фабрику через фабрику на 10 фабрик создающих друг друга. Я 8 часов с логами тупо разбирался: "А как это вообще нахрен работает?" Просто есть особенности фреймворка, и в Unity нет такого, что он мотивирует писать плохой код. Просто написание кода в юнити имеет свои особенности к подходам и практикам. Так же как и в Entity, так же как и в ASP, так же как и в Xamarin :) Поэтому я не понимаю, когда мне говорят, что в Unity про плохой код. Плохой код пишут плохие программисты, а Unity просто инструмент, которым надо уметь пользоваться.

UPD. Даже не так. Плохой код пишут все, когда это нужно. Плохие программисты или ещё неопытные не видят, когда их код плохой :)

Лиды должны уметь говорить на языке бизнеса

На самом деле при работе на мой взгляд важно объяснять всё на языке бизнеса. Я собаку съел на защите технического отдела за последние годы. Но просто бизнес не понимает "сложно", "плохо", "техдолг" нужно рефакторить. Аргументация должна быть конкретной в терминах бизнеса, а для этого надо понимать бизнес. Не нужно чувствовать себя самозванцем "если я не могу писать систему без багов, то я не профессионал". Современные системы настолько сложны, и иногда на их разработку дают так мало времени, что баги и проблемы проекта — это неизбежность. Где нужно соблюдать баланс, чтобы система не разваливалась, но при этом и фичи не разрабатывались месяцами.

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

Тоже самое про фичи и альтернативные реализации. Скажем что-то сделать сложно или тупо в рамках системы (такое бывает часто), но если вы хотите "продать бизнесу идею", то нужно предложить бизнес альтернативу решающую ту же проблему. Тогда бизнес готов будет обсуждать. Так как тезис "это делать сложно", если бизнес думает что функция очень важная — не работает. А вот "это делать сложно, но вот это делает почти тоже самое, но делается быстро и ничего нам не ломает" — это обсуждаемо. Причём не надо ставить под сомнение разумность бизнес требования "пользователи так не делают". Обычно бизнес по аналитике, опыту или ещё чему-то в курсе, что пользователи так делают. Поэтому и возникло такое продуктовое требование.

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

Новая игра для White Label Games

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

Делаем крутые эффекты с помощью Animation Curve
https://habr.com/ru/post/699520/

А вот и время появилось таки написать статью про то, как Animation Curve в текстуру превращать и что с этим можно делать. Думаю это кому-то будет полезно.

Прикольная статья разбирающая аспекты настройки света в URP
https://blog.unity.com/games/shedding-light-on-universal-render-pipeline-for-unity-2021-lts

Когда-нибудь я и сам перееду на URP, буду писать шейдеры не кодом, а в шейдер графе и это всё будет супер полезно. Но это совсем другая история. Почему-то (возможно ошибочно) у меня до сих пор есть лёгкое недоверие к работе URP в мобильном WebGL. И что как только я начну туда переезжать, то огребу тонну... новых знаний. Но статья всё равно интересная.

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

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

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

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

Поговорил про 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 Так что я вероятно не лучший, но повидал некоторое дерьмо :)