URP Sprite Glow
https://dev-game.pro/demos/urp_glow_demo/

Доделано. Шустренький глоу для спрайтов на URP работающий с WebGL, да и где хочешь. Гауссом конечно можно сделать посимпатичнее, но будет дороже, и не шейдер графом. А хотелось, чтобы ассет было легко модифицировать. И чтобы был дешёвый по производительности. Без полноэкранных эффектов и тому подобного.

Демо работы можно глянуть по ссылке. Чуть позже почищу изображения от артефактов. Так как светятся ещё остатки тени под ногами вампира.

В общем и задачку выполнил по игре, так как глоу штука очень полезная для туториалов, да и для выбора перса (у меня же планируется point&click управление). И как ассет почти сделал. Осталось только сделать документацию, так как детали с альфой, с экструдом и так далее немного неочевидные на мой вкус. Напишу доку на неделе.

Да, если что исходники доступны для скачивания на бусти. Для второго уровня подписки и выше.

#индиприключения

Про многопоточность и асинхронность

Наткнулся с утра на заметку про многопоточность. Сама заметка мне не особо понравилась. Наверное в основном что там написано "для сеньоров". А для сеньоров она ни о чём, так что ссылку давать не буду. И тезисы из прилегающей к ней подборки статей — тоже. Напишу сам на ту же тему (не для сеньоров).

Многопоточность и асинхронность скажем многие путают.

Простым языком многопоточность нужна в задачах, которые в основном дают нагрузку на CPU. С планом на эксплуатацию в системах где у процессора много ядер (почти любая сейчас). Из плюсов, что в данном случае мы используем процессор максимально эффективно. Поэтому это требуется в CPU-bound задачах. В играх это у нас была бы физика (но есть PhysX), ИИ, генерация мира и иногда игровая логика.

Асинхронность — это последовательное выполнение операций. Оно работает в одном потоке (в контексте юнити логичнее всего что в главном). Асинхронность по сути переключается между задачами без блокировок не создавая новые события, а используя event loop. Чаще всего в Unity это корутины. Если вдруг вы по какой-то причине не знаете как устроен event-loop в Unity то вот ссылка. Как это работает не блокируя поток в корутинах? Создаётся список (а если быть точным итератор) операций, который исполняет операции разбитые yield-ами по ходу исполнения Unity Script lifecycle.

Многопоточность штука удобная. Но к сожалению не доступная из коробки шарповыми средствами для скажем WebGL проектов. Шарповый System.Threading и Unity Job System. Тем не менее в современном вебе есть Web Workers. Они не интегрированы в Unity, так как не поддерживают синхронизацию с главным потоком Unity и с DOM. И всё же через нативные js плагины их можно запускать. Если кому-то интересно, то могу как всегда за 🔥 написать пример использования Web Workers из Unity. На десктопе и мобилках всё работает хорошо. Нужно просто знать как избегать deadlock и race condition. Я обычно использовал её для всяких алгоритмах на графах. У меня был проект с укладкой графа в трёхмерном пространстве и вот она считалась в отдельном потоке.

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

1. Ад коллбэков

Глубоко вложенные коллбеки делают код нечитаемым и сложным для поддержки. Советую почитать про термин "Pyramid of doom" в программировании. И нет, вы что, программисты не любят драматизировать.

2. Сложность обработки ошибок

Ломаются трейсы, ломаются логи, нет единого места для трай кетча. Это всегда доставляет неудобства.

3. Инверсия контроля

Коллбэки нарушают линейный поток кода, передавая управление внешней функции. Из-за этого сложно отследить как и когда выполнится код.

Ну критикуешь — предлагай. Но всё уже предложили за меня. Мне в целом нравится UniTask. С ним довольно удобно работать. Тот же async/await подход. Удобный и понятный. Можно конечно пользоваться C# 7.0 async/await, так как в Unity уже давно есть .Net 4.0. Да и UniTask его вроде тоже требует. Так что главное преимущество корутин — это то, что они работают даже с .Net 3.5.

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

#интересное

Шейдерная магия в Unity: Красивая погода в играх
https://80.lv/articles/take-a-look-at-this-gorgeous-shader-based-weather-system/#conversation

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

#новости

Интеграция игр в React Native: боль, страдания и неочевидные решения
https://habr.com/ru/articles/917138/

Статья о подводных камнях интеграции Unity в ReactNative. О том что эмулятор не работает и остальных приколах. Что тут можно сказать?

Нативная интеграция нужна только для того чтобы иметь доступ к нативным технологиям ос устройства. Аркит, запуск ONNX моделей на устройстве и так далее. А для просто игровых механик я уже давно делаю веб для клиентов. Просто интегрируем игру в любое через веб вью. Этот подход в разы лучше.

Проще обновлять и поддерживать, не занимает вес билда. В среднем любое приложение и так требует доступа к интернету, так что это тоже можно не считать ограничением. Один из примеров проектов прошлого года что мы делали - игра для бетбума.

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

#новости #оработе

10 трендов мобильных игр в 2025
https://www.deconstructoroffun.com/blog/2025/6/5/the-state-of-mobile-gaming-2025

В статье The State of Mobile Gaming 2025 с сайта Deconstructor of Fun обсуждаются ключевые тенденции и изменения в индустрии мобильных игр к середине 2025 года.

1. Гиперказуал и гибриды – лидеры по доходам.
2. Растет подписочный гейминг (Netflix, Apple Arcade).
3. UGC-платформы (Roblox, Fortnite) набирают аудиторию.
4. Подписки и реклама вытесняют IAP.
5. Жёсткие законы против лутбоксов и данных.
6. AI в разработке – быстрый контент и тесты.
7. Меньше новых хитов – доминируют старые франшизы.
8. Web3-игры в упадке (кроме нишевых проектов).
9. Кроссплатформа – стандарт для топ-игр.
10. Китай остаётся ключевым рынком, несмотря на регуляции.

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

#новости

Как запустить Quest в РФ с помощью MacBook (и на что я убил 6 часов)

Купил Quest 2 давно, редко использовал. Решил обновить прошивку через ADB, так как стандартно не обновлялась. Но не знал, что после этого шлем нужно активировать заново. А в РФ это невозможно без VPN. Забил. А сейчас вдруг шлем понадобился по работе. Тут уже можно поразбираться. VPN на роутер настроить не вариант (а мой Microtik где-то в Москве). Появлялись съездить на такси в Абхазию — там вроде без блокировок. Но придумал кое-что удобнее :)

Решение:
1. Устанавливаем VPN на MacBook (у меня сработал третий из AppStore).
2. Подключаем iPhone с мобильным интернетом к MacBook.
3. В System Settings → General → Sharing настраиваем раздачу Wi-Fi через VPN.
4. Подключаем Quest к хотспоту — вуаля, активация проходит.

На что потратил 6 часов:
Пытался настроить Nekoray (альтернатива Shadowrocket для Windows).
- System Proxy не подходит — проксирует только процессы системы, не Wi-Fi.
- TUN Mode вроде бы то, что нужно, но запросы таймаутятся.
Три часа на Windows: чистил драйверы, настройки сети — безрезультатно.

Переключился на MacBook. Тот же Nekoray — та же проблема. Пробовал Shadowrocket для Mac:
- В обычном режиме не раздаёт Wi-Fi.
- В режиме туннелирования всего трафика ломается DHCP — Quest не подключается.

В итоге нашёл простой способ через стандартные настройки Mac.

ИИ не помогли (Perplexity, DeepSeek). Они ищут ответы, но не понимают, почему не работает то, что должно. Как с моим экспериментом, сказал я дипсику: "Напиши скрипт, который наденет клоунские маски на фото". Код он дал, но 40 минут ушло на борьбу с зависимостями (dlib, OpenCV). Без знаний Python и pip — ноль толку.

#оработе

*Meta Platforms Inc. признана экстремистской организацией в РФ, её продукты не имеют официальной поддержки.*

Как создают игры профессионалы: 5 личных правил от топовых гейм-дизайнеров
https://youtu.be/wjpMro-JnhI?si=zwaSk7ebiv7UzRYd

Классный ролик с GDC 2015 о важных вещах в геймдизайне. Я бы не назвал это поавилами или трюками. Скорее разбор геймдизайн концептов. А что за «правила»?


1. Создавайте эмоциональную связь

Классная часть ролика о том, что игры про эмоции. И том как можно создавать эмоциональную связь игрока с игрой. И почему это важно.


2. Видеть светлую сторону

Вообще забавно, что тут даже со знанием англиского мне потребовался переводчик, чтобы понять суть основного совета «Look for the silver lining». Забавный фразеологизм. Суть рассказа о том, как в условиях ограничений можно придавать шарм даже казалось бы «хреновым решениям».


3. Магия числа 3

Интересный рассказ о магическом числе 3 и почему оно так популярно в играх и не только.


4. Бейтесь за маленькие детали

О том как пасхалки, маленькие детали и элементы игры могут сделать игру запоминающейся.


5. Не пытайся оценивать свою собственную игру

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


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

#интересное

SharedLogic. Общий игровой код для Unity-клиента и .NET-сервера
https://habr.com/ru/articles/918220/

Забавный концепт. Любопытная статья. Лично я предпочитаю тонкие клиенты. Но почитать про другие подходы всегда любопытно.

Единственное что хочется добавить к словам автора, что у подхода всё же есть недостаток. Пресловутые версии. Когда игру надо обновлять, то сервер должен обновится вместе с игрой. При значимых изменениях. Особенно с проверкой хешей. В статье я инфы про это не заметил, но это проблема shared logic в микросервисной архитектуре. Просто менее ярко выраженная, так как в микросервисной мы попадаем в «ад dll или ад версий». Так как у нас куча сервисов должна использовать одну и ту же версию shared logic микросервиса. И как следствие обновляться вместе с ним.

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

1. Читерить может не так просто, а с пиратами что делать?
Имея все алгоритмы вычисления хешей на клиенте и всю схему апи,
мы просто берем всю логику игры с клиента и подменяем сервер зная всю логику валидации.

2. Да и читерить тоже можно
У нас все алгоритмы вычисления хешей есть на клиенте. Пишем бота декомпильнув проект, который будет без игры отправлять запросы в нужном порядке с вычислеными хешами.

По сути придумана специфичная соль для запросов при толстом клиенте. Звучит прикольно, подход имеет место быть. Но я всё так же буду предпочитать тонкие клиенты с правильно простроеной логикой обработки запросов.

Потому что скажем пример в статье про границы для постройки базы — это логика тонкого клиента. Бек вообще не знает про существование гуя и коллизий. А фронт у нас организован должен быть по принципам MVVM. Поэтому для проверки состояния можем ли мы тут построить на бек ходить не надо. Бек провалидирует эту инфу на этапе постройки, но для определения границ и окон без задержек достаточно информации на тонком клиенте.

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

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

#новости

Генератор карты в стиле Binding of Isaac
https://youtu.be/V9BODsU3QvU?si=qOWZ_WyB6fH4fxLI

В видео рассказывается алгоритм и его имплементация в Unity генератора игровой карты с комнатами где есть входы и выходы.

А какие например бывают генерации?

1. Разделение на комнаты (BSP/Voronoi) – уровни создаются через рекурсивное деление пространства (как в Binding of Isaac). Плюсы: чёткая структура, легко контролировать баланс. Минусы: может выглядеть шаблонно.

2. Случайные ветвящиеся пути (как в Hades) – игрок выбирает направление из нескольких вариантов. Плюсы: даёт ощущение свободы, динамичный геймплей. Минусы: требует ручной настройки весов комнат.

Такие генераторы полезная штука и концепция для метагеймплея того же рогалика. Вообще если уж я обожаю рогалики, вроде Monster Train, Ship of Fools и тому подобное, может и игру про вампира стоит сделать рогаликом. Основной плюс рогаликов это удержание и реиграбельность.

Надо подумать можно ли в базовую механику головоломки поверх накрутить рогалик логику. И чтобы я игру не 3 года разрабатывал. Но с головоломкой будто бы тяжело придумать достаточно перков. Это нужна механика игры со статами. Да и боссов делать тоже сложно.

В общем подумаю, но может оставлю это для какого-то следующего проекта.

#новости

Решил писать о геймификации
https://news.1rj.ru/str/dofamarket

Больше каналов богам каналов. По работе изучаю кучу кейсов, геймификаций, маркетинговых статей. Но чтобы блог личный не был "обо всём вперемешку" — начнём разбивать.

Завёл канал в котором буду писать про механики геймификации, системы лояльности и прочее применение игровых механик в маркетинге.

Что там будет? (рубрики)

🔹 “Механика дня” – разбор одной игровой механики (например, прогресс-бар в приложении, викторины, квесты).
🔹 “Кейс недели” – примеры успешного использования геймификации (Burger King, Starbucks, Nike).
🔹 “Тренды” – новые технологии (AR, VR, блокчейн-игры в маркетинге).
🔹 “Чек-листы” – готовые схемы для внедрения (например, “5 шагов, чтобы превратить скучный lead-magnet в игру”).

В общем если интересуетесь темой, то подписывайтесь. Я так мимо проходил рассказать, чем я ещё решил заниматься :)

#оработе

VFX Graph - Stylized Fire - Vol. 1 — Бесплатно
https://assetstore.unity.com/packages/vfx/particles/vfx-graph-stylized-fire-vol-1-207167?aid=1011l8NVc

Наткнулся на инфу что по промокоду GAP2025 данный ассет можно получить бесплатно. Вдруг кому-то пригодится.

#интересное

Как шейдеры оживляют цифровую ткань? Разбор симуляции
https://youtu.be/ms010Fz02wo?si=3ip2YCAsnrMgzm25

Интересное видео с разбором довольно простой реализации симуляции ткани. Вообще помню как мне кто-то рассказывал: «А ты никогда не замечал, что в играх и мультфильмах персонажи переодеваются за кадром?» Что анимация, что симуляция одежды это боль. А переодеть перса в кадре сверх дорогая задача.

Вообще забавно как часто бывает полезно представить какой-то объект или процесс множеством точек со связями и правилами на этих связях. Мой диплом звучал как «Применения метода конечных элементов в моделировании процесса волочения проволоки». И сам метод по сути про тоже. Есть точки, между ними силы и правила деформации. И с шагом мы симулируем что будет если приложить силу туда-то.

#новости

Стоит ли учить чему-то в Unity разработке?

Я почему-то всегда не ищу лёгких путей и не люблю заниматься "бесполезной" деятельностью. Уже несколько лет я задумывался на тему того, а стоит ли записывать условно курс по шейдерам? И условно геймдев то я всегда считал занятием "для энтузиастов" и как работа - точно не про деньги. Даже если сейчас посмотреть рынок труда, то на Unity 162 вакансии разработчика и с зарплатой до 3к$. А если мы посмотрим на Java, то вакансий 1400+ с зарплатой до 5к$. Что забавно исторические данные не найти, я даже задумался может парсер на хх повесить, который динамику будет собирать) Хотя если чему-то и учить в РФ с точки зрения "существования рынка труда", то из движков очевидно Unity, так как на анриале у нас 11 вакансий, а на Godot 2.

Это конечно не показывает ситуацию по indie разработке, так как наверняка есть много команд которые делают самое разное и довольно мелких.

И с одной стороны есть идеи что можно поделать. Например записать курс по компьютерной графике с шейдерами на Unity и рассказом о принципах работы ГПУ. Но я даже не знаю будет ли на это спрос. И даже если будет - а будет ли это не бесполезно купившим. К инфоцыганству я в целом отношусь негативно. Я недавно слышал что есть курсы "обучение нейросетям" со стоимостью 80к рублей в месяц. Крайне интересно было бы посмотреть программу этого курса, так как нейросети могут сами научить как ими пользоваться бесплатно.

Поэтому не хочется делать то что мало кому будет полезно в целом. Или что полученные знания после скажем довольно тяжело монетизировать. Хотя в игры и не идут обычно за деньгами, как показывает устройства рынка. За деньгами проще выучить Java SE :) Так что может я недооцениваю количество тех же "невидимых" инди и тех кто бы послушал про ГПУ скажем без применения этих знаний. Получается вопрос открытый.

#мысли

Математика в Gamedev по-простому

Чёт я заметил в обсуждениях последнего поста в чате канала, что я видимо не публиковал подборкой свои статьи про математику в геймдеве. И да как же неудобно в телеге, что у неё странная система работы комментов и они не крепятся к посту :)

Исправим это недоразумение. На сколько я помню это получилась обзорная серия, но вроде много кому понравилась.

Математика в Gamedev по-простому. Векторы и интегралы - https://habr.com/ru/articles/430146/
Математика в Gamedev по-простому. Матрицы и аффинные преобразования - https://habr.com/ru/articles/432544/
Математика в Gamedev по-простому. Триангуляции и Triangle.Net в Unity - https://habr.com/ru/articles/435374/
Математика в Gamedev по-простому. Кривые и рябь для эффекта дождя в Unity- https://habr.com/ru/articles/435828/

Сюда же на эту тему можно докинуть подборочкой мои старые статьи по шейдерам

Shader — это не магия. Написание шейдеров в Unity. Введение - https://habr.com/ru/articles/473638/
Shader — это не магия. Написание шейдеров в Unity. Вертексные шейдеры - https://habr.com/ru/articles/474812/

На эту серию я явно забил в какой-то момент.

Ну и докинем сюда просто по базе компьютерной графики.

Что такое тексел? - https://habr.com/ru/articles/714278/

Может кто захочет полистать на досуге.

#интересное