По просьбам любопытствующих создал канал, в котором буду делиться мыслями и прогрессом в разработке игрового движка с открытым исходным кодом. Ознакомиться с репозиторием можно здесь.

Итак, немного о движке. Движок я начал разрабатывать примерно в 2007 году. До этого долго вынашивал идею. В то время движков было очень не много и многие писали свои. Я тоже решил пойти по этому увлекательному пути. За это время (почти 20 лет) движок 3 раза переписывался с нуля и каждый раз архитектура казалась все лучше и лучше. Последнее "переписывание" ядра было примерно 6-7 назад. И кажется сейчас, она выглядит достаточно стабильной и гибкой.

О возможностях движка. Движок написан на языке С++. Имеет редактор и утилиты для финальной сборки игрового билда. Он разрабатывается по модульному принципу. Пользователи могу добавлять собственные модули расширяя возможности как самого движка так и его редактора.
На данный момент я написал несколько основных модулей для работы с графикой:
- Рендер (OpenGL)
- Редактор Материалов (Shader Graph)
- Редактор текстур (Работа с атласами и прочее)
- Редактор эффектов
Так-же есть модуль отвечающий за обработку физики на основе Bullet3
Модуль скриптового движка (Angel Script)
А так-же ряд различных конвертеров игровых ресурсов.

Цель проекта не сделать "убийцу" UE5 или Unity, а сделать небольшой, удобный движок сопоставимый по качеству с Godot. Догнать любой из этих движков в одиночку НЕ ВОЗМОЖНО! Чисто человеческий ресурс не даст сделать это. Поэтому я просто пишу движок и стараюсь получить от этого удовольствие. Написание движков дает очень хороший буст к планированию архитектур и пониманию как оно работает "под капотом". Эти навыки были применены в различных профессиональных областях. Так, что если вам интересно, добро пожаловать в эту глубокую кроличью нору. 😏

Во всех игровых движках можно выделить 3 основных части:
1. Система игровых ресурсов - это загрузка ресурсов с диска или процедурная генерация.
2. Обработка игровой логики - отвечает за организацию игрового цикла и правила игры.
3. Вывод результатов работы - это рендеры графики, источников звука и т.п.

Так-же можно выделить (опционально) систему синхронизации состояний между игроками.

Основой всех игр являются данные, поэтому поговорим о системе ресурсов в Thunder Engine. Есть несколько базовых типов ресурсов и несколько вспомогательных. Полный список и их назначение я сейчас приводить не буду.
Во только некоторые из них:
- Texture - Ресурс хранящий в себе картинку которую можно показать на экране (Используется материалом)
- Material - По сути представляет из себя набор шейдеров, определяющих как визуально будет выглядеть объект. (Его цвет и фактура)
- Mesh - Ресурс отвечающий за форму игрового объекта. Состоит из набора треугольников и дополнительных служебных атрибутов.

Thunder Engine использует собственный формат хранения ресурсов. Он нужен для обеспечения скорости загрузки и избегания использования различных загрузчиков в момент работы игры. Конвертация ресурсов происходит в момент импорта ресурсов в редакторе. Конвертированная версия ресурса сохраняется в отдельню папку, для последующей упаковки.

Вторым неотъемлемым компонентом игры является игровая логика. в Thunder Engine базовым объектом является Actor. Вы найдете много схожих черт с GameObject в Unity. Каждый Actor может вмещать в себя коллекцию различных Компонент (Component) эти компоненты могут отвечать за различные аспекты игрового процесса. Отображение игровых ресурсов (Mesh, Sprite и т.п.). Источники звука. Триггеры и прочее. Пользователи могут создавать свои компоненты и добавлять их к Актерам на сцене. (Опять же очень похоже на Unity не так ли?). В целом для упрощения работы с движком, я постарался сделать API похожим на популярные решения. Так будет проще для всех. 😇

Последним столпом ядра движка являются Системы. Системы это невидимые пользователю труженики, обеспечивающие последовательность обработки игрового цикла. К примеру ResourceSystem отвечает за жизненный цикл всех игровых ресурсов. Она загружает их с диска и удаляет их когда они больше не требуются. RenderSystem отвечает за отрисовку игрового мира. Есть системы для обработки физики. Скриптовых сценариев и прочие веселые штуки. Обычно система работает либо с компонентами принадлежащими ей либо с ресурсами. Разумеется разработчики могут добавлять собственные системы в игровой цикл.

Итак после небольшого экскурса в историю и подводки к базовой архитектуре движка. Настало время рассказать чем я занимаюсь на данный момент. Чтош приступим. Относительно недавно я занялся рефакторингом модуля отвечающего за пользовательский интерфейс. В предыдущей версии вся система виджетов была частью основного ядра. Решение это было вынужденное и связанное с зависимостями на соседние модули. Благо их удалось развязать и выделить GUI в отдельный модуль. Что в свою очередь даст возможность отказаться пользователям от лишнего (если их не устроят мои кнопочки и панельки). Но это еще не все. Я обратил внимание на UI Toolkit в Юнити и некоторые полезные фичи решил сделать и у себя.

Встречайте:
UiLoader - компонент который может принимать в себя новый ассет UiDocument представляющий из себя xml репрезентацию вашего UI. Так-же этот XML можно положить из кода и он загрузит его! Чудеса не так-ли?
StyleSheet - Новый тип ассетов который представляет из себя CSS файл. Да да! Тот самый CSS!
Так-же CSS стили можно настраивать и из XML документа.

Разумеется система реализована очень базово и CSS возможности сильно обрезаны. Но фундамент заложен и в дальнейшем возможности можно будет расширять!

Давненько хотел добавить поддержку формата Spine 2D. Эта задача лежала в бэклоге аж с 2018 года. Как быстро летит время! Наконец, я на это решился! Формат файла (в JSON варианте) вызывает двойственные чувства. С одной стороны, он кажется избыточным в некоторых полях. А с другой стороны рядом с JSON находится файл атласа, который выглядит как нашлепка. Я не понимаю, почему нельзя было эти данные положить в сам JSON файл? Я специально не хотел использовать существующие рантаймы для отрисовки спайнов т.к. приводит к дублированию функционала и, одновременно, усложняет интеграцию. Поэтому решил попробовать конвертировать структуру в известные моему движку компоненты и ресурсы. Да возможно не все фичи будут поддерживаться на старте (привет бленд шейпы) но я обязательно расширю недостающие элементы (когда-нибудь >_<)

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

Решил немного прерваться со спайном и поправить баги которые нашел Павел Танонов в редакторе. Т.к. скоро релиз очередной версии (по плану конец Марта), необходимо максимально отполировать найденные проблемы. Очень помогает взгляд на движок со стороны. Спасибо большое Паше за эту возможность!

Эх сколько раз я зарекался делать крупный рефакторинг перед релизом! Но каждый раз хочется что-то улучшить в архитектуре. Вот и сейчас решил переработать Sprite ассет. До этого этот тип ассета был Solid (все данные хранились в нем самом) к такому типу относятся простейшие ассеты, которые нельзя разделить (текстуры, меши и т.п.). Противоположностью solid ассетам являются ассеты-контейнеры. Контейнеры, обычно, содержат в себе ссылки на другие ассеты и дополнительные, внутренние параметры, отвечающие за соединение solid ассетов. В новом релизе Sprite будет ассетом контейнером. т.к. теперь он будет поддерживать несколько страниц текстур, а так-же различные шейпы, представленные в виде мешей. Такой подход, в теории, позволит в будущем использовать повторно некоторые элементы, что положительно скажется на потреблении памяти. После этого рефакторинга, возможно возникновение новых проблем и регрессий. Но, со временем, я их все отловлю! Обещаю!

Интересную багу нашел Павел в системе скриптов! На данный момент движок поддерживает программирование игровой логики на скриптовом движке AngelScript. Очень достойный и недооцененный движок с поддержкой ООП, компиляцией кода в исполняемый байткод (что ускоряет загрузку) и клевой виртуальной средой исполнения. Короче оказалось, что в редакторе между сессиями симуляции игрового процесса не сбрасывались глобальные переменные, что приводило к странному поведению игровых юнитов (они отказывались двигаться). Фикс занял условно 10 строк. Спасибо Паша!