Particle Plexus
https://mirzabeig.substack.com/p/unity-tutorial-particle-plexus-part-3

Классный туториал по красивому визуальному эффекту. Люблю такой визуально простой, но при этом эффектный VFX.

#новости

Открытость IT, а точнее разработки

Давно ничего не писал. Но и дел много + я ща в походных условиях осваиваюсь. А сейчас раз уж появилась мысль — стоит написать.

На пост меня навело то что ко мне пришли с рекламой закрытого канала. Я такое рекламировать не хочу, так как для меня реклама погоды в моих доходах не создаёт. При огромной цене поста относительно CPV в 10 рублей за просмотр. То есть около 10к рублей за пост. У меня час консалта стоит как бы столько же (хотя я уже думаю сделать дороже). Не беря основной бизнес — доходов с проектов. Ладно, речь не об этом.

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

Не, там конечно будет как в той же доте) Первое время тебя будут гнобить. Нужно будет перетерпеть саркастические ответы на новичковые вопросы и тому подобное. Но в разработке все всегда были готовы помочь друг-другу. Причём без оплаты. Даже взяв за пример мой консалт. Он платный: 1) для бизнеса 2) при конкретном коммерческом запросе.

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

Курсы — норм, так как это структурирование информации, для тех кто хочет ускориться и не хочет сам заниматься. Но всё же комьюнити разработчиков, общение в айти и т.п. должно оставаться открытым. А то скоро как у юристов будет сайт «программист ру», где за 100 рублей будут отвечать где в блоке с кодом «;» пропущена :)

#мысли

Загадка Order in Layer

Unity иногда поражает своими решениями. Особенно их очевидностью. Вот вы знаете какое максимальное значение у sortingOrder в SpriteRenderer? Ну наверное если работаете с 2д много то знаете. Но вот почему так - загадка. А давайте попробуем угадать?

Сначала сходим в документацию. Там ничего не сказано. Ну ладно, документация нужна только трусам. У нас же есть код, а код лучшая документация. Посмотрим тип sortingOrder в коде. Ну вроде бы int. Следовательно по идее значение должно быть равно int.MaxValue - 2 147 483 647? Ведь так Unity? Так? *тут должна быть ухмылка Энакина, но в текст в телеграме нельзя вставить картинку*

Не, опять не угадал. Максимальное значение равно - 32767. То есть short.MaxValue. Почему при этом sortingOrder у нас типа int, а не short? Ну видимо во славу сатаны. А я потратил 5 минут лишних на задачу и ещё на пост чутка времени, чтобы узнать почему при драге sortingOrder = int.MaxValue ставит -1 в значение порядка сортировки объекта. Я считаю и обработка больших значений божественная, и документация идеальная, и код очень логичный. Уже за 12 лет работы с этим движком удивлять он всё так же не перестаёт.

UPD: Перепроверил. Ладно, это не написано в мануале по спрайт рендереру и в апи спрайт рендерера. Но если зайти прям в пропертю в апи спрайт рендерера, то там это написано. Ну как обычно, чтобы докопаться до истины нужно постараться.

#оработе

Продюсер на вольных хлебах: Об ошибках

Я рассказал о работе, а теперь поговорим об ошибках. Их было много за 6 лет, но хочется выделить какие-то самые важные. Хотя в первую очередь я поговорю почему ошибаться нормально.

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

1. "Победителей не судят" - это ошибка

Мне всего лишь 30. Свой путь в бизнесе и переговорах я по сути начал 6 лет назад, когда мне было 24. И тогда был и юношеский максимализм, и я прям помню как продвигал идею того, что "победителей не судят". Я любил жестко продвигать свою позицию, спорить по многим вопросам и так далее. Потому что "победителей не судят". Если проект сделан и работает - то к тебе ноль вопросов. И что я могу сказать по прошествии 6 лет в бизнесе - это действительно так. Победителей не судят. Но есть нюанс.

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

Отстаивать свою позицию важно и нужно, но как и во всём - нужен баланс.

2. "Мы же делаем для вас лучше"

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

3. "Все сам"

Это вообще топ-1 ошибка. Я уже не помню сколько раз я в проектах не делегировал разработку когда надо было. Я умею работать с супер скоростью. Некоторые проекты я целиком с нуля разрабатывал за 2-3 дня. Потому что за 90 проектов мне нужно просто сесть и написать. Чтобы сделать тот же раннер или ещё какую-то игровую механику мне даже задумываться не надо. Просто попечатать пару часов строчки кода. Так как для меня в Unity всё ключевое понятно.

Но очень часто было такое что я был загружен и не отдавал кому-то другому проект. А потом когда до дедлайна остаётся пара дней "ну мы уже ни с кем не договоримся" и я в огне всё делаю сам. Обычно прохлебав какие-то переговоры или какой-то контракт. Да либо просто устраивая себе весёлые ночи без сна. Лучше заранее и сразу грамотно планировать ресурсы и своё время. И по сути этому я более менее (и то не до конца) учусь сейчас.

4. "Излишняя принципиальность"

Тут я не считаю себя неправым до конца. И не считаю это грубой ошибкой. Но всё же иногда чисто с коммерческой точки зрения можно было быть мягче. У меня в контрактах прописано обычно 3 итерации правок. Была такая история что в одном контракте мы пошли в пятую итерацию, где я предварительно сказал: "Внимательно - это точно последняя". Мы их сделали и пришло ещё несколько мелких правок, на которые я сказал нет. Среди которых была одна критическая для клиента. Точнее даже так, я не сказал нет. Это проблема того что мало кто умеет вести переговоры. Я сказал: "акт и оплата сегодня и тогда сделаем". Считаю ли я себя неправым в этой ситуации - в целом нет. Но вот обязательно ли было так делать - тоже нет. Я это сделал не по коммерческим соображениям, а чисто из принципа.

Паттерны в Unity
https://habr.com/ru/articles/826014/

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

Про паттерны как всегда стоит сказать, что это шаблоны и упрощение, но не святой грааль разработки. А то фанаты солида вообще иногда похожи не на разработчиков, а на религиозный культ. Паттерны полезно знать, так как они упрощают работу и чтобы не переизобретать велосипед. А главным в разработке я считаю старую добрую логику. Я придерживаюсь главного принципа - KISS (Keep it simple stupid)

Если вы придумали автоматизацию какого-то процесса или же чтобы ваш код через рефлексию как-то кофе варил и не можете это объяснить одним предложением - это плохая автоматизация. Это бывало часто у меня джуном и мидлом. Что я придумаю как что-то делать автоматически "элегантно" через какой-то хитровыдуманный способ. В среднем это плохо.

#новости

Использование встроенных шрифтов
https://habr.com/ru/articles/828620/

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

#новости

Создание игр на Unity: С чего начать?
https://habr.com/ru/articles/828302/

Давно ничего не писал. Сейчас и образ жизни изменил, и завал по работе, так что было не до блога. Но я вернусь! Про статью - это скорее повод, статья так себе. Мне не особо понравилась. Такая из разряда "всё везде и сразу". Очень много информации которую тяжело усвоить. Я люблю всё везде и сразу, как какой-то простой и понятный справочник. Но зато она пробудила воспоминания чисто своим названием.

Не знаю как вы, а я в школе был задротом очень много играл в игры. Ну, а то же, даже в топ-3 гильдий европы в WoW в основном составе бегал бить Иллидана. И собственно как наверное у многих геймеров у меня была мысль "блин, хотелось бы уметь делать такое". Но жил я в Волгограде, поэтому курсы по разработке то было найти сложно. Не то что по игровой разработке, а просто по разработке. Это сейчас из каждого утюга рекламируется новый курс, а в те времена разработчики жили с деревянными игрушками и без дяди индуса, который объяснит любую херню в разработке. Я пытался найти репетитора или курс, чтобы начать учиться, но в те времена не нашел.

Учится разработке раньше было в разы хардкорнее. Хотя смешно, что в том же WoW мне скинули я считаю лучший мануал по написанию сайтов на HTML, с которого я наверное начал что-то разрабатывать. Что забавно начал я с веба, так как я просто не понял как скомпилировать код. Я типа чёт поковырял в плюсах на сколько я помню в 9 классе, но так и не разобрался: "А как это хотя бы запустить?". Повторюсь, тогда не было туториалов от индусов на любой чих. Тогда учиться разработке было посложнее.

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

#новости

Реалистичный шейдер воды для VR
https://80.lv/articles/artist-showcases-a-realistic-water-shader-running-in-vr-on-meta-quest-3/

Художник, боюсь ошибиться в имени, продемонстрировал классный шейдер воды. Шейдер сделан для URP и оптимизирован для работы с тем же Meta Quest 3.

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

#новости

Radiance Cascade в 2д в Unity
https://github.com/Youssef-Afella/RadianceCascadesUnity

Относительно недавно Александр Санников описал новый подход к расчету глобального освещения. И вот уже начинают появляться репозитории с различными реализациями. И тут у нас 2д реализация данного подхода. Всегда интересно такое поразбирать :)

#новости

В дополнение к прошлому посту видео как этот подход работает. Мне очень нравится как визуально при движении «светящейся жидкости» на это реагирует освещение.

Процедурная анимация в стиле Doc Ock
https://80.lv/articles/unity-developer-unveiled-doc-ock-inspired-proc-animated-creature/

Классная анимация перемещения представленная разработчиком Keenan Woodall. Круто что она сделана из стандартных ассетов. Выглядит интересно.

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

#новости

Френдзания
https://game.dobry-kids.ru

Это был длинный и интересный путь до релиза, и теперь можно рассказать про наш крутой проект - «Френдзания» для детской линейки Добрый. Мы отвечали за разработку игры в рамках большой NCP-активации бренда, которую реализует агентство The Diversity.

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

Удалось применить множество интересных решений: и подход к тому, что авторизация вынесена в нативную часть, и различные подходы к взаимодействию с бекендом, и ряд хитрых оптимизаций в рамках игры. Опыт с прошлым большим веб тайкуном дал, конечно, многое. Он показал, как фронтенд грамотно должен выступать «тонким клиентом», чтобы он работал быстро и правильно.

В общем, я рад, что в портфолио появится такой классный проект и о нём можно рассказать :)

#оработе

Game UI Database
https://www.gameuidatabase.com/

Это что за прелесть! Вышла вторая версия большого сайта с базой данных интерфейсов более чем 1300 игр. Вот у вас бывает такое при постановке задач на GUI? "Ачивки надо сделать ну как в той игре. Да играл ты в неё. Ща поищу." И то что пинтерест и гугл не по всем играм хорошо находят геймплейные скрины и интерфейсы.

А тут целая большая база данных по 1300+ играм, как я посмотрел, почти с каждым интерфейсным экраном. Это нам нада. И сохранить и закрепить. Гуй в играх в целом часто боль, поэтому какие-то опорные материалы нужны всегда.

#новости

Индустриальный AR помощник Hyundai
https://unity.com/blog/industry-first-ar-solution-for-construction-machinery

Я так люблю такие громкие заголовки. Первое индустриальное AR решение (ну это конечно СЕО, а не в самой статье, но забавно). Я такое впервые делал думаю эдак в году 2018. Ужас уже 6 лет прошло.

Статья забавная. Для тех кто не знал о разных применениях AR - вот пример. Подобные AR системы для промышленности делают уже давно, и я такие делал, просто игры мне нравится делать больше. Визуализация данных с датчиков и сенсоров в пространстве, отображение BIM, CAD, DWG моделей и сложных форм, какие-то базовые подсказки даже делали.

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

Идея того чтобы совмещать реальный объект и модель в дополненной реальности не нова. И я когда-то в различных R&D зубы сломал именно об трекинг. У меня было две задачи подобного класса, где современным системам трекинга можно было сказать: "ВЫ НЕГОТОВЫ" (с) Иллидан. Это контроль качества и AR навигация. Но первое это прям на максималках. Так как там всегда очень сложные условия для любых скажем VSLAM систем. Стационарные системы вроде Vicon неудобно эксплуатировать. Радиолокационка, магнитка, ультразвук - проблемы с точностью. Хорошей точностью в целом обладает только оптический трекинг пока.

В общем статья вызвала у меня ностальгию по временам, когда я занимался серьёзными индустриальными задачами, и придумывал разные решения под разные бизнес требования, так как разбирался (да и до сих пор разбираюсь) во всех видах трекинга. Жаль вот эту часть в статье не подсветили, но подозреваю причина проста - так как и тут эти проблемы не решили.

#новости

Эффект цепной молнии
https://youtu.be/eSqoJVdGbxM?si=zvabkt2qZEQvv_cR

Новый туториал от Gabriel Aguiar с эффектом цепной молнии. Смотрится симпатично. Но главное чем больше туторов по VFX разберёшь и проделаешь, тем проще делать свои кастомные эффекты.

#новости

Алгоритмы столкновений
https://leanrada.com/notes/sweep-and-prune/

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

#новости

Ghost Cat Anzu: Ротоскопирование за кадром
https://80.lv/articles/ghost-cat-anzu-rotoscoping-comparison/

Люблю я аниме и люблю старые техники. Одна из таких забавных техник — это ротоскопирование. В статье мне просто понравится пример на видео с покадровым повтором в анимации референса. Выглядит наглядно и классно.

Вообще этот приём в основном использовался в анимации, но в 80-ых так же в таких культовых играх как Мортал Комбат и Принц Персии. Вот любопытная статья на тему https://group-animation.livejournal.com/12739.html

Сейчас он конечно устарел, и его заменил Motion Capture который в среднем дешевле и что важнее быстрее + 3д. Даже в случае с 2д играми, как более оптимальный продакшен процесс. Но мне всё равно нравятся такие ламповые старые штуки.

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

#новости

Порталы в неевклидовом пространстве
https://www.bytehyve.com/view/blog/?i=84&t=portals_for_non-euclidean_spaces

Интересная статья про механику порталов. Плюс тут про неевклидово пространство, а «нереальная геометрия» сама по себе достаточно интересная штука. Такой прием очень любил художник Эшер, рисуя картины с нереальной геометрией. С использованием идей из его картин отлично получаются игры-головоломки и отличный тому пример — Monument Valley. Что не удивительно, так как авторы игры говорили о том, что вдохновлялись литографией Эшера «Восхождение и спуск».

#новости

UniTask на замену корутинам, таскам и эвейтерам
https://youtu.be/OlNJ2GkaPTE?si=15J7Vzn0DwcBadgh

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

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

#новости

Видеть сквозь стены: шейдер для Unity
https://80.lv/articles/this-unity-dissolve-shader-lets-you-see-through-walls/

Шейдер Энди Флетчера для Unity позволяет создавать эффекты растворения и видеть сквозь стены, улучшая визуальные эффекты и игровой процесс. Эффект реализован достаточно просто, через отрисовку спот текстуры по screen space UV.

Выглядит красиво. Сделано элегантно и просто. Кайф.

#новости