Последние пару дней у нас в чатике обучения обсуждалась новость про уязвимость в юнити, о которой сообщили разрабы движка, решил оповестить тут на всякий случай:)

❗️ В Unity была найдена уязвимость системы обработки файлов, позволяющая загружать вредоносный код в билды игр на Android, macOS, Windows и Linux! Проблема затрагивает все версии Юнити, вышедшие за последние 8 лет, начиная с Unity 2017.1.2p4.

➡️ Третьего октября Unity Technologies разослали пользователям электронные письма с информацией о найденной уязвимости. Компания советует разработчикам срочно загрузить новый релиз редактора Unity подходящей версии, где дыра уже была залатана. Из-за серьёзности проблемы было решено выпустить обновление безопасности даже на версиях движка, поддержка которых была прекращена, вплоть до 2019.1. Для уже выпущенных игр был представлен инструмент для внедрения патча напрямую в бинарные файлы игры.

🔔 Больше информации о проблеме, а также полный список версий, где уязвимость была исправлена, можно найти в посвящённой ей статье на официальном сайте Unity.

p.s. добавлю, что глобально для ваших пет проектов или каких-то небольших выпущенных игрушек особо опасности никакой нет, т.е. можно спокойно просто обновить версию движка и работать дальше ни о чем не переживая. Однако, если у вас есть проект с большой аудиторией, то стоит обеспокоиться и выкатить апдейт билда по быстрее)

Недавно у моего знакомого вышел долгий и довольно подробный ролик на тему генерации 3д ассетов с помощью нейронок

Решил поделиться с вами, возможно многим программистам/не художникам будет полезно для своих проектов. Сам сильно в подробности не вдавался, но судя по результату можно неплохого качества лоу поли пропсы и прочие подобные ассеты делать без участия художников, что звучит довольно неплохо)

🔣 Ссылочка на видосик

🧐 Кстати как относитесь к генерации графики/ассетов нейронками?) Используете для этих целей или ну его?))) Пишите в комменты свой опыт:)

#ПриветИзПрошлого

Тестируем новую рубрику с фактами из темного прошлого юнити... Ну или не очень темного:) Поставьте 🔥 если нравится такая идея:)

Взгляните на вот такой интересный пример реализации базового передвижения персонажа в Unity!

Да это юнити:) Вопрос "С каких пор Юнька перешла на Python?!" отложите в сторону. Здесь всё гораздо интереснее!

ℹ️ Перед вами находится программа, написанная на Boo - нишевом питоноподобном скриптовом языке, про который сегодня успели забыть даже его создатели. Тем не менее, приведённый код действительно рабочий, и вы спокойно можете использовать его в своём проекте... если, конечно, по какой-то причине не обновляли движок дальше версии 2019.1.0b9

➡️ С момента своего появления Unity пытался быть максимально доступным для разработчиков любого уровня - настолько, что на протяжении более чем десяти лет позволял писать скрипты аж на трёх языках на любой вкус и цвет: C#, UnityScript и Boo.

👩‍💻 Шарпы, надеемся, в представлении не нуждаются
👩‍💻 UnityScript, по сути, был статически типизированной вариацией JavaScript (И, заметьте, за долгие годы до появления всеми любимого сегодня TypeScript! Гордитесь!)
👻 А Boo... он хотел быть таким же быстрым и надёжным, как С#, но при этом оставаться максимально простым для изучения и использования, как Python

⚡️ Подобно остальным языкам, Boo был статически типизированным решением, интегрированным в .NET и Mono. Но, в отличие от C# и UnityScript, он не мог похвастаться ни вниманием со стороны разработчиков движка, ни тесным сообществом вокруг себя. В то время Python и близко не был настолько популярен, как сегодня, поэтому мало кто решал выбрать этот необычный язык, имея более понятные и знакомые альтернативы. Не помогало и отсутствие должной поддержки со стороны самой Unity Technologies. Документация к движку практически не содержала примеры кода на Boo, отдавая приоритет C# и UnityScript, что не способствовало улучшению позиций первого.

📉 Cудьба Boo оказалась предрешена. В 2014 году его поддержка в Unity была прекращена из-за слишком малой базы пользователей. Со временем все упоминания языка были окончательно вытеснены из документации и панелей интерфейса, а в 2019 компилятор Boo и вовсе удалили из файлов движка. А жаль. Возможно, сейчас, когда Python становится первым выбором для многих новичков в IT, питоноподобный скриптовый язык с призраком на логотипе мог бы очень сильно пригодиться нашему любимому движку...

вот такой сегодня #ПриветИзПрошлого

✨ Новые лайфхаки!? ✨

Сегодня будет длинно, но интересно...)
Ставьте 🔥, если поддерживаете длинные постики, мне нада знать стоит ли оно того:)

🧐 Кто помнит историю с Yandere Simulator?) Игры, разработчик которой настолько... своеобразно программирует, что в какой-то момент обнаружилось: практически весь его проект работает на километровых цепочках if-else, из - за чего поддерживать проект становилось совсем невозможно, разработчики бежали, проект сыпался... А вот если бы он использовал switch case...

Тооо ничего бы не поменялось, так как архитектуру проекта это не исправит, нооо возможно код был бы чуточку симпотнее)

Так что предлагаю познакомиться с парой плюшек, связанных с этой конструкцией:)

Начиная с C# 7, switch-выражение умеет работать не только с конкретными значениями, но и с диапазонами. Всё, что нужно сделать - поставить между ключевым словом case и значением знак сравнения >, <, >= или <=!

private const int CriticalDamageThreshold = 10;

private void HandleDamage(int amount)
{
    switch (amount)
    {
        // "Поймает" значения ∈ [10; ∞]
        case >= CriticalDamageThreshold:
            Debug.Log("Critical damage!");
            break;

        // "Поймает" значения ∈ (0; 10)
        case > 0:
            Debug.Log("Damaged!");
            break;

        case 0:
            Debug.Log("Miss!");
            break;

        default:
            throw new ArgumentOutOfRangeException($"{amount}");
    }
}

Поддерживаются и комбинации нескольких сравнений сразу - нужно только написать их через специальные операторы or...

case > 1 or < -1:
   // Делаем что-то
   break;

...или and...

case >= 0 and < 10:
   // Делаем что-то
   break;

Но что делать, если порог CriticalDamageThreshold не константен, а подсчитывается динамически или настраивается геймдизайнером через Инспектор? В таком случае, switch не позволит вставить поле напрямую в диапазон case'а!

Тут на помощь приходит ключевое слово when, которое позволяет работать и с не константами. С ним мы можем закешировать наше значение в переменную - а уже её спокойно запихивать в любые операции, возвращающие булевое значение.

[SerializeField]
private int _criticalDamageThreshold = 10;

private void HandleDamage(int amount)
{
   switch (amount)
   {
      case int damage when damage >= _criticalDamageThreshold:
         Debug.Log("Critical damage!");
         break;

      // <...>
   }
}

Выражения после when называются case guards и позволяют добавлять условия любой комплексности, которые должны выполняться, чтобы конкретный кейс свича "поймал" значение. Таким образом одни и те же данные можно заставить попадать в разные части switch-конструкции в зависимости от конкретных обстоятельств, что здорово прокачивает гибкость кода в конкретных моментах.

Честно скажу, на практике такое использую редко, уж больно замароченно выглядит это дело, но фишка интересная:)

Кстати, это еще не все фокусы со свитчом, так что ставьте 🔥 если хотите видеть еще #лайфхаки на канале

Решил немного обновить навигацию по каналу (сообщение в закрепе) :)

Как оказывается действительно многие пользуются подобным функционалом, поэтому в будущем буду более строго относиться к разбиению постов на хэштэги/рубрики, да и наверное по старым постам в скором времени пройдусь, тоже проставлю, если сил хватит:)

🙃 А вообще как у вас дела? Как двигаются проекты/обучение?)

В прошлом посте про #лайфхаки в C# мы разобрали, как можно удобно работать с диапазонами и комплексными условиями в switch-case конструкции. Вы поставили много 🔥, и это не осталось незамеченным! Так что сегодня продолжаем разбираться с интересными свойствами свича! 😎

✨ Итак, у нас есть Юнити-приложение с внутриигровыми покупками. Мы выпускаем наш проект сразу на трёх платформах: в Play Market, в AppStore и в Стиме для Windows и macOS. У каждой из площадок - своя система обработки покупок, поэтому мы создали общий интерфейс IPurchaseService, к которому обращаемся в коде, и написали три отдельные реализации под каждый из магазинов приложений. Теперь нам остаётся только проинициализировать правильный сервис при запуске игры.

Ну и, в целом, switch-конструкция выглядит тут неплохим решением:

RuntimePlatform currentPlatform = Application.platform;
IPurchaseService purchaseService;

switch (currentPlatform)
{
   case RuntimePlatform.WindowsPlayer:
   case RuntimePlatform.OSXPlayer:
      purchaseService = new SteamPurchaseService();
      break;

   case RuntimePlatform.IPhonePlayer:
      purchaseService = new AppStorePurchaseService();
      break;

   case RuntimePlatform.Android:
      purchaseService = new PlayMarketPurchaseService();
      break;

   default:
      throw new Exception($"Unsupported platform: {currentPlatform}")
}

...и, вроде, всё работает, но создаётся явное ощущение, что для такого простого действия получилось многовато словесного шума.

❓ Нет ли варианта лаконичнее?

✔️ Конечно же есть! С выходом C# 8 в языке была представлена новая фича - switch expressions. Она даёт знакомой нам конструкции непривычный краткий синтаксис следующего формата:

%имя_значения% switch
{
   %кейс1% => %возвращаемое_значение%,
   %кейс2% => %возвращаемое_значение%,
   // <...>
   _ => %дефолтное_возвращаемое_значение%
};

То, что свич-выражение вернёт как результат своей работы, можно будет сохранить в переменную или передать куда-то ещё. Самое то для нашего случая!

После рефакторинга получается такое:

// Статический импорт значений enum для краткости.
// Трюк выполнен профессионалами. Не повторяйте в жизни!
using static UnityEngine.RuntimePlatform;

// <...>

RuntimePlatform currentPlatform = Application.platform;

IPurchaseService purchaseService = currentPlatform switch
{
    WindowsPlayer => new SteamPurchaseService(),
    OSXPlayer => new SteamPurchaseService(),
    IPhonePlayer => new AppStorePurchaseService(),
    Android => new PlayMarketPurchaseService(),
    _ => throw new Exception($"Unsupported platform: {currentPlatform}")
};

...и, вроде, уже все выглядит на порядок лучше, но как-то нехорошо смотрятся WindowsPlayer и OSXPlayer, которые пришлось прописать как два разных кейса, хоть они возвращают одно и то же. Но и это можно исправить при помощи контекстного ключевого слова or, о котором мы уже говорили в прошлый раз!

WindowsPlayer or OSXPlayer => new SteamPurchaseService(),

Диапазоны и другие ключевые слова, вроде and, when и отрицания not, тоже поддерживаются, так что в гибкости работы switch expressions ничем не уступают обычным свичам:

int healthPerCents = GetHealthPerCents();

CharAnimation animation = healthPerCents switch
{
   100 => CharAnimation.Normal,
   >= 25 and not > 100 => CharAnimation.Hurt,
   > 0 and not > 100 => CharAnimation.CriticalState,
   0 when _timeForReviveSeconds > 0 => CharAnimation.Dying,
   0 => CharAnimation.Dead,
   _ => throw new Exception($"{healthPerCents}")
};

Такая вот сегодня вышла switch-фишечка. Но и это ещё не всё, что умеет данная конструкция! В запасах лежит ещё одна маленькая интересность, которая иногда очень пригождается в проектах. Интересно о ней узнать? Ставь 🔥, и все будет в заключительном посте на эту тему!))

И снова всем #ПриветИзПрошлого!)

А вот вам ещё кусочек необычного кода, который реально работал в Юньке!

➡️ В прошлом посте про старый Юнити мы обсуждали, что раньше можно было писать скрипты аж на трёх языках. И если один из них - Boo, - оказался почти никому не нужен и вскоре забыт, то второй, - UnityScript, - зашёл немалому числу людей, и долгое время был настоящим конкурентом C#.

⚙️ И это не удивительно. Boo интегрировали в Юнити чисто "чтобы был". Создателя языка просто наняли в штат компании, и он как-то там поддерживал своё детище на фоне. А вот UnityScript разрабатывали самостоятельно, эксклюзивно для движка, поэтому этот язык умел некоторые штуки, о которых даже современный C# может только мечтать.

💡 Например, в скриптах было необязательно писать класс - просто лепи код, как есть, а движок сам поймёт, что нужно отнаследоваться от монобеха. А ещё все сущности, написанные на этом языке, сразу умели отображаться в Инспекторе, потому что аттрибут [System.Serializable] применялся к ним автоматически.

ℹ️ Само название UnityScript намекает, что его основные идеи нагло спёрли подсмотрели у JavaScript. Даже файлам с кодом оставили расширение .js, из-за чего некоторые начинающие разработчики игр потом искренне верили, что именно так и выглядит ДжаваСкрипт - с классами и статической типизацией 😂

📉 К сожалению, хоть этот язык и шёл гораздо лучше Boo, в итоге они разделили одну судьбу. Со временем разработчики всё больше склонялись в сторону C#, считая, что альтернативы - ерунда и детский лепет. В итоге Unity Technologies объявили, что и Boo, и UnityScript будут полностью удалены из движка.

📊 И пусть на тот момент меньше 3% всех проектов использовали UnityScript как основной язык, всё равно в каждой пятой игре, сделанной на Unity, был хотя бы один .js-файл. Поэтому, в отличие от Boo, нашего героя не забыли полностью. Более того, именно из-за него по сей день некоторые новички верят, что в Unity можно писать код на ДжаваСкрипте... или вообще на Java))

А ещё ходят слухи, что где-то в тёмных подвалах разработчики до сих пор поддерживают старые игры, написанные на UnityScript...

А вы встречали UnityScript в проектах? 🧐 Пишите в комментариях и ставьте 🔥 , если хотите узнать больше о старой Юньке!

Недавно мы с вами уже рассматривали интересности из старых версий движка. Но и в настоящем есть, что посмотреть, так что сегодня тестируем рубрику, в которой будем рассказывать, #ЧтоНового крутого появилось в новых релизах Юньки!)) Поддержите 🔥, если хотите ещё таких выпусков!

Запекать красивый свет никогда не было так просто, как в Unity 6!

💡 Свет - невероятно мощный инструмент, который может в корне преобразить визуал игры и бесконечно радовать глаз игрока. А запекание освещения заблаговременно, на этапе разработки, позволяет всей этой красоте ещё и не нагружать устройство пользователя расчётами в реальном времени.

✨ Если какие-то объекты на сцене статичны, значит, падающий на них свет и отбрасываемая ими тень не будут меняться в процессе игры, так что, вместо того, чтобы просчитывать их каждый кадр в рилтайме, можно сделать это единожды заранее и записать все затемнения и засветы прямо в текстуры сущностей.

❓ Но что делать с динамичными объектами? Ведь вшивать в связанные с ними материалы данные освещения явно не стоит, а то игрок очень удивится, когда сломает ящик, а тень от него останется на стене 😄

⚡️ Для решения этой задачи в Unity давно существуют так называемые Light Probes. Они работают по прямо противоположному принципу: запоминают степень освещённости не на поверхностях, а на пустых пространствах вокруг себя. Впоследствии, если в зоне их действия появляется какой-то объект, движок не тратит время на раздумья "как сильно нужно освещать эту сущность," а просто вытаскивает из лайт пробы заранее просчитанные значения для этого куска сцены и применяет их во всех нужных местах. Удобно! Но не совсем. Объективным недостатком технологии Light Probes является необходимость вручную расставлять их в нужных местах. Этот процесс довольно кропотливый, да ещё и приходится повторять его каждый раз, когда архитектура сцены изменяется.

💥 В Unity 6 и эту проблему постарались решить! На одной из презентаций была представлена новая технология - Adaptive Probe Volumes (APV). Идея проста: нажмите одну кнопку, и движок расставит Light Probe-группы за вас, основываясь на источниках освещения сцены и её архитектуре! Более того, в целях оптимизации APV по-разному распределяет пробы на каждом конкретном участке локации. Чем сложнее архитектура сегмента, тем кучнее группы Light Probe'ов будут расположены. И наоборот - там, где толком ничего нет, много лампочек пихать не будут. Незачем.

✏️ Чтобы использовать Adaptive Probe Volumes в URP- или HDRP-проекте на Unity 6 или выше, открываем ассет нашего пайплайна и в поле Lighting > Light Probe System переключаем "Light Probe Groups" на "Adaptive Probe Volumes". Далее в окне глобальных настроек освещения (Открывается на Ctrl+9) на вкладке Scene выключаем флаг Realtime Global Illumination, если он включён, и нажимаем Generate Lighting в нижней панели. После этого группы Light Probes должны сгенерироваться для всех Baked- или Mixed-источников освещения. А посмотреть, как эти группы расставило по сцене, можно, включив флаг Probe Visualization > Display Probes в дебаггере рендеринга (В верхней панели выбираем Window > Analysis > Rendering Debugger, вкладка Probe Volumes).

ℹ️ Стоит отметить, что технология ещё молодая и требовательная к настройке проекта, поэтому на некоторых сценах может сбоить и ставить отдельные лайт пробы невпопад, а сами лампочки иногда просвечивают между стенами, если последние слишком тонкие. Но, уверены, в будущем это поправят, как уже довели до ума многие другие инструменты, без которых мы сейчас просто не можем представить работу в Unity. Да и уже сегодня эта технология выглядит очень многообещающе! 😎

Такая вот сегодня интересность о новом движке:) Делитесь в комментариях своим опытом использования APV и не забывайте про 🔥, если интересно узнать, #ЧтоНового ещё принёс нам Юнити шестого поколения!

Инспектор может больше, чем ты думаешь!

Полгода назад в одном из постов про #лайфхаки я уже рассказывал, что Юнька позволяет вставлять в float-поля не только стандартные значения, но и бесконечность. Однако тогда из финального текста пропал кусок с объяснением, как именно это можно сделать:)

Так что расскажу про такие возможности по подробнее)

Если вам временно нужно сделать бесконечным количество патронов или секунд в таймере, настраиваемом float-значением через Инспектор, не спешите лезть в код и переписывать логику. Просто напишите в нужном поле inf или Infinity, и Юнити автоматически подставит туда соответствующее значение.

Также можно получить отрицательную бесконечность, написав -inf или -Infinity соответственно, если вам вдруг это зачем-то надо.

А ещё таким образом можно вставить в float-поле число Пи (pi) и Not a Number (NaN). Конкретно это на практике не особо полезно, но прикольно же! 😎

Ну и фактик напоследок - Инспектор ещё и считать умеет! Если по заветам Сида Мейера захотите увеличить или уменьшить какое-то значение в два раза, не тянитесь за калькулятором. Просто введите в Инспектор математические выражения, и он всё посчитает за вас. Помимо базовых операций поддерживаются возведение числа в степень при помощи символа ^ и взятие квадратного корня через sqrt()

На сегодня у меня всё. Как всегда, если пост понравился, обязательно ставьте 🔥