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

Как растёт операционная нагрузка вместе с командой Есть такой момент в жизни любой студии, когда замечаешь, что куча времени уходит не на работу. Бухгалтерия, договоры, согласования, переводы, акты. Один подрядчик — терпимо. Пять из разных стран — уже отдельная работа. Когда я веду крупный проект или несколько мелких, я часто за созвонами, договорами, заказами, актами и переводами не успеваю делать больше ничего. Хотя с точки зрения делопроизводства сейчас многое упростилось. Но ладно, я в аутсорсе — у меня это часть жизни уже давно. У части коллег со всеми событиями последних лет просто нет денег в РФ, и приходится придумывать, как что-то тут оплатить. Отдельная головная боль — выплаты зарубежным подрядчикам. У меня был классный сейлз-менеджер из Минска, в какой-то момент девочка, делающая крутое 3D, переехала в Германию. Да и вообще: я видел студии, где этим занимался разработчик в свободное время. Студии, где это висело на продюсере. Многие, начиная делать проект мечты, забывают, что это бизнес. А бизнес помимо предпринимательской ответственности тянет за собой тонну сопутствующих «ритуалов». Постепенно рынок под это подстраивается — появляются инструменты, заточенные под распределённые команды, тот же Arbonum. Но большинство небольших студий до сих пор решают это руками. При этом международные переводы — это всегда риск: или права оформлены неверно, или деньги где-то просто зависнут. Хорошая новость: это решаемо. Плохая: пока не больно — никто не чинит. А больно обычно в самый неподходящий момент — когда горит дедлайн и выясняется, что у вас нет прав на арт, который уже в билде. #мнение #бизнес

Анимация поверхности воды в реальном времени на Unity https://80.lv/articles/this-enchanting-water-cross-section-was-created-in-unity Sakura Rabbit снова. Если не знаете — один из моих любимых Unity-разработчиков, делает визуально безупречные вещи. На этот раз — лесное озеро с анимацией поверхности воды. Выше — туман и атмосфера, ниже — камни, растительность, лучи света проходящие сквозь воду. У сакуры в портфолио ещё куча подобного — динамические капли дождя, складки ткани в реальном времени, эффект в стиле Venom, каблуки которые адаптируются к высоте персонажа. Если не следите — советую. #находка #unity #шейдеры

Клеточные автоматы с несколькими окрестностями на Compute Shaders https://www.reddit.com/r/Unity3D/comments/1s2sh1u/multiple_neighborhood_cellular_automata_using/ Обычный клеточный автомат — например Game of Life — смотрит на 8 соседей вокруг клетки. Включить или выключить — решает простое правило. MNCA (Multiple Neighborhood Cellular Automata) делает иначе: вместо одной окрестности — несколько концентрических колец на разных радиусах. Каждое кольцо имеет свой вес. Результат — не пиксельная сетка, а плавные органические структуры которые выглядят как что-то живое. Митоз, рост грибницы, нейронные связи. На CPU это не запустить в реальном времени — слишком много вычислений на каждый пиксель. Compute Shaders решают проблему: каждая клетка считается параллельно на GPU. Из тех вещей которые смотришь и думаешь "как это вообще работает" — а потом разбираешься и оказывается что математика там элементарная, просто применённая красиво. #новости #unity #шейдеры #алгоритмы

Про «Наблюдателя» https://www.youtube.com/watch?v=0wVF68QZrtQ Хорошее видео, но на самом деле депенденси хелл чутка преувеличен. Потому что тут вопрос реализаций представленной в видео. Да паттерны обладают разными недостатками. Но тут мне не совсем нравится логика регистрации объектов в наблюдателе. Хотя в видео по сути поднимается проблема депендеси хела со всякими менеджерами типа звука. И в целом берется небольшая проблема прямолинейной реализации. С миллионами зависимостей, узкими точками отказа и так далее. На самом деле это бывает даже не так критично, когда вы пишете не движок, не библиотеку и не фреймворк :) Разберем на примере менеджера звука. Есть про менеджер звука знают объекты визуализации и объекты игровой логики, это казалось бы потенциальная точка отказа. Но мы не на сервере с сложной реализацией сервиса. Менеджер звука обычно это весьма условно стейтлесс штука (точнее её стейт не особо меняется), и она по сути просто что вызывает «системные вызовы» воспроизведения звуков. По крайней мере в той точке где миллиард зависимостей. Если зависимости не меняют состояния, обращаются в точку которая не может отказать и вызывают довольно тупые методы — там сложно создать себе проблемы. Это происходит в других случаях, где множество зависимостей меняют состояние объекта в не пойми каком порядке. Но базово как этой проблемы избежать? Вот у нас есть звук при спауне, звук при сборе и так далее. И тут нам помогает композитная система Unity компонент. И абстрактные Unity события. Система компонент позволяет по юнити событиям делать подобные вызовы при этом не зная о контексте остальной системы. Да и в целом это работает специфично. Потому что это как раз ведет нас к разнице подходом Config-First, Code-First и так далее далее. Но и у них есть своя цена. Код ферст всегда позволяет почти всегда быстро находить проблемы, так как там нет контрактов, которые не зафиксированы в коде. Конфиг ферст всегда имеет какой-то внешний абстрактный контекст и часто требует документации. Для примера с тем же пресловутым звуком. У вас есть понятное место в коде где по логике вызывается сбор кристаллов. И вы вызываете там звук сбора кристалла. Всё явно и очевидно. Альтернативное решение без лишних зависимостей. У вас есть компонента которая в OnDisable вызывает звук по айди. Айди сериализованное поле. Вам нужно повесить на префаб кристалла эту компоненту и прописать айди соответвующего звука. И это уже некий абстрактный контракт не зафиксированный кодом. А видос рекомендую посмотреть. Так как понимать как можно играться с архитектурой проекта полезно. И автор говорит дельные вещи. Что в конкретном примере это не критикал, это неважно, так как когда создаешь подобные материалы трудно подобрать пример который подсвечивает все нюансы. #новости #мнение

200 человек и $50 млн vs один человек и вагон терпения: как соло-разработчик сделал игру уровня Atomic Heart https://habr.com/ru/articles/1013082/ Или кликбейты наше всё. Автор крутой, ничего не скажешь. Вообще уважаю людей доводящих проекты до конца. А тут такой визуально достойный проект. Хз что по геймплею, учитывая такой большой блок про проблемы с сохранениями, но выглядит прикольно. Успешный творческий проект. С точки зрения бизнеса, особенно игрового, цифра в 100к$ для кого-то может звучать внушительно (в статье есть эта цифра, за 6 лет разработки, но к слову сказать без особого маркетинга). Но по сути это 17к$ в год, а после всех вычетов 10-11к$ в год или 1к$ в месяц условно без учета расходов на проект. Ну то есть зарплата джуна за такой титанический труд демонстрирует важность маркетинга. А так я просто не люблю кликбейты. Это скорее не к автору игры, а к автору статьи. Делал проект один, но не один (композитор, жена, еще люди появляются по тексту). И так далее. Но как рассказать про прикольный проект — ладно. А так, не знаю как сам по себе проект, а автор в любом случае молодец. Если смотреть как на творческий проект, чем вполне могут быть игры как форма искусства, а не как на бизнес проект — очень круто. #новости

TDD играет новыми красками если подумать Вообще я только сейчас понял насколько хорошо нейросети подходят под TDD (Test Driven Development). Часто в плане будет стоять тест, но если изначально придерживаться этого подхода, это будет работать до забавного интересно. Основной проблемой для TDD всегда была скорость. Сначала пишем тест, потом код, подключаем это все в CI&CD. И написание + поддержка тестов отнимала кучу времени. Конечно же в данном подходе не стоит и код, и тест генерить нейросетью — такое. Это не TDD, это само подтверждающийся шум. А вот написать тест грамотно, как подтверждение корректности реализации и остальное оставить кодогенерации — звучит разумно. Для мелких задач можно и тесты кодогенерить в целом, но важно держать в голове что ИИ всегда пишет тест не к твоему функционалу, а к своей реализации. То есть тест будет тестировать что сделала нейросеть, а не то что надо было сделать по бизнес логике. Конкретно это выражается в том, что ИИ может: пропустить edge-кейсы, о которых ты не написал явно; выбрать одну интерпретацию неоднозначного ТЗ и последовательно провести её и в тестах, и в коде — всё зелёное, но не то что ты хотел; протестировать детали реализации вместо поведения. Если уметь грамотно контролировать контракты и давать ТЗ на их реализацию. Делать кодогенерацией тесты и реализацию раздельно, то это близко к TDD. Но с грамотно написанными тестами забавно как нейросеть может адаптировать реализацию. Если тест писать самостоятельно, то на самом деле вопрос филосовский важно ли, что в черном ящике. Так как тест может валидировать производительность, безопасность, реализацию, поведение и все что хочешь. Но другой вопрос, что ИИ может пытаться подогнать ответ под тест. Поэтому конечно этот подход нужно проверять временем. Но просто работать может любопытно. #мысли

Ооо, мультики сменили игры Инфоцыгане подключились в новые модные веянья ИИ. Вопрос на сколько им будут верить менеджеры 🙂 Я помню серию роликов на YouTube что заработай 500$ в день с этим методом. И ролики по продакшену мультиков для детей на Youtube с рекламной монетизацией. Теперь начинает прорезаться тоже самое про игры. Но пока заголовки не такие кликбейтные. Жду прям "как я заработал на своей игре 5000$ сделав её нейросетью" Да, конечно процессы упрощаются и нейросети забирают много рутинной работы. Один инженер сможет делать больше, но и работы как бы не мало. Но дело даже не в этом. Если вы знаете как делать успешные продукты в айти на мировой рынок, то изменение костов с 200 000$ на мобильный проект до 80 000$ включив нейросети (с нечистыми правами и прочими проблемами, допустим они вас устраивают) - не так важны. Успешный мобильный проект натурально зарабатывает сотни тысяч долларов в месяц. Поэтому понятное дело, что самым ценным как был, так и есть навык придумывать и доводить до реализации успешные продукты, и нейросети это не решают. Уметь грамотно делать анализ рынка, тестировать продуктовые гипотезы, строить роадмап продукта и так далее. Это те навыки которые тяжело заменить, так как сетки там галлюцинируют часто, ибо чаще всего это опыт которого нет в общем доступе. А что прогеры раньше за неделю фичу делали, а теперь 3, сильно миропорядка в айти не меняет. Но инфоцыгане как всегда забавляют. #мнение #карьера #геймдев

Unity официально поддерживает Steam https://app2top.ru/news/dvizhok-unity-ofitsial-no-nachal-podderzhivat-steam-238839.html Занятная новость с GDC. Unity наконец-то официально поддерживает Steam — до этого разработчики годами интегрировали Steamworks руками сами, без какой-либо официальной поддержки со стороны движка. Работало, но костыльно. Теперь есть Platform Toolkit, нативная поддержка SteamOS и Steam Deck. Плюс обещают регулярно обновлять Linux runtime — чтобы не нужен был Proton. Честно говоря немного смешно что это случилось только сейчас. Steam — крупнейшая PC-платформа, Unity — один из главных движков для тех же инди. Они просто... не были официально интегрированы. Все просто делали вид что всё нормально 🙂 Ещё интересная деталь: упомянули интеграцию с Fortnite, но подробностей нет. Напомню — в конце прошлого года Unity и Epic неожиданно объявили о партнерстве. Будем посмотреть. #новости #unity

Больше каналов богам каналов @easy_dev_math Те кто читает давно знают что математика в постах — одна из моих любимых тем. Векторы, шейдерная математика, интерполяция. Решил вынести это в отдельное место. Канал называется «Математика в геймдеве по простому» — там буду разбирать математические концепции через конкретные задачи разработки. Не теория ради теории, а почему синус нужен для движения по кругу, зачем матрицы в 2D-игре, как Безье делает анимацию живой. С примерами на Unity. Этот канал никуда не денется — здесь как обычно, всё остальное. Математика просто заслуживает своего места. Кому интересно — подписывайтесь и делитесь с друзьями :)

Как искал быстрый asin() и нашёл его в документации 2012 года https://habr.com/ru/articles/1009424/ Хорошая история про то как легко потерять несколько дней оптимизируя то что уже оптимизировано. Автор работает над трассировщиком лучей. Профилировщик показывает что std::asin() вызывается много. Окей, надо ускорить. Пишет аппроксимацию на рядах Тейлора — получает +5%. Неплохо, но точность страдает на краях диапазона. Переходит к аппроксимациям Паде — сложнее, точнее, но скорость та же. Несколько дней работы. Красивые графики погрешностей. Умная математика. Потом спрашивает LLM — тот выдаёт решение из документации Nvidia CG Toolkit. Продукт не обновлялся с 2012 года. Формула из учебника по математике 1960-х. На Intel быстрее std::asin() в 1.5–1.9 раза, точность почти идеальная.

double fast_asin(const double x) {
    constexpr double a0 =  1.5707288;
    constexpr double a1 = -0.2121144;
    constexpr double a2 =  0.0742610;
    constexpr double a3 = -0.0187293;
    const double abs_x = fabs(x);
    double p = a3 * abs_x + a2;
    p = p * abs_x + a1;
    p = p * abs_x + a0;
    return copysign(HalfPi - sqrt(1.0 - abs_x) * p, x);
}

Мораль которую сам автор и формулирует честно: он ни разу не остановился и не спросил себя "а может кто-то это уже решил?". Просто начал делать. Решение лежало в мёртвом SDK, который никто уже не помнит. И никто из знакомых разработчиков не подсказал — хотя проект публичный и известный в C++ и графических кругах. Узнаваемая история. #новость #рендеринг #математика #оптимизация

Path tracing в URP https://github.com/Kuan-Mi/UnityPathTracing Нашёл интересный репозиторий — реализация real-time path tracing в Unity URP. Не просто "пустили лучи", а полноценный стек: DXR-пайплайн, шумоподавление от NVIDIA (REBLUR, SIGMA), DLSS Ray Reconstruction, SHARC для кэширования радианса. И всё это работает с динамическими сценами включая скиненные меши. Что меня зацепило — поддержка VR режима. Path tracing в VR это отдельный круг ада с точки зрения производительности, и то что кто-то это вообще пробует — уже интересно. В планах у автора ReSTIR DI и объёмное освещение. #интересное #unity #шейдеры #рендеринг

Пи-день 🥧 Каждый год 14 марта (3.14) математики и программисты по всему миру отмечают день числа π. Традиция началась в 1988 году в музее науки Сан-Франциско — физик Ларри Шоу устроил парад вокруг круглого стола и угощал всех пирогами. Сейчас это неофициальный праздник всех кто любит числа. Задачка в честь дня: как вычислить π не зная никаких формул — только с помощью случайных точек? Берём квадрат 2×2. Вписываем в него круг радиуса 1. Бросаем случайные точки. Считаем сколько попало внутрь круга. Отношение попавших к общему числу точек стремится к π/4. Умножаем на 4 — получаем π.

float EstimatePI(int samples)
{
    int inside = 0;
    for (int i = 0; i < samples; i++)
    {
        float x = Random.Range(-1f, 1f);
        float y = Random.Range(-1f, 1f);
        if (x * x + y * y <= 1f) inside++;
    }
    return 4f * inside / samples;
}

Почему это работает: площадь круга = π·r², площадь квадрата = 4·r². При r=1 отношение = π/4. Случайные точки распределяются равномерно, значит их соотношение повторяет соотношение площадей. При 1 000 сэмплов получаем ~3.1х. При миллионе — ~3.141х. Сходится медленно, зато наглядно. Это метод Монте-Карло. Именно он лежит в основе глобального освещения в path tracing — каждый световой луч это случайная выборка, накапливаете достаточно и получаете физически корректную картинку. С праздником, 3.14 🎉 #математика #шейдеры

Ответ: нет Time.deltaTime Как многие правильно ответили. Без deltaTime объект двигается на speed единиц каждый кадр. На 30fps — 30 единиц в секунду. На 144fps — 144 единицы в секунду. Скорость зависит от fps.

// Правильно:
transform.position += Vector3.forward * speed * Time.deltaTime;

deltaTime — время прошедшее с прошлого кадра. Умножая на него, получаем движение в единицах за секунду, независимо от fps. Этот баг был даже в игре по франшизе. Woody Woodpecker: Escape from Buzz Buzzard Park — на слабом компьютере игра работала нормально, а на новом Вуди носился по экрану со скоростью света. Разработчики привязали скорость к кадрам, и чем быстрее железо — тем быстрее персонаж. Классика. Тут можно ещё в режиме прохождения собеседования докопаться до третьего варианта. Так как главный верный ответ дельта тайм, как почти все и ответили. Но самый верный подход на собесе, когда разобрались с таймом, вопрос "а на объекте есть коллайдер? Если да, то нужен rigidbody, а с перемещением Rigidbody лучше работать в методах RigidBody, чтобы физика работала корректно". Не обязательно, но плюсик в карму об этом подумать. Задача на собеседовании показать максимум того, что вы знаете. #задачка #unity

Задачка: что не так с этим кодом? Пойдём дальше по каким-то типичным базовым задачкам. В целом этот вопрос хоть и простой, но довольно неплохая проверка на опытность.

void Update()
{
    transform.position += Vector3.forward * speed;
}

Код работает, враг двигается. Но есть проблема которая проявится на разных устройствах. Какая? Варианты: а) transform.position нельзя менять напрямую - 🤷‍♂️ б) Ошибка в формуле - 🤷‍♀️ в) Нужен Rigidbody для движения - 🤷 #задачка #unity

ИИ не заберёт вашу работу. Но кое-что изменит Как технический продюсер я нанимаю беру людей на проекты. И за последний год что-то сдвинулось. Раньше джун это был человек которому надо объяснять синтаксис, ждать пока разберётся с документацией, принимать код который надо переписывать. Сейчас джун с Cursor или Copilot закрывает задачи которые раньше требовали мида. Это не значит что он стал мидом — он не понимает почему код работает. Но задача закрыта. Для студий это значит одно: спрос на джунов падает. Зачем брать человека на обучение если ИИ делает ту же механику за час? Но вот что интересно. Спрос на людей которые умеют правильно поставить задачу — вырос. Архитектурное решение, код ревью, понимание почему вот это решение сломается через месяц, вопросов безопасности — это то что ИИ пока не закрывает. Потому что для этого нужен контекст всего проекта, а не одного файла. Но даже когда он начнёт грузить проект целиком, многие недооценивают сколько неочевидного контекста разработчик держит просто в голове. Парадокс в том что ИИ сделал дешёвыми именно те навыки за которые джуны конкурировали. И одновременно сделал дороже то за что конкурировали сеньоры. Рост сеньоров станет медленнее, так как будет целая тонна код манки. Бизнес за этим погонится так же, как и он гонится обычно. Сколько "прототипов на выкинуть" стали развивать в продашкен решения потому что сроки горят и нужно срочно запускаться. Так что если вы только начинаете — учитесь не писать код, а понимать системы. ИИ напишет. Вопрос в том кто будет решать что писать и что написано хорошо. #мнение #карьера #геймдев

Питон знать конечно теперь ещё важнее Я всегда продвигал идею о том, что Python нужно знать всем. Не на продакшен уровне понимания языка, а чтобы уметь написать простой скрипт, запустить его и чет в нем отредачить. И сейчас этот навык как никогда кстати. И вот почему. Я продолжаю ковырять Claude и как же он медленно думает над какими-то простыми вопросами на самом деле. Многие "повторяющиеся" операции, которые можно автоматизировать скриптами (особенно в контексте Unity), он не автоматизирует, а будто решает заново. И тут нам на помощь приходит питон. Чтобы не ждать пока Claude почешет репу, всегда для задач у которых есть какое-то периодическое применение просишь его "а выгрузи мне python скрипт" который делает задачу. А не описание самой задачи. Пока по моему наблюдение конечно он не умеет главное, что хотелось бы автоматизировать и будто бы можно - это верстать в Unity. Но может просто я не разобрался как. Так как пытался я дважды в мелких задачках им верстать и собирал он какую-то чушь, даже когда ему подробно объяснишь что от него хочется. #мысли

Про цифры в игровой индустрии: Деньги, которые вы тратите ещё до первой строчки кода Продолжаю серию. В прошлых постах разбирали куда деваются деньги с продаж и почему ваше время не бесплатное. Сегодня про деньги, которые утекают ещё до того как проект начат — на найме. Допустим вы студия. Нашли хорошего технического художника. Он живёт в другой стране. И тут начинается. Юридическая консультация чтобы правильно оформить договор с иностранным подрядчиком — от 5 000 до 20 000 рублей. Одной. А договоров у вас не один. Банковские переводы: SWIFT в среднем стоит 30–50$. Плюс конвертация по невыгодному курсу, как разбирали в прошлом посте. На команду из 5 человек — это ещё 150–250$ в месяц просто за факт перевода денег. Передача прав: и это отдельная история. Без правильно оформленных документов о передаче имущественных и авторских прав — юридически они остаются у фрилансера. Не у студии. Это не очевидно, но именно так работает законодательство. И это не только про иностранцев — судов с фрилансерами по правам на результат работы даже внутри РФ было достаточно. Причём фрилансерам стоит это знать в свою пользу: если договора нет или он составлен криво — права на вашу работу остаются у вас. Итого скрытый overhead на одного иностранного подрядчика в год: грубо 1 000–2 000$ просто на административку. Для команды в 5–7 человек — 5 000–14 000$ в год только за то, чтобы людям платить. И это не только инди-история. В средних студиях та же проблема, просто масштаб больше и цена ошибки выше. Есть разные сервисы которые берут этот кусок на себя — например Arbonum: договоры, выплаты, передача прав. По сути превращает скрытый overhead в понятную строчку бюджета. Если набираем 70 🔥 — следующий пост про то как считать реальную стоимость разработчика с учётом всех накладных. Там тоже есть неочевидные цифры. Или как я в первый раз разорилися. #мысли #бизнес #цифры