Я давненько присматриваю замену QBS для компиляции игровых бинарный файлов. Текущая ситуация меня не страивает по нескольким причинам:

1. Я регулярно сталкиваюсь с тем, что QBS отказывается строиться из исходников на CI. Сейчас я вообще вынужден убрать его из релизов (в замен предлагается использовать QBS из более старых релизов).
2. Сам QBS довольно избыточен, для построения простых игровых бинарей. Он как швейцарский нож, очень многое умеет, но на финальной стадии постройки используется очень ограниченный функционал.
3. Исходя из второго пункта, QBS тащит за собой огромное количество разных вспомогательных файлов, что противоречит моей идеологии о компактности, раздувая редактор дополнительным мусором, который не используется, но требуется "на всякий случай".

Относительно давно я положил глаз на Ninja. Это компактная система сборки состоящая всего из одного бинарного файла. Из его плюсов:
1. Компактный.
2. Кроссплатформенный (Windows, Linux, MacOS)
3. Довольно простой файл для сборки

Однако есть и один минус! В отличии от QBS в Ninja нет генератора проектов для IDE. Но это в принципе решаемо, написанием своего генератора проектов. Нужно будет выделить время в след цикле разработки на исследование этого инструмента.

#thunderengine

Скоро конец квартала, а это значит, что настает пора релизов.

Встречайте новый релиз Thunder Engine!

В этом релизе добавилось много интересных штук, таких как:
- Поддержка HTML5 платформы. Теперь вы можете делать игры под веб.
- Вернулась поддержка MacOS.
- Улучшен графический пайплайн. Графика стала лучше! Хотя казалось бы куда уже лучше? =)
- Добавлена возможность обращаться к Web серверу (пока только для десктоп платформ)

Полный список вы можете найти тут.

#thunderengine

С момента релиза прошло уже больше месяца. И все это время я не делал новых постов. Каюсь!

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

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

Я никуда не пропал. Работа над движком продолжается.

Одной из самых моих нелюбимых частей движка, безусловно является редактор UI интерфейсов и инструментарий для манипуляции с виджетами. С ним все время какие-то проблемы образуются. Сама по себе система довольно простая. Но к ней навернуты системы масштабирования и margin'ы и padding'ы всякие, (которые добавляют головной боли) для правильного позиционирования виджета в иерархии. По не многу, я выправляю найденные баги. Но иногда. это занимает какую-то прорву времени. Так и сейчас. Я потратил примерно 2 недели, что-бы исправить поведение рамки. помогающей манипулировать виджетом. Было примерно как показано на скрине. Теперь должно работать правильно. Так-же я помню о старой таске за номером 720 в которой есть просьба добавить быстрое создание ассетов интерфейсов. У меня уже есть механизм шаблонов для них, но я пока не придумал, что нужно разместить в этом самом шаблоне. Может у вас есть идеи?

#thunderengine

Произвел реафакторинг UI компонент. Сделал применение стилей более гибкими. Как вы возможно знаете, все UI виджеты у меня состоят из простейших компонент. Frame/Image/Label. Все остальные виджеты, под капотом, это комбинация этой сладкой троицы. Иногда сложные виджеты требуют довольно глубокой иерархии. Что-бы нормально применять стиль (цвета размеры и т.д.), необходима возможность отделить своих, от чужих. Так родилась идея SubWidgets. При создании виджет сам регистрирует свои части в специальный контейнер. А когда применяются стили, мы легко можем пройтись по контейнеру и применить стили, только к зарегистрированным компонентам. Решение получилось супер элегантное. В будущем, можно даже селекторы специальные написать для CSS.

#thunderengine

Продолжаю совершенствовать редактор игровых интерфейсов. Добавил базовые шаблоны для ассетов типа UI (интерфейс) и CSS (таблица стилей). Задумываюсь о поддержке анимации виджетов через CSS. Но пока держу себя в руках.

#thunderengine

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

#thunderengine

Так-же сегодня произошло одно маленькое, но знаменательное событие. Счетчик сквозной нумерации тикетов/пулл реквестов приблизился к отметке в 1000. Это хороший повод поделиться некоторой статистикой:
- Количество решеных тикетов: 590
- Количество пул реквестов: 378
- Количество коммитов в репозиторий: 1337 (Elite ^_^)
- Всего выпущено релизов: 25

#thunderengine

Продолжаю улучшать редактор UI. Давненько хотел добавить возможность, выравнивания виджетов друг, относительно друга. Я называю эту фичу Snap Solver. На манер Решателей из CAD систем. Это не совсем оно конечно, но очень похоже. Технически, при перемещении виджета, или при изменении его размера, инструмент смотрит на соседние виджеты в иерархии и "примагничивает" границы по X и Y осям других виджетов, если таковые найдутся. Сейчас инструмент учитывает границу соседнего в иерархии виджета и его геометрический центр. В будущем, можно будет сделать еще и учет расстояния, выстраивая виджеты "паровозиком". Хотя для таких целей лучше подходят лэйауты, которые уже поддерживаются.

#thunderengine

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

#thunderengine

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

#thunderengine

Вот, наконец и подошел момент релиза версии 2025.3. В этой версии, я сфокусировался на исправлении, найденных мной, ошибок в различных редакторах ассетов (в основном UI Editor). Так-же я постарался улучшить пользовательский опыт (Copy/Paste), при использовании редактора. Новых фичей я завез совсем немного и они, по большей части, касаются низкого уровня. С полным списком изменений вы можете ознакомится здесь: https://github.com/thunder-engine/thunder/releases/tag/2025.3

#thunderengine

Продолжаю делать глобальные рефакторинги. Сегодня у нас на очереди работа со строками. Раньше я использовал std::string тип, для взаимодействия с текстовыми данными. Но он не всегда удобен, когда нужно сделать более сложные вещи, типа разделения, поиска или замены. Я решил написать аналог QString и не стал сильно заморачиваться, назвав его просто String. У него пока не так много фичей, как у оригинала, но на первое время хватит. Самое муторное было заменить все строки движка с std::string на String. Уверен, что баги вылавливать буду еще некоторое время. Но это глобальное изменение давно назрело.

#thunderengine

Пока занимался рефакторингом редактора, связанным с постепенным отказом от Qt. Я обратил внимание, что цикл, в котором происходит динамическое объединение объектов в группы, для последующей отрисовки, делает это каждый раз при вызове функции PipelineContext::drawRenderers. А это происходит несколько раз за кадр. Что приводит к многократному, бесполезному копированию, одних и тех-же данных. Надо бы этот момент оптимизировать. Чем я и займусь далее.

#thunderengine

Хотел ответить в комментариях, но решил сделать отдельным постом.
На самом деле там назрел небольшой рефакторинг, т.к. технический долг начинает давить. Некоторые моменты я просто решил убрать. К примеру у Actor больше не будет понятия "Слой" он переехал в Material. т.к, по большому счету, он использовался только там. И у Renderable может быть больше одного материала со своими личными настройками. Так-же, теперь, Renderable компонента может возвращать больше одного меша для отрисовки. Теперь каждому материалу можно будет назначить свой, индивидуальный меш, что позволит делать более сложные компоненты. Первый кандидат на это EffectRender.

#thunderengine

🌍 Куда делся ландшафт в Thunder Engine?

Если вы работали с Thunder Engine, то наверняка заметили: в нём нет поддержки ландшафта. "Как так?!" — спросите вы. Ведь даже в простых движках он есть!

И будете правы — когда-то он и у меня был. Но 5 лет назад, во время большого переписывания, Terrain просто… не попал в список поддерживаемых компонентов.

Почему? Потому что я хотел реализовать масштабные пространства — а без чанкинга тут не обойтись.

Иногда я снова задумываюсь о добавлении этой системы, но каждый раз упираюсь в сложности:
🔹 Обработка и хранение чанков
🔹 Удобство работы в редакторе
🔹 Формат данных, который пока далёк от идеала

Я изучил, как с этим справляются Unreal Engine и Unity, и понял: работы — целая гора.

Вопрос в другом: а нужно ли это вам? Стоит ли тратить время на ландшафты, или лучше сфокусироваться на других фичах?

Пишите в комментариях! 🚀

#thunderengine

Вчера получил вот такое письмишко.
Сотрудничать я с ними конечно не буду, но внимание приятно. 🔥
Интересно, почему наши так не отслеживают проекты? 🧐

Люблю проактивность. 🚀

#thunderengine

🔥 Частицы в Thunder Engine стали ещё круче!

Сегодняшние улучшения принесли две мощные фичи:

✨ Поддержка SubUV
✨ Анимация SubUV

Теперь вы можете:
🔹Создавать материалы с атласами спрайтов
🔹Настраивать анимацию частиц, которая будет проигрываться за время их жизни

Что ещё улучшено:
🔹 Исправлены баги в системе частиц
🔹 Пофикшены несколько крэшей
🔹 Полностью переработан вершинный шейдер Billboard

Теперь для анимации из атласов достаточно всего одного vec3 из инстанс-буфера!

Эти изменения сделают ваши визуальные эффекты более живыми и гибкими. Как вам такие апдейты? 💬

#thunderengine #GameDev #VFX

💭 Немного размышлений на тему визуальных эффектов.

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

На данный момент есть 2 класса отвечающие за визуальные эффекты в движке:
🔹 VisualEffect - это ресурс, в котором находятся все параметры и команды, отвечающие за поведение ваших частиц на сцене.
🔹 EffectRender - это компонент, который отвечает за проигрывание эффекта, его можно разместить непосредственно на сцене и назначить ему VisualEffect.

Итак мы разобрались с вводными.

А вот теперь, вам, предположим, нужно создать эффект костра. В котором должны быть:
1. Пламя
2. Дым
3. Искры (опционально)
4. Можно еще дисторшен от температуры добавить (опционально)

Совершенно очевидно, что это все разные эффекты, объединённые в одну систему.

Возникает закономерный архитектурный вопрос. Если у нас 4 разных эффекта, может объединить их в одну систему?

Вариант 1: Единая система

Можно переименовать:
VisualEffect → EffectEmitter (отвечает за отдельные эффекты)
Создать новый VisualEffect как контейнер для нескольких синхронизированных эмиттеров

Плюсы:
✔️ Есть центральный ресурс объединяющий разные эмиттеры и даже возможно их синхронизирующий.

Минусы:
⚠️ Предстоит рефакторинг с переименованием, что может привести к поломке существующих ассетов.
⚠️ Если мы захотим новую комбинацию эффектов, нам придется создать новый отдельный VisualEffect. Если помним, то EffectEmitter все еще хранится отдельно.
⚠️ Если в VisualEffect будет содержать всего один EffectEmitter, это все еще 2 ресурса к загрузке.

Вариант 2: Оставить как есть

Просто размещать несколько компонентов EffectRender и объединять их в префаб

Плюсы:
✔️ Не надо ничего менять, все работает как сейчас.

Минусы:
⚠️ Нам придется объединить наш пресловутый костер в префаб.
⚠️ Возможно нужно будет как-то синхронизировать состояния эмиттеров с помощью дополнительных компонент.

Какой вариант вам кажется более удобным?

#thunderengine #GameDev #VFX