Одна из любимых картинок на все времена

Кто-нибудь знает как собираются приложения под IOS в обход trusted devices?

Гугл говорит, что это невозможно. Документация эпла говорит что так нельзя. Самое похожее на такой механизм — это AdHoc (хотя с автоматической подписью вообще непонятно какой провижен оно использует) Но вот что интересно. Я встречал и без jailbrake приложения которым телефон "не доверяет". Скажем приложения покер румов. Там просто дают ссылку, которую если расковырять, она очень похожа на AdHoc, но вместо IPA, там идёт ссылка на зип архив под названием инсталлер. И крайне интересно, как это сделано и работает? Это какой-то воркэраунд или механизм от эпла? Непонятно

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

Собираем новый пакет

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

Animation Curve в текстуру

Как всегда для своих ссылочку пораньше чем я напишу на эту тему статью и причешу. Собственно преобразование Animation Curve в текстуру с пробросом в материал. Можно ещё в рендереры потом сделать и т.п.

В репозитории можно посмотреть, как сделать кастомный инспектор для всяких шейдер проперти в скрипте и т.п. Но главное "а зачем это надо?". На самом деле не всегда удобно математикой задавать кривые. Иногда удобно это делать руками. На примере того же поста повыше про подбор альфы в depth маск для вытравки человека. Думаю напишу статейку в котором покажу ряд применений такого подхода. А так сгенерировать текстуру скажем 256х1 ничего не стоит, но при создании какого либо эффекта или передаче в шейдер данных может сэкономить просто уйму времени :)

Да в особенности это про режим Repeat и Mirror. Так как задать сложную периодическую кривую и регулировать её в шейдере, это задача не для слабых духом. А делать тоже самое через курв и тайлинг uv легко и интуитивно понятно

Нейросети и контент

Я уверен, что нейросети не заменят художников, но станут шикарным инструментом для художников. Концепты, баннеры и т.п. набрасывать и докручивать будет просто кайф :) И вот какую красоту тут сделал один художник :) https://dtf.ru/gamedev/1439137-hudozhnik-sozdal-interaktivnyy-koncept-art-pri-pomoshchi-neyroseti-midjourney-i-unity

А вы знали, что в Unity есть Device Simulator?

Конечно никакого отношения к "настоящему симулятору устройства" он не имеет, но я вообще как-то пропустил эту фичу. Но оказывается в юнити теперь есть что-то на подобие функции в Google Chrome, только удобнее засчёт нарисованных бровок и т.п. https://docs.unity3d.com/Packages/com.unity.device-simulator@2.2/manual/index.html

Подсветка сейф зоны, информация о гпу и цпу, эмуляция событий Low Memory, эмуляция событий тача. И это просто режим геймвью. Симуляция классов Screen, Application, SystemInfo)

В общем забавно, я как-то упустил когда эта фича вообще появилась и заехала в редактор :)

Давайте обсудим, что такое плохой код?

С утра комментарием к старому посту меня снова заинтересовали этой темой. Все часто говорят про плохой код, а что это на самом деле? Вы уверены, что однозначно это знаете и понимаете?

Мы не идём от того, что такое хороший код. Что там код должен быть компактным (класс в 1000 строк это как минимум вызывает вопросы). Что код должен быть модульным и т.п. А так же не берём вкусовщину, вроде мантры солида :) И соответственно если ты нарушаешь Single Responsibility то это очень плохой код. Почему? Потому что если у класса нет стейта, это функциональный объект, который занимает 200 строк, но логика поведения его функциональна, то к каким проблемам ведёт нарушение пресловутого S?

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

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

Если в классе описаны 2 и более стейтов или кроссстейтов — это очень плохо.
Если реализация кода не позволяет написать клиент в консоли — это плохо. (самая простая проверка отделения отображения от поведения)
Если любая ссылка пробрасывается через иерархию вызовов в методах больше 3 раз — это в среднем плохо. В таком случае надо выносить ссылку в статический контейнер

Кто хочет может в комментарии докидать свои, потому что я описал явно не всё.

Чем мы занимались последние годы?
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к человек. В целом контент всё равно остаётся бесплатным, я не буду вводить платные функции, подписки, посты за деньги, так как не для того я канал создавал. Но кто-то захочет поддержать канал, это конечно же приветствуется и теперь есть такая возможность :) Я стараюсь делать качественный контент по сложным темам, вы угощаете меня кофе. По-моему вполне хорошая сделка. Не хотите, нет возможности, платного контента "для випов" у меня нет и не будет :) Можете просто читать про то, о чём я пишу, если вам это интересно :)