Григорий Дядиченко

Как две оптимизации могут испортить рендеринг: артефакты в HDRP
https://auzaiffe.wordpress.com/2026/01/10/sample-decorrelation-in-brdf-preconvolution-for-image-based-lighting/

Статья посвящена проблеме визуальных артефактов при реализации image-based lighting (IBL) в реальном времени. Автор, ранее работавший в команде HDRP в Unity, описывает проблему с появлением швов. Представьте ситуацию: вы собрали вместе несколько умных оптимизаций, каждая из которых отлично работает сама по себе, чтобы ускорить реалистичное освещение сцены. Но в сочетании они неожиданно начинают конфликтовать, и на текстурах появляются заметные швы. Это классический случай в разработке графики, когда стремление к эффективности приводит к новым визуальным артефактам, и решение проблемы заключается не в отказе от оптимизаций, а в поиске способа заставить их работать в гармонии, аккуратно настраивая их взаимодействие.

Статья довольно интересная. Хотя сам по себе баг почти никогда не приводит к визуальным артефактам. Но статьи про рендер полезно читать, чтобы понимать как он в целом работает и какие артефакты бывают.

#новости

Как создать деформации сетки в Unity — решение в 30 строках кода
https://80.lv/articles/neat-way-to-create-simple-mesh-deformations-in-unity

Разработчик Tomaso продемонстрировал простой способ создания деформаций сетки в Unity — объекты оставляют видимые вмятины с помощью смещения вершин при ударе и плавного снижения влияния. Деформация рассчитывается вне основного потока и применяется после завершения вычислений, что обеспечивает по словам автора высокую скорость и масштабируемость даже для больших сцен и множества жёстких тел и столкновений. Код можно найти на GitHub, там же есть другие интересные инструменты, например, для физики верёвок и тканей.

А теперь по факту. Решение неплохое, а репозиторий в целом любопытный, там помимо Light реализаций, есть реализация с компьют шейдерами. Симпатично, но есть несколько нюансов. И первое что бросается в Light версии:

Vector3[] baseVerts = (Vector3[]) deformedVertices.Clone();

Легкая реализация, отдельный поток ускоряет, но при каждой деформации мы в память выделяем массив вертексов 🙂 План надежный как швейцарские часы 🙂 Мне кажется тогда уж если морочиться с этой задачей лучше использовать либо unsafe, либо Span и джобы)

Ладно, допустим. Почему я когда-то бросил эту задачу и о чём не говорится в этой задаче? Ретопология. Тут же смещением вертексов эффект делается, а что если ваша геометрия это квад? Там нужно автоматически в точке применения силы перестраивать сетку. И вот это на самом деле дорого. Когда я делал порт Triangle.Net 4 года назад, я решал именно задачу деформаций. И прикол в том, что в реалтайме укрупнять сетку для деформаций довольно дорого. Поэтому все эти симуляции чуть чуть упускают контекст что геометрия у вас должна быть специфичной.

Не, если что репозиторий крутой и стоит поковырять, и автор молодец, достаточно хороший подход. Можно полезное почерпнуть, а в компьюте можно было бы усложить уравнение из идей метода конечных элементов и получить достаточно достоверную деформацию. Но что касается производительности, просто обратите внимание на память. И если разбираться будет лень, попросите нейросеть переписать блок с клонированием на zero-allocation вид. Думаю она справится. А в реальном применении вам ещё понадобится либо замучать кнопку subdivision в моделлерском софте, либо иметь под рукой алгоритм динамической ретопологии сетки.

#новости

Про цифры в игровой индустрии: Деньги которых вы никогда не увидите

Попытаемся ещё. Спишем не набранные огоньки на то, что я утром 1-го января решил писать про бизнес. Все только проснулись и отошли от боя курантов, а я проснулся и сразу про работу. А вообще нагоняйте друзей, что за дела 🙂

В прошлом посте была красивая картинка кто сколько зарабатывает. И что скажем 6% зарабатывает 5-10к$. Ну неплохая сумма, конечно вопрос за какой период времени. Но это доход, а вот как устроено всё на самом деле (и это довольно важно понимать и при подсчёте экономики проекта и при питчинге инвесторам) Ведь в доходе есть деньги которых вы никогда не увидите.

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

Пройдемся по ним. Вы продали копию своей игры за 1 000 рублей.

1. Комиссия магазина — первый и самый большой срез

Практически любая цифровая платформа берёт свою долю:

- Steam — 30% (снижается при больших оборотах)
- PlayStation Store / Xbox Store / Nintendo eShop — 30%
- App Store / Google Play — 30% (или 15% для малых студий)

Эти деньги не проходят через вас. Вы их даже не держали в руках. 300 рублей отдали, 700 рублей осталось.

2. Курсы валют и конвертация
Вы продали игру в долларах, евро, иенах.
Но:

- Банк конвертирует по невыгодному курсу
- Возможны дополнительные 1–3% потерь
- Курсовые скачки между датой продажи и выплатой

Откусим от 700 рублей ещё 21 рубль. Останется 689 рублей.

3. Налоги: деньги, которые были вашими… формально

После всех комиссий остаётся сумма, которая выглядит как «доход студии».
Но это ещё не ваши деньги.

Основные налоги:
- Налог на прибыль
- НДС / VAT (в некоторых странах — сразу при продаже)
- Налог на дивиденды (если вы выводите деньги себе)
- Социальные взносы, если платите зарплаты
В зависимости от страны итоговая потеря может составлять:

20–40% от того, что осталось после магазинов. То есть от 700 рублей осталось 300-550 рублей. Ну будем пока пессимистами. Точность уже можно получить для конкретной страны, льгот, проекта.

И на самом деле есть ещё несколько мелких подобных механизмов, но принцип понятен. Продали копию, нам дай бог осталась половина суммы. А если учесть что на рынке привлечение пользователя вроде стоило не менее 5-ти долларов, то с копии мы заработали дай бог 100 рублей.

Это нужно и полезно учитывать при планировании своей бизнес модели. Обычно можно ставить коэффициент денег, которых вы не увидите от 0.5 до 0.6 (учитывая ещё риски возвратов и чарджбеков) и вы редко промахнётесь. Игры весьма весёлый вид бизнеса.

Но если на этот пост не наберем 100 🔥 значит это всё же мало кому интересно, и про по-разному стоящее время и борьбу за снижение CPA я писать не буду 😆

#мысли

Coding Adventure: Анализ звука
https://youtu.be/08mmKNLQVHU?si=BxOmQZFGBvrs--re

Очень крутое видео про анализ звука, которое дает понимание о многих его аспектах. Сразу понятно как работают TTS системы и прикольная часть с «оставлять скрытые сообщения в аудио дорожках». Я обожаю подобные штуки.

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

Но на самом деле такого очень много. Определение движения сквозь стены по радиоэлектронному шуму вроде Wifi сигнала. И так далее, информации вокруг много и её можно учиться интерпретировать для разных задач. Когда я плотно занимался трекингом всего подряд, то конечно много удивительных вещей узнал. Саккады, логика работы с засветами, анализ магнитных полей и так далее.

#новости

LLM Отличная уточка

Если вдруг кто не сталкивался. Метод уточки (Rubber Duck Debugging) — это приём отладки, при котором вы вслух и максимально подробно объясняете игрушечной уточке (или любому другому неодушевлённому предмету) свой код, шаг за шагом описывая его логику и проблему. Проговаривая вслух каждое действие и предположение — структурируются мысли. Так можно замедлиться и рассмотреть задачу под новым углом, что очень часто приводит к самостоятельному нахождению ошибки или решения ещё в процессе объяснения.

А тут у нас у всех появилась личная уточка, которая ещё и вставляет свои 5 копеек. Но зато теперь этой старой методой пользуются очень многие.

#мысли

Мирза Бейг продемонстрировал новый шейдер для визуализации чёрной дыры
https://80.lv/articles/black-hole-visualized-with-unity-shader

Технический художник Мирза Бейг представил новый проект — шейдер, который позволяет визуализировать искажение, напоминающее чёрную дыру, и создавать завораживающие анимированные сцены. Ранее он демонстрировал другие шейдеры: для стекла, голограммы, визуализации моделей искривления пространства-времени в виде решётки, 2D-контура с эффектом свечения, а также шейдеры в стиле бабочки, VHS и кристалла, и механику сюрреалистичных порталов.

#новости

IL2CPP vs Mono. Что нужно знать?
https://researchandprogram.blogspot.com/2026/01/il2cpp-vs-mono-scripting-backend.html

Базовый ответ. Да ничего не надо знать о нюансах этих двух скриптинг бекендов. Статья обзорная и забавная, с симпатичными картинками. Если вы не в курсе что такое AOT и JIT — можно пролистать. И я согласен с автором, если вы хотите говорить про настоящую производительность, юзайте бурст :)

Для релизов используют IL2CPP, а для тестов моно :) Рассказ окончен :) Рендер разрабам до фонаря какой там скриптинг бекенд, разрабам бизнес логики это редкий проект, где вопросы производительности будут упираться в выбранный скриптинг бекенд. Эту область работы Юнити можно оставить загадочным черным ящиком и не потерять вообще ничего.

#новости

Нейросети, GUI и вообще

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

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

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

Очень важно приучиться с итерациями нейросетью часто коммитить. Так как часто хочется вернуться к прошлой реализации. Ну и последнее архитектурные паттерны. Недавно мне один блок написала система прям забавно. Есть контроллер, он связан с презентером, гуй дергает методы перезнтера, а он в свою очередь строить вьюмодель и отправляет на отрисовку. В одном модуле. Забавно. Но есть нюанс, если нейросеть просто придумала вам MVP, MVVM или что угодно, но вы не продумали нафига, вы начинаете либо (не понимая суть архитектурного паттерна) делать костыли. Либо натягивать сову на глобус, так как у вас же есть базовый паттерн архитектуры, вы его придерживайтесь.

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

#мысли

Небольшая заметка про нейросети

Так как мне становится всё больше лень заниматься рутинными задачами с одной стороны, а с другой стороны мне слишком впадлу подключать копайлот и другие спец. тулы. Я задачки пишу дипсику и ChatGPT.

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

ChatGPT пишет архитектурно лучше, но с загадками. Он сразу начинает от интерфейса (подход сначала пишем интерфейс в целом кайфовый). Декомпозирует, разбивает. Ток DI разве что не пытался делать. Мне нужен был функционал который запускает симуляцию, пишет отчёт, меряет производительность и так далее и архитектура которую предложил чат мне в целом понравилась. (Launcher, Runner, ReportBuilder, Context, Faccade) Особенно прикольно он реализовал фассад с передачей в него контекста. Это я даже потом в другом месте использовал. Единственное что он любит недоговаривать. Пишет какую-то переменную или кусок кода и такой «да это был псевдокод». Ну и такая декомпозиция удобная в бою, а в задачах прототипирования или тупорылых тулов избыточна.

Важно понимать, что я то на 100% знаю что хочу от нейросетей, поэтому они мне пишут неплохой код. Так как у меня формулировка задачи выглядит как ТЗ :)

И кстати ещё это все нереально удобно для работы с битами и вызовами операционной системы. Что я проходил в универе на системном анализе. Мне по одной задаче нужно было работать с колодой карт. Но если представить её как массив карт, учитывая что карты из неё выходят и приходят обратно, там память с ума сходит. Или появляются всякие костыли isFree, Nullable и так далее. Поэтому я решил, что умещу колоду в 52 бита :) 0 карты нет, 1 карта есть. Но я не помню как в шарпе работать с этим синтаксисом, а вот нейросеть такой код пишет отлично :) Конечно забывает, что мы теперь работаем с битами и пытается где-то подсунуть массивы и списки, но если за этим следить, это быстрее лично для меня, чем вспомнить всю логику работы битшифтов в шарпе :)

#оработе

Абсурдная оптимизация: Падающий песок
https://www.youtube.com/watch?v=HrrJxkRlRfk

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

Достаточно простая концепция позволяет моделировать довольно сложные процессы. Основное преимущество по сути возможность строить сложные границы. Представим задачу что мы хотим посмотреть распространение дыма по локации. Логику этого можно базово задать клеточным автоматом, как и у автора в примере с песком. И что удобно, так как вычисления зависят только от ячейки и данных в её соседях, то такие вычисления довольно просто переносятся на GPU.

Кстати, если говорить про математическое моделирование каких-то процессов. Потому что автор там берёт какое-то выдуманное правило. Допустим взяв для примера задачу распространения тепла по материалу. Можно прикидывать такое грубо, что подходит для задач в играх. Просто каждый такт тепература усредняется между соседями с какой-то дельтой. И окажется, что это довольно близко к уравнению теплопроводности (Лапласа). И при правильном шаге, параметрах теплопроводности, размере ячеек сетки и небольшому усложнению уравнения среднего можно получить довольно точную математическую модель.

И вообще так работает со многими дискретными методами. Клеточные автоматы и тот же метод конечных элементов, при правильно заданных уравнениях и достаточно мелкой дискретизации (мелкая сетка и так далее) дают значения близкие к нашим математическим представлениям об устройстве реальности. Этим они и прикольны. И благодаря дискретности и отсуствию сложной условной логики, как и необходимости знать много информации, вычисления на эту тему довольно легко переносятся на GPU. Хотя конечно сейчас есть и более современные и модные методы, вроде того на чём базируется Nvidia Flux (сопоставление потоков). Но что важно понимать про нейросетевые методы. Просто человечество условно когда-то решило: "Память не проблема, у нас её много. Зачем нам что-то решать и моделировать в реальном времени, если мы можем просто подставлять ответы? Пусть грубо и не супер точно, но для продакшена годится."

#новости

Про цифры в игровой индустрии: Цифры можно видеть по разному

Я был недавно на форуме KamaDev. Там был интересный доклад Андрея Карелина (VK Play). Например, цифра в 77% по Steam сразу вызывает вопрос: сколько из этих проектов неконкурентоспособны? Если предположить 50%, то картина уже не такая печальная. Но разговор не об этом.

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

Главное, чтобы у проекта сходились ключевые метрики:

ALTV (средний доход с игрока) должно быть больше CPA (стоимости привлечения).

Точку безубыточности можно грубо оценить так:

DevCost - (ALTV - CPA) * CPA / AdBudget = 0

Если математика сходится — проект окупается. Формулу можно детализировать, учтя комиссии и налоги. Но суть в том, что у каждого проекта свои уникальные возможности по рекламе и стоимости разработки.

Если тема интересна, напишу серию постов с расчётами и нюансами для инди-разработки. Собираем 🔥. Наберём 100 — продолжу.

#интересное

Всех с Новым Годом! 🎉🎊🎆🎄🍾

Григорий Дядиченко pinned a video

А обсуждать что выбрал инди разработчик который умеет работать только на Unity для фанового проекта особо смысла не имеет. Я всегда был против такой критики потому что молодые команды должны делать на том, на чём получается, на чём умеют, а не задаваться такими вопросами как "что тут оптимальнее". Сделанный кривой продукт в разы ценнее чем оптимально несделанный. Это опыт, с которым уже можно работать и делать что-то новое. Страшнее всего вечно делающиеся проекты. Если мы говорим о коммерции, то умение завершать проект, фичекатить, искать компромиссы в разы круче перфекционизма, потому что в коммерции мы живем в реалиях бюджетов и сроков. И если бюджет на кор гемплей закончится потому что команда решила писать на three.js ибо так оптимальнее, и интеграция фич и контента стала стоить х2, относительно той же реализации в юнити. А выиграли мы 5 мб веса и 20% произвоидельности. Да никому в бизнесе это нафиг не надо. Лучше уместиться в бюджет.

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

#новости

Bongo Cat — убийца системных ресурсов
https://habr.com/ru/articles/982102/

Даже сил на предновогодний пост хватит перед тем как окунуться в объятия оливье. Сорри что чутка проспамил, но не мог пройти мимо. Просто автор затронул мою излюбленную тему. Выбор технологического стека. *щелкает пальцами как бизнес технарь*.

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

Но поговорим в общем про тему. Выбор технологического стека. Давайте предположим что мы живем в фентези. А точнее в профессиональной коммерции, где решение о технологическом стеке - это решение принимаемое людьми с достаточной экспертизой. А не "что умеем, тем и пользуемся". В этом случае в компании должен существовать технический директор, с опытом разработки проектов различного масштаба, на различных технологиях. Понимающий плюсы и минусы каждого конкретного подхода. Таких людей на рынке натурально единицы. Я себя нескромно причисляю к ним, так как я разрабатывал и корпоративные решения, и игры, и мультиплееры, и синглы, на самых разных технологиях. Но в реальности если будет возможность я часто предпочту анриалу юнити. Потому что там больше проблем я знаю как решить. Поэтому выбор зависит от конкретного опыта конкретного техдиректора.

Но ладно, анриал или юнити это часто близкий выбор, как бы кто не спорил. Разительной разницы между этими движками нет. Для сессионки где ключевым была бы репликация данных даже я бы взял анриал, потому что модуль репликации там неплохой. И там сделать шутан аля анриал торнамент ощутимо проще 🙂 А что ещё важно для принятия решения о стеке в таком взрослом подходе? Ну чтобы этот проект кто-то мог сделать, то есть устройство рынка найма. Когда я уходил в рекламный рынок и в веб, я понимал что Unity трудно сделать оптимальнее чем pixi.js, phaser, three.js и так далее. Но если выйти на рынок найма и сказать "мы делаем крутой проект на three.js", то при масштабировании и росте проекта спецов искать на работу замучаешься. Своих растить тоже дорого. Поэтому мне было по бизнес причинам проще оптимизировать Unity, чем брать "более оптимальные технологии" за основу. И конкуренции в этом поле мало, потому что опять-таки, даже появляются студии которые "мы используем именно веб технологии". Это мессадж который трудно продать. Это при развитии упереться в ту же проблему что я описал. Просто я это решил посчитать заранее. А если игра работает на 15% медленнее, но всё ещё в 120 фпс. При этом вы можете нанять на не пару Вась, которые понимают в вашем тех стеке, а имеете выбор из сотен, то очевидно что плевать на эти 15%. А вы при росте не особо хотите оказываться в ситуациях где у вас есть деньги, а сделать вы ничего не можете, так как платить их некому.

И тут мы приходим к основной мысли. Ведь грамотный техдир может заранее всё спрогнозировать, сэкономить много денег и тому подобное. Выбрать стек не только по технологиям, но и по бизнесу. А это экономит тонну на том, что не надо брать на себя перерасход на "наращивание штата", на "переработки и переделки проекта" (так как переделка со сменой стека это космический кост) и так далее. И так то оно так, но есть нюанс. Такие спецы стоят дорого (я вообще чаще выполняю роль внешнего консалта, так как в штат идти я не особо хочу). Поэтому эта экономия работает на проектах у которых планируемый бюджет (общий на создание) стартует думаю от 400 000$. С такими спецами получается и сэкономить, и получить более стабильный продукт. Так как опыт позволяет предсказывать проблемы и решения до их возникновения.

Наш новый шоурил

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

#оработе

Про 2025

Обычно итоги я подвожу раньше. Но в этом году даже конец года был довольно плотный. Всех с наступающим в первую очередь! Вот уже год я живу в горах и мне нравится. Всё же в Москве классно работать, а не жить на мой вкус. Жизнь в Поляне мне нравится в разы больше, да и климат отличный.

По работе год был сложный. То что стало меньше денег вертеться на рынке было довольно ощутимо. В этом году мы сделали 15 проектов. Чего-то крупного было штуки 3-4, а остальное мелкие, но кайфовые проекты. Мне нравятся и лендинги которые мы сделали в этом году, и игры. В следующему году надо будет постараться чтобы делать больше.

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

Мы обновили сайт https://whitelabelgames.ru/ Наконец-то оформили часть портфолио, хотя и ещё не всё. Нужно добавить все виды интерактивных карт, которые мы делали за последние годы. И которые не за NDA. Плюс я хочу немного подпилить контент на сайте на праздниках. Новый дизайн мне нравится, но главное что появилось портфолио. А то раньше кидать для демонстрации проектов видео по чатам было неудобно обсуждая какой-либо проект. Хочу ещё таки прикрутить телеграм бота на праздниках. В этом году так часто приходилось тушить пожары, что на такую мелочь времени не оставалось.

По блогу меня всё терзает мысль что хочется завести какой-то видео-формат. Посмотреть площадки где есть органический рост. Потому что в телеге с этим всё плохо. Но продашкен видео ощущается чем-то сложным именно в плане съёмок. Сценарии и контент то мне не трудно придумывать. Может пересилю себя в новом году. Хотя опять-таки вопрос в площадках. Потому что на РФ платформах будто бы нет органики. Что вк, что рутуб людям заменяет телевизор, и туда выходить с образовательным контентом по игровым движкам (так как там нет системы рекомендаций) будто бы нет смысла.

В общем. Год получился тяжелый, но классный. Хотя по финансам я потерял много и сново нахожусь в "режиме пирата" живя по принципу "похер, разберемся" без подушек и так далее. С другой сделать в этом году получилось немало. Зато за последние два года я в личном плане приобрел много, что по сути бесценно. А с финансами разберемся, дело наживное и на самом деле не такое сложное, когда ты занимаешься чем-то 12 лет по 12+ часов в день. Навыки за праздники я не пропью, хотя возможно попробую 😆

Всех ещё раз с наступающим Новым Годом! Спасибо что подписаны и следите, блогу уже почти 4 года, и он жив только благодаря вам! В новом году я постараюсь сделать больше и интереснее. А будет это видео формат или что-то другое - посмотрим.

#итогигода

От 150 до 1000 рыб: как Unity Burst преобразил разработку
https://80.lv/articles/mobile-friendly-1-000-fish-simulation-in-unity

Разработчики Tap Oceans (Superheart) поделились прогрессом. Раньше из-за проблем с оптимизацией в игре было лишь 150 рыб, и процессор «плавился». С помощью Burst'а команда увеличила это число до 1000+ с хорошей на производительностью!

Параллельно идёт работа над процедурными 3D-пещерами, подводными дронами, системами вооружения и крутыми эффектами. Браузерная версия игры уже в планах!

#новости

Найм лучше бизнеса
https://habr.com/ru/articles/977792/

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

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

На работе я именно умирал со скуки, моя работа мне по сути не давала этой самореализации. Поэтому я ушел их последней компании «психанув от стабильности». Хотя думаю с текущем набором навыков, мне бы могли дать какие-то амбициозные и интересные задачи. Бизнес научил переговорам, грамотно продюсировать проекты и многому другому. Продавать, контролировать исполнение и так далее.

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

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

Поэтому в бизнес, как и в геймдев, надо идти по любви (а в геймдев я бы даже сказал по большой). Разработка игр в этом плане ещё под капотом хранит тонну рисков, как и любая творческая активность. А за деньгами лучше и проще ходить на работу. И наверное если в «реальном мире» трудно с тем чтобы зарабатывать больше среднестатистического предпринимателя, то вот в айти это не самая трудная задача. А точнее в разработке.

#новости

Магия GPU: как заставить мобильник рисовать природу с поэзией и ритмом
https://makedreamvsogre.blogspot.com/2025/12/gpu-driven-poetic-dynamics-from.html

В статье описывается система GPUFloraPainter, которая позволяет обрабатывать на GPU двадцать типов растительности, включая симуляцию ветра, взаимодействие с окружением, редактирование и отсечение невидимых объектов. Вся логика работает в Compute Shader: CPU только передаёт список видимых ячеек, а GPU самостоятельно обрабатывает все вычисления, что позволяет поддерживать 57–60 FPS даже на мобильных устройствах среднего уровня. Система использует Quadtree для разделения сцены на ячейки, Voronoi алгоритм для процедурной генерации растительности, FilterMap для управления типами и плотностью растительности, а также RenderTextures для хранения данных. В результате достигается высокая производительность и реалистичное отображение природы.

#новости