Последнюю неделю я решил ещё сильнее углубится в рендер. В основном я изучал тесселяцию. И я понял, что пора переходить на URP :)

Во-первых, по URP появилось достаточно много материалов. Во-вторых, я разобрался как пишутся кодом шейдеры под URP и это так же в чём-то удобнее. Core.hlsl имеет в себе много прикольного

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

https://dtf.ru/gameindustry/1270216-unity-otmenila-gigaya-demo-igru-s-realnymi-primerami-po-razrabotke-na-svoem-dvizhke

Очень жаль

Что-то полистал я новости последние. И Unity видимо решили повторить успех близов по уровню скандалов. Про "разработчики которые не думают на старте о монетизации — идиоты", это прям что-то уровня "у вас что нет телефонов?"

Я не буду конечно говорить, что пора идти на другой движок и т.п. Так как вменяемая альтернатива одна — Unreal Engine. Но потратив на Unity уже 8 лет, я не знаю что юнитеки должны сделать, чтобы заставить меня переучиться на другой инструмент. Так как пиар и инфополе одно, а инструментарий удобный для работы — другое. Но конечно печально это всё

А, ну и ссылка на новость: https://www.pocketgamer.biz/interview/79190/unity-ironsource-john-riccitiello-marc-whitten-merger/

Если коротко, по всему этому скандалу "из ничего". Я не вижу никакой проблемы в монетизации, и в тезисах в целом (ну кроме идиотов) Но вообще CEO компании не должен так выражаться на острые темы в принципе. Да, монетизация — это важно для успешного продукта. И да, юнитеков можно понять, так как деньги им приносят успешные продукты. Но у движка огромная аудитория и просто творческих людей, которые делают юнити тем, чем он так прекрасен

Юнити прекрасен не самим движком, своим рендером, фичами, архитектурой, лайфтайм лупом. UI лучше в нативном дройде например, у веба юнити курит в сторонке (боже какую магию можно творить на CSS). По рендеру тоже, всё что встроенное в юнити переписывается нормальными разрабами в первую очередь. Я уже не помню когда последний раз использовал стандарт шейдер. Да даже физика рейкастов у меня своя для VR проектов, так как PhysX слишком медленный в этом контексте для пары моих задач

Основная ценность Unity — это его комьюнити. И юнитеки делают вообще всё, чтобы поссорится со своим комьюнити последнее время. Я вряд ли сменю Unity не потому, что мне трудно выучить плюсы (я их как бы знаю, хотя и не на про уровне. Но CLI плюсы в целом несложные. Всё что дальше 17 стандарта я не в курсе конечно что там творится. Я остановился на бусте и смарт поинтерах) и в анриале объективно есть часть прикольных фич. Но в юнити я эти фичи заменяю тем же самым сделанным комьюнити + пользуюсь своими наработками + несколькими сотнями готовых репозиториев

Для того же света есть SEGI и Aura. Есть куча крутых репозиториев от keijiro. Есть множество репозиториев с разными технологиями на просторах гитхаба. И это не считая ещё огромного подмножества того, что сделано просто на шарпе. Типа того же моего порта https://github.com/Nox7atra/Triangle.Net-for-Unity Я по сути сделал пару утилитарных методов и перевёл точность на float, но это изначально старый шарповый https://github.com/wo80/Triangle.NET который стоит на плечах плюсовой библиотеки

В общем удивительное рядом. Я и раньше удивлялся работе с комьюнити от Unity, но сейчас такое ощущение, что они совсем себя решили опустить на дно в глазах комьюнити. Сначала закрытие Unity Answers, потом слияние с IronSource, потом закрытие Gigaya, а теперь вот это. Что же будет дальше?

Эхх, жаль этого исполнения нет на стриминг сервисах с музыкой :) Ностальгически скучаешь иногда даже по такому року :) https://youtu.be/n037fE7tol4

Классная симуляция https://github.com/Gornhoth/Unity-Smoothed-Particle-Hydrodynamics

Неплохая краткая статья по графике в юнити. Галопом по европам конечно, и много именно нюансов опущено, но это разумно. Как и говорит автор, все нюансы описать — это на книгу. Я бы только больше "литературы для домашнего изучения" добавил. Хотя бы рендер хелл и реалтайм рендеринг техникс https://habr.com/ru/post/677360/

Классный эффект скана https://github.com/MirzaBeig/Post-Processing-Scan

SIGGRAPH

Давно ничего не писал из-за завала по проектам) Нооо пора исправляться) Я обожаю смотреть всякие лекции и интересные доклады, и чтобы понимать что происходит в графике SIGGRAPH всегда обязателен к просмотру так же, как и Unite для Unity разработчиков) https://www.youtube.com/watch?v=vn-WzWm74Pc Конечно подобные штуки не для реалтайма, но по ним уже видно на что способны современные компьютеры в плане графики, симуляций всяких материалов и т.п. Плюс очень часто там можно "подсмотреть" интересные подходы и работы. Не всегда такие сложные, допустим если мы говорим про одежду, то интересно (хотя визуально попроще) она сделана в NFL 21 https://www.youtube.com/watch?v=_x3PBfk0-ww

Очень трудно стать экспертом работая в крупной компании

Сегодня я наткнулся на весьма любопытный ролик с которым я в целом согласен. Там есть 4 критерия того "в какой среде надо находится, чтобы стать экспертом". Если коротко по 4 пунктам

1) Множество повторений — это в целом путь изучения чего угодно. Я всегда был за обучение через практику, так как написав 40 раз одну и ту же задачу, ты делаешь её на автомате. В том числе поэтому в своих проектах я в среднем против использования готовых ассетов для мелкого функционала. Понятное дело "писать свой AVPro для практики" — глупая задача. Но всякие мелочи типа скриптов управления или камеры, полезно именно писать даже чисто для разминки. Пока это не станет автоматическим действием, как у меня. Условно мне дольше зайти на ассет стор и скачать ассет/поискать в гугл, чем написать свой Pinch, Zoom для управления мобилок или ограничитель камеры

2) Достоверная среда — в этом плане повезло с программированием. У нас среда почти всегда достоверная, как и в шахматах или в любой технической штуке. В том же покере (я когда-то был про игроком) всё немного сложнее. Конечно же я сыграл более 1 миллиона рук за свою карьеру. Но эту среду трудно считать достоверной без системы статистики. Ну то есть запомнить все руки невозможно + покер классно обманывает нас по психологии. Человеческий мозг так устроен, что он лучше запоминает яркие события. Поэтому "выигрыш на рандоме" запоминается лучше правильной игры. Просто про игроки каждую неделю разбирают свои сыгранные руки (так как я играл онлайн у меня была история рук, где можно было разобрать свои ошибки и причины). В офлайне интересные руки можно запоминать осознанно. Так как играя в про стиле ты будешь играть за 4-5 часов в среднем около 20-30 рук, что не так много информации. Но в разработке всегда результат достоверен)

3) Своевременная обратная связь — вот тут уже есть нюансы. С обычной работой программы исхода два "работает" и "не работает". Ты быстро обучаешься видеть классические баги, закономерности и т.п. И тут всё действительно просто. Многие баги я нахожу очень быстро, так как "я уже это всё видел". Причём даже в чужом коде, так как на самом деле даже в самой плохой архитектуре есть типовые паттерны и закономерности. Но вот архитектура даёт обратную связь совсем не сразу, если тут нет лида который даёт фидбек) Говорит о нюансах и т.п. Поэтому в ней на самом деле меньше всего экспертов. Особенно в продуктовых компаниях среди людей, которые работают по куче лет над одним проектом. Бывают исключения, люди которые прочитали все книги. Разбирают на досуге чужие репозитории (обожаю этим заниматься) и их архитектуру, кто сильно вкладывается в своё самообучение, но это единицы. Большинство читают мантру SOLID, DI и IoC, и выжимки из чистой архитектуры. А книжные знания в архитектуре имеют некоторую проблему. В контексте каждого проекта применим свой подход. Есть критика солида, DI и т.п. Есть другие подходы, есть куча архитектурных схем. И по сути каждая более или менее применима под контекст проекта. Единственный общий принцип для всего KISS :) Который очень часто в таком случае нарушают) И для его тренировки я очень рекомендую разбирать чужие репы. На своём коде трудно понять, что "он сложный". А вот на чужом легко) И опять таки начинаешь видеть закономерности сложного кода

4) Преднамеренная практика — и вот этот пункт самый сложный для выполнения в крупной компании. Побывать в крупной компании полезно, так как это свой контекст и надо понимать, как она работает и "её мышление". Но с точки зрения того же разработчика, ты через время, особенно когда сервис переходит в стадию оперирования начинаешь "делать одно и тоже без развития" и деградировать. Опять таки, есть люди которые самостоятельно практикуются дома, имеют пет проекты или истории типа моих статей. Чисто чтобы не "костенеть". Но я чаще всего уходил из компаний, так как я переставал получать новый опыт в принципе. Я просто делаю одно и тоже и не развиваюсь, значит мне пора дальше) Поэтому видимо в конце концов я пришёл в аутсорс, где по сути за 4 года я сделал больше 60 проектов. И каждый не особо похожий на другой) Когда проект новый (в крупной компании), то там чаще всего бывает интересно. Но на такой проект бывает трудно попасть)

И с чем я точно согласен в видео, что экспертность — это по сути про распознавание ситуаций и закономерностей, но достоверное. То есть по сути очень глубокая насмотренность. И это начинает казаться интуицией) Но по факту ты просто уже всё это видел, и понимаешь либо "куда смотреть", либо "к чему это приведёт". Рекомендую всем кто хочет стать эксперта завести себе простую привычку, чтобы не убивать много времени. Разбирать какой-нить репозиторий 1 раз в месяц. Не особо большой, для этого отлично подходят репозитории Keijiro Takahashi но можно и любые другие. И разбирая стараться замечать "что вам непонятно и почему". Это сильно увеличит качество вашего кода, так как проще будет видеть такие проблемы в своих решениях)

Насмотренность и работа

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

Чтож пора про что-то и со сцены рассказать осенью на https://mixrconf.ru :)

Версии и контент

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

У нас условия правда ещё сложнее. Контент делает несколько других команд и поставляет бандлами — и это ад. Когда система усложняются начинаешь постепенно сталкиваться с такой вещью как "баги Unity" и многие из них юнити часто правят. Но когда контент делался год, третьими лицами, а баг в новом контенте является критическом — ты в ловушке. Обновить юнити нельзя (упадёт весь старый контент), поправить баг нельзя (бывают баги без workaround). И поэтому всегда нужно помнить, что если проекту будет несколько лет, рано или поздно наступит такой момент, когда либо нужно будет всё обновить, либо вайпнуть :)

Помимо этого если мы идём по пути обновления надо всегда закладывать в архитектуру проекта проверку версий. И тут есть два подхода. Для богатых "поддерживать Х версий проекта и контента" или говорить пользователю "иди обновляйся". Вторым путём скажем идёт близзард в своём Hearthstone. Поэтому до релиза в сторы, если у вас контент хранится на бекенде, всегда закладывать в архитектуру небольшой скриптик. Который спрашивает у сервера "а совместимая ли у меня версия с текущим контентом?" И если нет, то вызывает попап "иди обновись в стор". Это сэкономит вам кучу нервов и времени)

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

Каждому разработчику лучше знать Python

Да и в целом знать несколько языков. Современная разработка позволяет дружить очень много вещей между собой. В той же юнити тоже видно много всяких технологий типа Node.js, так как под тем же десктопов всё супер. Благодаря виртуализации, WSL и докеру в целом можно запускать кучу всяких готовых технологий штук. Но почему именно питон?

Так сложилось, что из-за своей "простоты" на питоне написано столько всего, что там можно закопаться сколько полезного можно встроить в свой проект или пайплайн. https://github.com/wo1fsea/PyTexturePacker как пример

Так же полезно бывает уметь написать собственный простой веб-сервер с помощью Flask с какими-то mock ответами для тестирования. Обработка изображений, перепаковка, чистка проекта по юнити мете. Задач которые удобнее решать питоном очень много. Особенно в рамках винды/линукса, так как никто не мешает запускать Python скрипты из редактора)

Хотя конечно чтобы быть на самом деле "кроссплатформенным разработчиком" в Unity надо знать очень много. Чтобы хорошо работать с Unity WegGL — по хорошему нужно знать js и webpack, Android — Java хотя бы на базовом уровне, IOS — ObjectC/Swift. В идеале для ряда вещей ещё неплохо бы знать на базовом уровне C++ :)

Допустим с тем же WebGL, чтобы научиться грамотно строить работу приложения мне пришлось изучить React.js, хотя бы на среднем уровне, чтобы банально делать правильно "игровой интерфейс". Потому что Unity + WebGL на мобильных платформах имеет кучу проблем в части инпутфилдов, да и не только :) Да и грузится юнити на мобилках, даже если подрезать всё и вся не за 1 секунду) Поэтому лучше в натив выносить всякие "авторизации" и прочее, а игру грузить оффскрин, чтобы пользователь был "занят делом", пока оно грузится, а не смотрел 30 секунд на прогресс бар)

Поэтому не очень хорошо замыкаться в рамках только одного языка и одной технологии. В случае тех же выставок Python вообще must-have, так как если работать с компьютерным зрением, системами трекинга и по счастью вам доступен именно ПК, то OpenCVForUnity и прочие C# решения не сравняться с тем, что есть на Python :) Миллиард всяких полезных тулзов, туториалов (да их можно портировать на шарпы, но это обычно дело не быстрое) и т.п.

Я думаю можно будет побольше пописать про CV и технологии трекинга, так как с помощью них помимо "прикольных интерактивов", можно писать ещё и интересные продакшен тулзы. Та же комбинация IKinema Orion + HTC Vive была когда-то самым дешёвым Motion Capture из возможных) И с неплохим качеством) А потом эпл купил IKinema и нет больше Ориона :)

Лучше писать меньше кода, чем больше

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

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

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

1. Плохо документированы — и чтобы пользоваться библиотекой ты должен думать как библиотека. По сути понять идеологию по которой разрабы писали либу + спокойно читать чужие исходники, чтобы понимать "что не так". Так как в документации написано одно, а по исходникам всё совсем по-другому. Да и в целом можно разобраться

2. В них есть баги — и когда это критический баг, а либа решает очень много, нужно придумать воркэраунд. А для этого опять таки мы лезем в исходники либы и смотрим: "писать свой форк" — для опенсорсных, "придумать как обойти" — для закрытых либ, но декомпилируемых. Допустим вот в том же ARFoundation. Казалось бы готовая либа для AR, но у меня есть несколько расширений для неё так как: события на Android и IOS работают по разному и для этого нужен обработчик; в них есть часть багов для которых нужны воркэраунды; они немного по разному работают в разных условиях. Поэтому сделать большое AR приложение — это не просто интегрировать ARFoundation по туториалам и радоваться жизни, там есть огромное количество контекста, которые я продолжаю узнавать. Типа нюансов и проблем динамической подгрузке AR маркеров из облака. (Что такое AR маркер можно тут почитать)

3. Дружить библиотеки с друг другом — нетривиальная архитектурная задача. У каждой библиотеки свой контекст, своя идеология, свои баги, своя частота обновлений. И в рамках проекта интегрировать множество библиотек — уметь надо)

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

Современная разработка. Разработчик и библиотеки

К прошлому посту так сказать :)

Если кому-то интересно, то посмотреть можно тут)

Urban Ekb https://liveapp.onelink.me/V9Nw/hu5l1kvx
Urban Saint-P https://liveapp.onelink.me/V9Nw/tp36joqx

Красота математики

Конечно же математика не так нужна в решении средних задач программиста, но иногда она позволяет творить откровенную и не очевидную «магию»)

Я обожаю интересные задачи математики, в них можно найти очень интересные мысли и подходы, которые довольно неочевидны. Сегодня я наткнулся на любопытное видео. И действительно, очень крутая задача показывающая не очевидную математическую «магию». По сути на основе этой же задачи можно строить алгоритмы поиска скажем по связанным данным. Так как если данные связаны подобным образом, что обладают структурой циклов внутри себя, то это может значительно ускорить поиск в отличии от тех же жадных алгоритмов или алгоритмов поиска, которые работают за log(n) Так как нам не потребуется проходить по всем объектам) А можно предположить, что если наши данные представляют кучу несвязанных циклов, то с некоторой вероятностью сложность поиска будет уже пусть даже линейной, но по циклам меньше, чем log(n).

Допустим мы ищем в игре ботов фармящих золото. Часто боты работают как фермы, запускаются +- в одно и тоже время с разных айпи адресов. Но допустим мошенник хитрый, и рандомизирует время запуска + конечно же использует VPN. С помощью в некоторой степени той же идеи мы можем найти весь ботнет. Только вместо номеров на коробках у нас айпи адреса и время запуска (с некоторым люфтом). Мы смотрим айпи, смотрим время захода, ищем массив айпи с таким же временем захода, потом смотрим когда они ещё заходили, набросив пару фильтров отсекающих вероятно честных игроков) И таким образом находим массив айпи и аккаунтов которые с них заходили, чтобы забанить все эти аккаунты) Это конечно не прям такая же задача, и тут есть предположение, что боты не заходят совсем в случайное время со случайных неповторимых айпи, но базируется оно на той же идее, что мы можем свести данные к набору некоторых циклов)

Такими задачами конечно в среднем не занимаются разработчики, но это всё равно безумно интересно. Так же, как меня когда-то впечатлила идея qsort с двумя нодами. Идея в том, что в алгоритмах часто не обращают внимания на то, что сложность O(log(n)) в целом можно грубо развернуть в N * log(n) + C. Где N и C — это какие-то числа. И когда условный поиск/сортировка идёт по миллионам данных, то N=2 и N=1 — это два разительно отличающихся времени поиска)

Конечно я всё ещё считаю, что математика и алгоритмика в современном программировании обязательными не являются, так как в реальности такие задачи — это дай бог 2% задач. И есть много задач вообще не требующих математики) Но в любом случае это очень крутой инструмент :)

Интересный репозиторий с инверсной кинематикой https://github.com/ehsan-mohammadi/Aim-IK