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

Итак, так как сейчас мы с командой делаем один большой проект, то как-то сразу начинают вспоминаться очевидные грабли крупных проектов. Версии билдов и версии контента. Но дело даже не в этом, хочется отметить один важный нюанс. Контент должен либо уметь обновляться через 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

Прикольный шейдер бара здоровья или маны) Странно только, что без обработки стенсила для интерфейса. Это в целом "хороший тон" писать в интерфейсных шейдерах стенсил часть для обработки всяких UI масок. Хотя так как бар здоровья это в целом HUD оверлейный обычно, так что я могу придумать кейс использования маски — какая-нить анимация смены экрана и всё. Ну и мне чуть-чуть не хватает каких-нить пузырьков внутри, но это вопрос стиля игры, да и довольно простая доработка. Но в закладочки в любом случае надо положить :)

Фундаментальные знания

И снова пост из разряда "размышлений на тему". В любой области есть такая проблема, что знания могут стать не актуальны и невостребованными рынком. Технологии умирают, что-то устаревает и т.п. Юнити пока это конечно не грозит, но думаю что когда кто-то начинал изучать Action Script 3 и подумать не мог, что его убьёт HTML5 (но это не значит, что за убийства флеша можно простить! Помним! Скорбим! Не простим!) Поэтому работа в IT это путь постоянного обучения. При этом очень важно актуализировать знания. И где-то тут по тексту мне уже кажется должна быть реклама какого-то курса, но нет) Да и я не хочу пока в этом канале рекламу делать XD

Есть одна абсолютно не устаревающая вещь. Фундаментальные знания. Почему любой Senior разработчик в среднем легко сможет перескочить с технологии Х, на технологию Y? Будет плеваться конечно, но перескочит) Потому что в программировании суть везде одна, меняется чуть-чуть синтаксис, где-то инструменты удобнее (привет джавистам от .Net разрабов), где-то чуть сложнее, так как придётся вникнуть в другую парадигму. Но всё программирование по сути сводится к простой фразе. Программирование — это превращение одного представления данных в другое представление данных посредством серии обработок :) И так по сути можно описать любую программу. Поэтому фундаментальные вопросы архитектуры, простоты, чистоты кода не меняются в зависимости от технологии. И лучше учить их, чем конкретику фреймворков. Конкретику и нюансы фреймворка надо знать только в том фреймворке, в котором ты работаешь. Я просто встречал ребят которые знают миллиард фреймворков, но по сути про программирование не знают ничего (а тут стоит передать привет части фронтендеров)

Чем же прикольны вузовские знания? Многие говорят, что они устарели, что то что проходят в вузах уже не нужно в реальности, так как технологии обновляются быстрее, чем университетские программы. И это так) Но лишь наполовину. Если брать конкретные прикладные технологии, конкретные языки и т.п. в вузе иногда преподаётся что-то древнее. У когда я учился у нас преподавали: C++ — который в целом ой как не скоро можно будет назвать "устаревшим", но у нас преподавали какой-то древний стандарт), Ассемблер — который полезно знать для понимания работы ПК и больше ни за чем и собственно Action Script 3. Но помимо прочего на парах рассказывали про ООП (который не меняется уже хз сколько лет концептуально), про паттерны, про классы, объекты и т.п. И да, конечно я понимаю что можно было в курсе сделать лучше, спустя 10 лет программирования, но оглядываясь назад по той же теории баз данных и прочим вещам нам давали неплохую фундаменталку. Так как ну модель OSI и теорема CAP так же особо сильно не меняются со временем)

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

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

Стоят студенты и курят. И у них спрашивают:
- Hу как, мужики, за сколько сможете китайский выучить?
(Студенты) - А методичка есть?
- Да, есть.
(Студенты) - Hу сейчас докурим и сдадим!

Туториал по симпатичному дождю в 2д в Unity. Просто и со вкусом по сути по работе с партикл системой )

https://www.youtube.com/watch?v=fpGMz5Ia0XM

Классный репозиторий по переводу glsl шейдеров в shaderlab юнити :) Работает не идеально и пишет прям много лишнего, но упрощает работу по переписыванию до "отрезать лишнее" :) https://github.com/pema99/glsl2hlsl

Советы по работе с префабами в Unity

https://habr.com/ru/post/687416/

Давно я не выпускал статей и вот дошли руки написать о том, о чём больше нельзя молчать! Может кому-то пригодятся мои мысли, соображения, опыт и советы на эту тему :)

Пошумим?

Если вы работаете с графикой, то все виды шумов должны быть вашими лучшими друзьями. Я делал очень много различных эффектов основываясь чисто на шуме перлина. По этой причине очень важно напомнить про keijiro сана и про его репозиторий, который лежит теперь удобно пакетом в registry https://github.com/keijiro/NoiseShader

Рекомендую добавить себе в закладки, запомнить что он есть и пользоваться. Волны делаются шумом, прикольные абстрактные формы делаются шумом. Надеюсь скоро наконец-таки зарелизится один проект, и я смогу показать какую ещё симпатичную штуку можно сделать с помощью шума. Как пример интересных работ, как шумом перлина дистортится пламя https://www.graphicon.ru/html/2008/proceedings/English/S8/Paper_3.pdf :) В общем если заниматься VFX в шуме лучше разбираться)

Вообще надо всё же собраться с силами и написать большую обзорную статью про шум и его применения. Так сказать с чем его готовят) Но сейчас пока и так слишком много дел на сентябрь)

Значит хотел с утра начать писать систему для визуализации графов для статьи по графам. Чтобы загрузить какой-то графовый датасет и показать как там можно визуализировать) Оптимизации и т.п. С демкой в WebGL)

Но сделать же нужно нормально, поэтому я закопался в рефлексию и парсинг CSV с ней. Чтобы система не была заточена прям под конкретный граф, то пришлось написать конструкцию, как на скрине, чтобы элегантно пробрасывать маппинги) Видимо статья будет ещё про подходы к асинхронности на вебгл (такси там юзать as is нельзя, проще на корутинах делать) и ещё примером того, как можно обращаться с рефлексией) Ну либо надо будет один репозиторий использовать, как иллюстрацию для пары статей/постов, когда я допишу этого монстра)

Начал я с утра писать проект по графам XD

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

Unity написали небольшую статью в блоге «как сделать свой кодстайл») Больше кодстайлов богам кодстайлов :) https://blog.unity.com/technology/clean-up-your-code-how-to-create-your-own-c-code-style

Интересное видео про рекурсию https://www.youtube.com/watch?v=ngCos392W4w

FFT

Быстрое преобразование Фурье — это основа, это знать надо. Я нашёл довольно интересный видос про него https://www.youtube.com/watch?v=h7apO7q16V0 Но вообще это алгоритм который советую изучить в вкурить каждому, так как имеет очень широкий спектр применений) Ещё тут можно почитать статью про него https://towardsdatascience.com/fast-fourier-transform-937926e591cb

Как несколько примеров:

Сжатие изображений https://www.youtube.com/watch?v=gGEBUdM0PVc
Суммирование и фильтрация сигналов https://www.researchgate.net/figure/Fourier-transform-of-a-sum-of-sinusoids-and-filtering-the-highest-frequency_fig3_237061998
Поиск размылия на картинке https://pyimagesearch.com/2020/06/15/opencv-fast-fourier-transform-fft-for-blur-detection-in-images-and-video-streams/#:~:text=The%20Fast%20Fourier%20Transform%20is,mathematics%2C%20science%2C%20and%20engineering.
И ещё несколько https://www.quora.com/What-are-some-applications-of-2D-FFT-for-image-processing-computer-vision-computer-graphics

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