Unity собирается закрыть Unity Answers

Как сделать скандал на ровном месте? Убрать инструмент у которого есть комьюнити и которым пользуются все. Unity недавно объявило, что они собираются закрыть Unity Answers, так как он не пользуется особой популярностью. Хотя многие им пользуются думаю каждый день. В итоге вроде они дали заднюю, и решили повременить с этим великолепным решением

Изучив всё по теме, чем обосновано решение. Так как моя первая мысль была "Маленькой инди-компании жалко баксов на хранение ДБ и доступа к ней?". Ладно режим ридонли с альтернативами лучше ещё можно понять. Но просто положить всю базу знаний собираемую комьюнити годами. Это уровень. Даже для Unity. Причины, что эта штука базируется на легаси платформе, которую сложно поддерживать, и что мало кто сейчас отвечает на вопросы на сервисе. Но из-за этого класть огромную базу знаний — это уровень

Вроде как получив кучу хейта ребята дали заднюю и пока думают дальше. Так как если они его всё-таки просто положат и вопросы перестанут индексироваться — ну это прям "со дна постучали". Больше всего мне понравилась в ветке шутка про "Unity убивает Unity Answers", "Unity открывает платное вики с доступом по подписке")

Я пока в запаре, так что не успеваю что-то новое писать сюда) Ноооо скоро я разгребусь и вернусь. Честно-честно. Просто запуск нескольких проектов, миллиард дел, а ещё книгу нужно таки дописать, а то с меня её скоро спросят XD

А пока могу посоветовать почитать блог моего бывшего комрада по вектору 2 и в целом крутого левел дизайнера https://news.1rj.ru/str/vskobelev Если интересуетесь левелдизайном, то думаю он вам будет полезен, как минимум со статьями на хабре я бы рекомендовал ознакомиться точно. Да и если просто интересуетесь играми, то вам думаю тоже будет интересно :)

А я скоро вернусь и если соберусь с силами, то первую статью из цикла уже завтра выложу :)

Каустика

Довольно забавный эффект про которые написано куча статей, одна из моих любимых по простейшей реализации https://www.alanzucconi.com/2019/09/13/believable-caustics-reflections/

Для разминки написал подобную версию, которая чуть-чуть более логична, так как использует не uv, а мировые координаты и ложится на поверхность как бы сверху + на URP и шейдер графе. Мало ли кому-то пригодится)

Шейдертой

Один из неплохих способов разобраться в шейдерах, ковырять чужие шейдеры. И для этого есть неплохой ресурс — https://www.shadertoy.com

Он не единственный, но и там огромная коллекция интересных шейдеров. Написаны они правда на glsl, а шейдерлаб Unity используют hlsl. И часто написаны не очень хорошо, но эффекты там всё равно красивые и можно вдохновится интересными эффектами и посмотреть разные подходы)

Кроме того есть классный проект переводящий шейдертой шейдера в шейдеры для Unity https://github.com/smkplus/ShaderMan Он позволяет на основе шейдера из шейдертоя сгенерить шейдер для Unity, что бывает полезно. В общем советую попробовать поделать на основе шейдеров с шейдертоя поделать свои эффекты, пооптимизировать описанные там. Да и в целом иметь на вооружении при работе всю библиотеку шейдертоя бывает очень полезно :)

Хороший старый доклад с Unite по оптимизации в графике https://www.youtube.com/watch?v=JUiO64KbAHA

Оптимизации — дело тонкое

На Unite в целом много крутых докладов, которые стоит посмотреть. Вот ещё один из них https://www.youtube.com/watch?v=oatF8e_PPh0 Оптимизации дело тонкое, потому что если хочется добиться графики мирового класса, то нужно оптимизировать всё в контексте проекта. Никакие общие решения и техники не дадут аналогичных результатов в визуале никогда. У вас изометрия, глупо использовать 3д. У вас 3д, но с фиксированными пролётами камеры — есть тоже ряд техник. У вас используется блюр, его можно красиво переиспользовать. У вас стилизация с фиксированным числом цветов, тогда по весу можно запихать в одну текстуру множество математикой. Техник и идей масса, и это ещё не беря что-то сложное, поэтому очень полезно смотреть доклады и учиться на чужом опыте. Причём даже не столько тому, а как у них сделано, а как нужно думать и какой логике рассуждений следовать оптимизируя тот или инной модуль)

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

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

Юнити такой движок, что помимо самого движка есть огромное число прикольных штук сделанных комьюнити. Одна из таких система воксельного света 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