Прикольные репозитории

Юнити такой движок, что помимо самого движка есть огромное число прикольных штук сделанных комьюнити. Одна из таких система воксельного света https://github.com/sonicether/SEGI Она конечно старенькая, но всё равно рекомендую поковырять она на билд ин рендере достаточно забавна :)

Прикольный список крутых VFX артистов :) https://80.lv/articles/real-time-vfx-artists-you-should-follow/?amp=1

Курсы и обучение новичков

Я тут недавно наткнулся на забавный ролик, где человек ругает курсы и всяких ребят на ютубе за говнокод, когда составляется туториал для новичка. Ну перед сном почему бы и не глянуть, что за пример хорошего обучающего кода там будет. Увидев его код я в целом закрыл ролик моментально. Пример плохого кода, конечно если такие прям есть в скиллбоксе — это печаль. Но я не думаю, что ребята оттуда делают Find в Update. Это единственное за что сильно зацепился взгляд)

Хороший код, а точнее так, действительно хороший код, требует понимания огромного числа концепций и опыта. Плохой пример был действительно плохой, но его можно довести до нормального. А вот хороший код не будет понятен ни одному новичку и учит плохому. И вот почему)

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

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

3. События. События — это тоже высокоуровневый концепт, который нужно долго пояснять человеку, который пока не до конца понимает концепции массивов, циклов, переменных, классов и т.п.

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

Прикольный репозиторий с системой для паркура https://github.com/knela96/Dynamic-Parkour-System

Интересный дайджест с настройкой погоды в игре https://80.lv/articles/creating-volumetric-clouds-modular-weather-and-cloud-shadows-in-unity/

Поговорим про работу с контентом

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

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

И есть 2 пути подготовки качественного контента:

Первый — у вас хорошие специалисты и вы им доверяете

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

Второй — у вас есть грамотный продюсер или артдиректор

За 5 лет было много разных проектов. Я работал с людьми разного уровня, так как постоянно кого-то привлекаю к проектам в качестве фрилансеров. И если вы можете чётко до буквы объяснить задачу — с ней справится даже джуниор специалист. При этом качество от этого особо не прострадает. В работу экспертов не должны лезть непрофильные специалисты. Вроде бы простое правило, но многие почему-то этого не соблюдают. Тут у контент команды остаётся творчество в качестве придумывания форм для решения задачи и т.п. Но грамотно поставленная задача, составленный мудборд и рефы — это действительно половина решения задачи

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

Сделал генератор шаблона Unity пакета


https://github.com/Nox7atra/UPTG — так как я периодически выкладываю в опенсорс всякие инструменты и библиотеки свои, и так впадлу каждый раз создавать руками кучу файлов. Так как Unity в мануалах предлагает делать это руками. Написал компактный генератор всего что нужно. Забиваем данные, выбираем туглы и т.п. Надо будет на досуге добавить защиту от дурака с версиями, просто сейчас лень писать регулярку формата x.x.x а без них пакет не будет качаться + надо сделать версию обязательным полем и в целом протестировать, какие поля в пакетах обязательные

Как говорится может кому пригодится — пользуйтесь. Чтобы не делать это всё в ручную

Астрологи объявили неделю полезных ассетов

Чёт напало на меня желание поделать на выходных какие-нибудь полезные штуки. В вот вам ещё репозиторий :) Вас когда-нибудь бесило, что вы в какой-то анимации не можете поменять иерархию или переименовать объект в Unity? Вот меня очень часто. Особенно когда скажем в UI сделаешь какую-то сложную анимацию, композицию анимаций делать не хочется, но иерархию менять — это прям боль, там 5 объектов, заранее не подумал что они могут хотеть двигаться вместе. Из недавних прям таких кейсов, у меня была инфографика, а потом мне потребовалось плавно к ней вести линию соединения. И увидев, что мне нужно либо переносить ключи в 5-ти местах, либо делать ещё одну анимацию с уже внешним контейнером, я решил написать небольшую тулзу

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

Работает как-то так)

Красивая штука) https://www.youtube.com/watch?v=-t0fH4CH0V4

Классный эффект :) https://80.lv/articles/bloodborne-s-moonlight-sword-made-with-maya-unity/

Отличная статья про GPU Instancing https://catlikecoding.com/unity/tutorials/rendering/part-19/Rendering-19.pdf

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