Зато я точно понял как работает размытие Гаусса

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

Но бусти надо честно отрабатывать. Так что быстрый OutlineGlow не за горами. По сути плагинами для подписчиков я выложу то, что мне и в проекте пригодится. Просто оформлю так, чтобы это были удобные самостоятельные модули. Так что это у нас будет подсветка объектов, верёвки разрубаемые свайпом и динамический 2д свет способный отражаться.

Но раз уже подписчики появляются, подсветку хочется выложить завтра. Не заставлять же первых поддержавших людей ждать :)

P.S. Гаусс в целом не самый быстрый. Да и шейдер графом, учитывая его логику самплирования и "смещения от центра", без циклов собирать такое скорее забавно. Но я вспомнил ещё пару техник. Буду сегодня тестить.

#интересное

Продолжаю мучать Glow Outline

Обожаю вспоминать про разные оптимизации юнити. Где-то час я не мог понять что происходит с альфой. Я перепробовал разные варианта её расчёта, но в итоге всё равно получалась ободка с разными артефактами. Альфа обрезалась. И я не мог понять почему. Вот что значит пару лет почти не трогать SpriteRenderer.

А потом я вспомнил. Там же не Quad. там меш, который генерится и это оптимизация. На мобильный платформах, особенно на андроид, всегда была проблема с альфа блендингом при множестве слоёв, если есть много лишней альфы. Я с этим сталкивался ещё в 2015, когда работал над проектом Vector 2.

Хорошо, что в настройках Sprite есть ползунок ExturdeEdges. Он решает эту проблему, и нужно просто будет написать про это в документации. А на видео слева спрайт, справа квад.

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

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

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://t.me/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 данный ассет можно получить бесплатно. Вдруг кому-то пригодится.

#интересное