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

Да не просто движок, а с особой системой представления классов - смесь унаследованной (ООП) и компонентной (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