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

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

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

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

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

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