Чтобы блог не пустовал, решил с вами начать разработку движка.
Шутка. Я точно не знаю какая точка с запятой застряла во мне, но решил начать писать собственный движок на С++

Да не просто движок, а с особой системой представления классов - смесь унаследованной (ООП) и компонентной (ECS)

Про ООП (Объектно-ориентированное программирование):

В ООП классы представляют как цепочку, унаследование. Например:
- Объект -> Сущность -> Компонент Сцены -> Пешка -> Игрок (логика игрока)
Или:
- Объект -> Сущность -> Компонент Сцены -> Пешка -> Зомби (логика зомби)

Но... Если я хочу, чтобы игрок был с логикой зомби? Тут уже начинается проблема ООП программирования, именуемой "Алмаз Смерти". Класс можно унаследовать только от 1 родителя, без пересечений. То есть я не могу просто соединить Игрока и Зомби 
(А еще вставлю свои 5 копеек - тот же "Актор" в области Unreal Engine имеет много лишнего из-за слишком большой цепочки унаследования, что усложняет структуру движка и в будущем может убить оптимизацию)

Про ECS (Entity-Component-System - Сущность-Компонент-Система):

В ECS все представлено 3-мя основными понятиями - Сущность, Компонент и Система

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

И естетсвенно это решает проблему "Алмаза Смерти", ибо теперь игрока, зомби и зомби-игрока можно собрать из компонентов, а всю логику прописать в единственном центральном блоке (системе)

Но от такого подхода может пострадать структура движка, ведь тот же UI - зачем мне в нем компоненты? Когда надо обычное унаследование:
Главное меню -> Настройки -> Настройки графики

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

По началу я объединил логику лазеров в 1 класс, но тут произошел конфликт - лазерные кубики унаследованы от общего класса кубиков, и поэтому я не могу его унаследовать еще и класса с лазерами, поэтому.... Написал компонент для лазерных объектов + подсистему для обработки лазеров

В принципе это можно считать чем-то ECS, не учитывая что это больше как костыль, чем решение
(А один мой знакомый на Юнити так вообще написал 15+ компонентов и систем в 1-м игроке!! Емае, слава этому герою хвхвхв)

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

Root Engine
Движок, написанный на смешанности ECS и ООП. Да, я знаю - это безумно. В принципе еще никто особо не реализовывал это (Все говорят про минусы ООП в отличии от ECS, а никто не думал соединить их?)

Скажу сразу: Это чисто базовый эксперимент. У меня нет желания соревноваться с Unity, Unreal Engine, Godot и тд. Да, структура кода будет напоминать Unreal Engine - мне так привычней, как программисту на UE. Синтаксис интуитивно понятен и привычен

Немного про наш с вами план:
- Для начала напишем логику отображения окна и отделим логику от движка, чтобы в любой момент мы могли переписать модуль отображения окна и ничего не слетело
- Затем рааспишем структуру всего движка (рендера, математика и тд. - в дальнейшем расскажу)
- И самое главное... Рефлексия - это инструмент, который анализирует пользовательский код и разбивает его в понятный для движка код (раздрабливает) и загружает его в редактор (не перезапуская и не перекомпиируя сам движок). По сути этим можно назвать UHT - Unreal Header Tool, что генерирует файлы с вашим классом, но понятный для движка и затем движок применяет эти изменения. А вы думали откуда движок понимает, что такое UCLASS, UPROPERTY, UENUM и тд? :D (Интересный факт - почти у всех современных языков программирования С#, Java, Python и тд. - есть свои полностью реализованные под капотом инструменты рефлекси, А С++ увы... Будем учиться писать)

Вот такие пироги, считайте это наш 0-й день!

#RootEngine #PortalSolver

Наука рулит, сэр! Матеша

В общем хоть что-то закончено за день. Накинуты большинство типов данных, а также приступил к написанию RMesh, RRenderPipeline и тд.

Прогресс? Спокойная музыка, полный багаж матеши (Матрицы самое 💀) и попытка поболтать с OpenGL. Ему то GLAD подавай, то GLFW ему не нравится, то еще что-то... жесть просто

Умножение матриц 🤩

Даааааа
Чутка опоздал...
Но 3д заходит в чат

(уверяю вас это 3д хвхввх)

С++ и его небольшой "грязный" хак
Вызов функции из ничего =)

static bool _AutoRegister - Это статическая локальная переменная, инициализация которой происходит один раз при загрузке программы (перед началом main())

Вроде бы - и что с этого? Но именно в static переменную можно подложить свой код и он выполнится еще до загрузки всей программы! Хвхвхвххв, небольшой грязный трюк, но работает же)

Пишите чтобы вы такое положили до запуска движка 👀
Не волнуйтесь, статьей на всех хватит

Я говорил, что реализую создание систем без унаследования? Я сделал

Системы помечаются как RCLASS(System)

А затем на стадии компиляции регистрируются в движке (с небольшим хаком компилятора, а кому сейчас жить легко? хвхвхвх)

Я обещал - я сделал

Да, конечно сегодня планы были написать World и настроить камеру (чтобы камера хранила лишь основные данные, а дальше все камеры прогонялись через Render Pipeline, считайте система-компонент)

Но потерпел, завтра еще допишу регистрацию компонентов и.... Бинго! ГКМ будет написана и тогда можно будет реализовать все оставшиеся вещи

Напишу RObject - стандартный объект движка, RWorldObject - объект, который будет спавниться в мире (может еще подумаю над названием)

А позиции, физика, коллизия, рендер модели и камеры? Все будет компонентно и обрабатываться системами. От чего тот же RWorldObject может просто лежать в мире, или же иметь позицию

В общем ладно, день был необычным, всем спокойной ночи