Хорошая новость для разработчиков на Unreal Engine: мы сделали PVS-Studio доступнее, и теперь анализ UE-проектов в PVS-Studio доступен в лицензии Team, а не только в Enterprise. Далее рассказываем, почему мы пересмотрели лицензирование и что это значит для небольших и средних игровых студий.
В прошлой статье я сделал обзор на существующие на данный момент методы реализации анимации персонажей с применением машинного обучения. Однако существует ряд нераскрытых приемов, без которых финальный результат будет неудовлетворительным. В этой статье я поделюсь опытом реализации Learned Motion Matching.
Unreal Engine убирает блюпринты и приносит ECS и Verse!
Написал свое впечатление от первого запуска 6й версии движка.
Представьте, что вам нужна фотореалистичная 3D‑копия реального объекта или сцены: например, лица актёра для крупного плана или целой городской улицы. Сегодня для этого есть два инструмента: классическое 3D‑моделирование и фотограмметрия. Однако они съедают недели работы и ломаются там, где очень важны детали, — волосы, хром, стекло, отражения превращаются в артефакты. А на то, чтобы снять реалистичную сцену или объект так, чтобы это масштабировалось на тысячи единиц, обычно уходит слишком много времени и денег.
Выход из этого тупика для целого ряда задач мы нашли в Gaussian Splatting и прогнали технологию через несколько очень разных проектов: сканирование людей и локаций для кино (например, для «Кибердеревни»), создание цифровых двойников городских кварталов и симуляцию для автономного транспорта. Инструмент один — задачи разные. И именно на этом контрасте и родилось самое интересное.
Сегодня я расскажу, как риг из 15 камер заменяет установку за сотни тысяч долларов и зачем мы используем движущегося человека как калибровочную доску. Объясню, почему для беспилотного автомобиля фотореализм обязан рождаться из данных, а не из 3D‑редактора. Ну и, конечно же, расскажу про YaGS Plugin — наш опенсорс‑плагин, который делает Gaussian Splatting полноценной частью сцены в Unreal Engine.
Думаю начну с начала. Я занимаюсь разработкой одного артхаузного проекта с названием "Attempt to Survive" и работая над ним , имел одну важную цель. Сделать высокую оптимизацию для работы со многими старыми системами, с устаревшим железом на текущие реалии. При этом имея достойную картинку.
Для этого даже сделал небольшую сборку тестового пк с i7 6700k процом, картой gtx950 8 гигами оперы и материнкой с соответстующим сокетом. Многое уже имел от старого железа в коробках, так что собрать сложности не было.
Малое вводное.
Если посмотреть в далекое прошлое, можно узнать о личном опыте автоматизации тестирования и разработке в общем и целом. Но это отдельная история, и не представляет практически никакого интереса, по сравнению с тем, о чем пойдет речь ниже.
О чем статья. Как неделю назад в проекте была завершена предварительная настройка автоматизации разработки на UE5, что автоматизировано, а что нет. Также немного о ключевых вещах работы с AI и выбранных решениях.
Немного в прошлое.
В августе 2025 года, установка Qwen coder, поиск подходящего клиента плагина для vscode - не взлетело. То ли агенты кривые(на момент попыток) по типу Roo code , Kilo code, Cline и прочих. Поиск возможности и способа индексации всей кодовой базы UE5 - также оказались не удачны. Всякие встроенные механизмы векторных баз данных - полный провал. Поэтому к данному направлению вернулся только месяц назад. Так получилось. Ресурсы ограничены, опыт, знания, компетенции, и подходящие инструменты, более умные нейронные модели и агенты со встроенным базовым агент поведением.
А в интервале первые попытки автоматизации разработки и вторая попытка - время когда вручную используя чат агента и ручной copy past - крайне неэффективно и медленно. Хоть и позволяет делать то, что без AI очень сложно.
Но речь пойдет о задачах, степень сложности которых, относится к уровню Senior с 10-летним опытом и глубоким знанием архитектуры движка UE5 и его конкретных модулей. и недели на реализацию в лице одного такого специалиста. Также в этот период только начинали развиваться первые MCP Tool servers for UE5.
Анонс игры — одна из самых важных частей её разработки.
Сложно переоценить значение этого этапа. Он важен как для крупных студий, так и для соло‑разработчиков вроде меня. Хочу поделиться своей историей «успеха» анонса на IGN. Расскажу о технических проблемах при работе с движком UE 4, а также какими инструментами я пользуюсь.
Привет, Хабр! Меня зовут Роман Заикин, я руководитель проекта градостроительного модуля платформы R2 в компании ПИК. Хочу рассказать, как и зачем мы создали собственный инструмент для архитектурно-градостроительного анализа, какие вызовы решали и каких результатов добились (и причём тут Unreal Engine).
С 2022 года отечественная игровая индустрия получила, по разным оценкам, около 7–10 млрд рублей государственной поддержки. Цифры могут показаться огромными, но, сравнив их с мировыми, становится не так страшно. Например, разработка GTA V или Cyberpunk 2077 стоила порядка $300 млн — это около 20–25 млрд рублей. То есть весь объём государственной поддержки за несколько лет — это половина бюджета одной крупной игры.
И всё же для российского геймдева это беспрецедентные инвестиции. А ещё создано множество проектов, направленных на поддержку игровой индустрии. Но почему же из всех этих стараний мы видим лишь набор аккуратно собранных, но мёртвых проектов?
Ты — начинающий художник, который дорвался до Unreal Engine 5 и даже создал по гайду свою первую локацию. Но вот незадача: небо! Оно пустое и совсем не такое, как тебе хочется. А хочется, чтобы всё было «по красоте». Перерыв весь YouTube, ты нашёл кучу плохих роликов и парочку видео, где на протяжении 100 500 часов монотонный хмырь рассказывает художественную базу, от которой уши вянут.
Давай начнём с простого. Открываем Photoshop и создаём сцену 2048 x 2048 (можно и больше, тут стесняться не надо). Дальше нам нужно скачать два набора кистей. Вообще, их можно купить или найти официально, но мы — люди находчивые, поэтому ищем на «зелёном Ютубе под пиратским флагом».
UHT сгенерировал 4294 строки кода из одного моего заголовочного файла. Имена свойств, смещения в памяти, флаги сериализации, exec thunks для каждой функции - всё, чтобы движок в runtime знал о классе то, что C++ забывает после компиляции. Это третья и последняя статья в серии про внутренности Unreal Engine: K2Node → Blueprint VM → рефлексия. Разбираем, что внутри этих четырёх тысяч строк, зачем каждая из них, и как ими пользуются Details panel, GC, репликация и сама Blueprint VM.
В предыдущих двух статьях я разбирал K2Node - как устроены ноды Blueprint изнутри - и Blueprint VM: байткод, опкоды, стековую машину. Следующая на очереди - Reflection: UClass, UFunction, FProperty и вся система метаданных, на которой стоит движок.
Готовясь к ней, я решил, что лучше всего разобраться в теме поможет практика. И тут подвернулся юзкейс: мне нужен был способ сконфигурировать вызов произвольной функции в редакторе и выполнить его в рантайме. Без хардкода, без кодогенерации, без десятка одинаковых обёрток. Так появился FunctionHandler - плагин для UE 5.6, в котором пригодилось всё, о чём я писал раньше: CustomThunk'и, ExpandNode, работа с FFrame и MostRecentProperty.
Эта статья - про то, как всё сошлось в одном плагине, какие решения сработали, и на какие грабли я наступал.
Каждый раз, когда вы соединяете ноды в Blueprint и нажимаете Play, Unreal Engine запускает маленький процессор. У него свои инструкции, свой стек, своя защита от бесконечных циклов. Он написан в ~4000 строках C++ и живёт в одном файле. Через него проходит каждый Event Tick, каждый Event BeginPlay, каждый вызов Blueprint-функции.
Этот процессор - Blueprint VM (Virtual Machine). И сегодня мы разберём его по винтикам.
Небольшая инструкция для всех, кто работает в Unreal Engine и пишет на C++ или иных языках + компилирует файлы для Андроид.
Всем привет.
Сегодня будем обсуждать механику счётчика стиля из Devil May Cry, но в диалоговой системе!
Играя в DMC, я заметил, что момент, когда вы открываете счётчик комбо - а мне нравится это делать подкидыванием демонов в воздух - похож на то же ощущение, которое я испытываю при открытии сноски в диалоге. Это даёт ощущение перехода на более сегментированный аспект системы - сперва приёмы в воздухе, потом на земле и снова в воздухе. Или как у меня - диалог, сноска, диалог, сноска, сноска, диалог. Так что я решил попробовать добавить эту систему в свою демку.
В этой статье разберём, как Unreal Engine строит Hierarchical Z Buffer (HZB).
Покажем, как вычисляются размеры mip-уровней, зачем нужно специальное округление float, как используются функции Gather, батчинг нескольких mip-уровней за один Dispatch, groupshared память, wave-операции и Morton Z Curve.
Пошаговый разбор шейдера с примерами поможет понять, какие оптимизации реально применяет движок, и как эти идеи можно использовать в собственных графических проектах.
Каждый, кто имел дело с Unreal Engine после 2014, наверняка слышал про скриптовый язык Blueprint. Но что реально происходит под капотом, когда вы таскаете ноды? Как создать свою ноду (и надо ли это вам вообще?) В данной статье я бы хотел разобрать K2Node
Я сейчас собираю маркетинговую кампанию для своей первой игры. Денег на рекламу — ноль. И это, на самом деле, не редкость: большинство инди на старте живут в режиме «или делаем игру, или делаем маркетинг».
И вот что я понял: маркетинг без бюджета работает. Это дисциплина. Это таблицы. Это упаковка. Это тайминг. И это нормальное количество отказов, которое нужно пережить.
Ниже — система, которую я выстраиваю сам. Это не «универсальная истина», но это точно рабочая логика для тех, у кого нет бюджета, зато есть голова и руки.
— Нам нужен дизайн-док. — Какой именно? — Ну...ГДД.
Пожалуй, это одна из самых частых ситуаций, с которыми я столкнулся, начав искать работу в студиях.
Я уже более трёх лет в геймдеве — пусть и как инди-разработчик. У меня своя команда, собранная с нуля. Я учусь в магистратуре по профилю «геймдизайн», прошёл ряд курсов от западных университетов, написал десятки тысяч диалогов, GDD, питч-доков, фич-доков и множество других документов.
Я понимал, что поиск работы — процесс непростой. Но я не ожидал, что одной из главных сложностей станет размытость формулировок и отсутствие ясности в том, какой именно документ требуется.
Под «дизайн-доком» может скрываться что угодно: от one-pager на одну страницу до многостраничного системного описания с метриками, балансом и техническими ограничениями.
В этой статье я не буду обсуждать, почему в индустрии зачастую выше ценится сухая аналитика и таблицы, чем авторское видение (при том что одно другому не мешает). Вместо этого я попробую систематизировать наиболее распространённые виды дизайн-документов, немного их типизировать и, возможно, помочь тем, кто только входит в профессию и теряется в этом терминологическом хаосе.
Итак, попробуем разобраться.
Всем привет!
Сегодня говорим про систему world state — она позволяет делать вариативность, запоминать решения игрока и делать реплики/ответы на основе флагов.
