Как устроен Unreal Engine: не API, а инженерное мышление

Это не статья о том, «как написать игру на Unreal». Это статья о том, почему движок вообще устроен именно так, как устроен — и если ты действительно поймёшь ход рассуждения ниже, ты сможешь сам предсказать архитектуру любой ещё не изученной тобой системы движка, вместо того чтобы каждый раз заучивать её заново.

01Что это?

Unreal Engine — не одна вещь, а слоёный пирог из нескольких разных инженерных решений, каждое из которых закрывает свою отдельную проблему: Engine (сам движок как программа и как готовая инфраструктура), Framework (модель управления, в которую встраивается твой код), UObject (объектная модель, общая для C++ и редактора), Reflection (способность движка «видеть» устройство твоих классов в рантайме) и Garbage Collector (автоматическое управление временем жизни объектов). Эта статья показывает, что все пять — не случайный набор фич, а одна цепочка причин и следствий: каждое следующее решение существует, потому что предыдущее создаёт проблему, которую нужно решить. Пройдя эту цепочку один раз осознанно, ты получаешь не пять фактов для запоминания, а один способ мышления, применимый к любой другой системе движка.

02Почему это существует?

Проблема: 1997 год, студия делает шутер

Представь команду, которая в 1997 году садится делать трёхмерный шутер. Чтобы игра вообще запустилась и на что-то отреагировала, нужно с нуля написать: отрисовку 3D-графики поверх видеокарты конкретного производителя, загрузчик 3D-моделей и текстур из файлов на диске, обработку ввода с клавиатуры и мыши, физику столкновений и гравитацию, звуковой движок, сетевой код для мультиплеера с учётом задержек сети, редактор уровней, чтобы дизайнеры вообще могли расставлять объекты не строчками кода, а мышкой, и систему сохранения/загрузки состояния игры. Ни одна из этих восьми вещей не имеет отношения к тому, что делает игру именно ЭТОЙ игрой, а не какой-то другой — это чистая инфраструктура, без которой игра физически не запустится, но которая сама по себе не является геймплеем.

Причина: инфраструктура не переносится между проектами сама по себе

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

Первая попытка решения — купить отдельные независимые библиотеки

Естественный следующий шаг — не писать всё с нуля, а взять готовые сторонние решения: сторонний рендер, сторонний физический движок вроде раннего PhysX, сторонний звуковой SDK — и написать свой код, который дёргает каждую библиотеку по отдельности.

03Какую проблему решает?

Ответ Epic на эту проблему — не «более удобная библиотека», а смена самой модели отношений между твоим кодом и инфраструктурой. Вместо того чтобы ты вызывал набор независимых библиотек и сам был точкой сборки всего проекта, движок сам становится точкой сборки: он владеет главным циклом программы, владеет общей моделью объектов, владеет редактором, владеет системой загрузки/сохранения — а твой код становится набором классов-расширений, которые движок использует в предсказуемых, заранее определённых местах. Это решает исходную проблему не «более быстрым письмом инфраструктуры», а тем, что подавляющую часть инфраструктуры вообще не нужно писать заново — Epic написала её один раз, и теперь она переиспользуется в каждом проекте на движке, а команда действительно тратит время на то, что отличает её игру от других.

04Как устроено?

Что такое Engine, и почему этого недостаточно для ответа на вопрос «что такое Unreal»

Слово «Engine» (движок) само по себе описывает только часть картины: набор технических подсистем, которые совместно превращают данные (модели, текстуры, звуки, код) в работающую интерактивную симуляцию — рендер, физика, звук, сеть, система ассетов. Это уже само по себе огромная инженерная работа, но если бы Unreal был «только» набором таких подсистем, доступных через API, он бы оставался тем самым набором независимых библиотек из раздела 2, просто написанным одной компанией, а не собранным из разных источников. То, что превращает набор технических подсистем в целостную систему, с которой удобно работать команде разработчиков — это не про рендер и не про физику, а про то, кто кем управляет. Именно на этот вопрос отвечает следующее понятие — Framework.

Что такое Framework — и почему Unreal Engine именно фреймворк, а не библиотека

Разграничение между библиотекой и фреймворком лежит отнюдь не в плоскости размера программного кода, количества предоставляемых функций или степени сложности API — один из наиболее показательных критериев такого разграничения, хотя и не единственный, как будет уточнено ниже, состоит в том, кому принадлежит управление архитектурой выполнения программы и кто, в конечном счёте, принимает решение о моменте вызова пользовательского кода.

В ситуации, когда разработчик обращается к обычной библиотеке (например, к утилите для чтения PNG-файлов), архитектурный контроль полностью сохраняется за ним: он располагает собственной функцией main(), самостоятельно организует главный цикл приложения и в произвольно выбранный момент времени инициирует вызов необходимой библиотечной функции — «загрузить файл», «обработать массив данных», «возвратить результат». Библиотека, в свою очередь, выступает исключительно как поставщик готовой функциональности, пребывая в пассивном ожидании обращения со стороны клиентского кода; она не обладает ни знанием о структуре вызывающего приложения, ни полномочиями вмешиваться в его жизненный цикл.

С фреймворком складывается диаметрально противоположная картина: он предоставляет разработчику не разрозненный набор утилит, а целостный каркас приложения, включающий в себя правила организации кодовой базы, предопределённую последовательность инициализации и уничтожения объектов, систему межкомпонентного взаимодействия, а также заранее специфицированные точки расширения, в которые пользовательский код может быть интегрирован. Именно к этому классу систем и относится Unreal Engine. Когда программист создаёт класс-наследник, скажем, AActor, он не конструирует собственный игровой цикл — точка входа программы жёстко закреплена за исполняемым модулем движка, тогда как его код оказывается встроенным в уже существующий жизненный цикл посредством реализации функций с фиксированными сигнатурами — BeginPlay, Tick, EndPlay; при этом движок самостоятельно и в строго определённом им самим порядке решает, когда именно следует вызывать каждую из этих функций. Тем самым метод, написанный разработчиком, превращается не в точку входа, а в точку расширения, активируемую внешней средой исполнения.

Данный архитектурный подход носит наименование инверсии управления (Inversion of Control, IoC) и заключается в том, что основной поток выполнения программы переходит из ведения пользовательского кода в ведение фреймворка, который диктует как последовательность, так и временны́е параметры вызова подключаемых модулей.

Обычная программа с библиотекой (управление у тебя):

int main() {
    Init();
    while (running) {
        ProcessInput();
        Update();
        Render();
    }
}

   → Главный цикл определяется разработчиком.
   → Порядок выполнения подсистем устанавливается им же.
   → Библиотека не инициирует вызовов;
     обращение к ней происходит по инициативе клиентского кода.


Класс внутри Unreal Engine (управление у фреймворка):

void ASA_Character::BeginPlay()
{
    /* твой код */
}

void ASA_Character::Tick(float DeltaTime)
{
    /* твой код */
}

   → main() закреплена за движком.
   → Unreal управляет созданием объектов и их временем жизни.
   → Движок определяет, когда активировать BeginPlay,
     с какой периодичностью вызывать Tick
     и в какой момент произвести финализацию объекта.
   → По завершении пользовательского кода движок продолжает
     свой цикл, последовательно обновляя физику, сеть,
     рендеринг и сопутствующие подсистемы.

   → Следовательно, пользовательская функция есть
     точка расширения, но отнюдь не точка входа.

Почему обычный C++ выбран как основа — и почему его одного недостаточно

Ограничение №1: бюджет кадра

Игра в реальном времени должна успевать пересчитать физику, ИИ, анимацию, рендер и игровую логику за один кадр. При 60 кадрах в секунду это 16.6 миллисекунды суммарно на всё перечисленное. Языки с автоматическим управлением памятью через сборщик мусора, который может в любой непредсказуемый момент «встать на паузу» и просканировать всю кучу (классическая модель ранней Java, а также большинства реализаций управляемых рантаймов) — вносят непредсказуемые паузы ровно тогда, когда сборщику заблагорассудится это сделать. Это недопустимо, когда бюджет кадра и так на пределе: одна такая пауза в середине боевой сцены — это заметный игроку рывок кадровой частоты (так называемый micro-stutter). C++ даёт прямой контроль над временем жизни объектов и раскладкой данных в памяти, необходимый для того, чтобы удерживать этот бюджет предсказуемо, кадр за кадром.

Ограничение №2: тысячи взаимно ссылающихся объектов, которыми управляет не только программист

Вывод из двух этих ограничений одновременно: нужен язык с ручным контролем над временем выполнения (значит — C++, а не управляемый язык с непредсказуемым GC), но при этом нужна защита от use-after-free для объектов, на которые ссылаются множество разных, не связанных друг с другом систем движка (значит — какая-то форма автоматического управления временем жизни, но только для этой конкретной категории объектов, а не для вообще всей памяти программы). Это ограничение — прямая причина всего, что описано дальше в этой статье: Unreal не выбирает между «быстрый, но опасный C++» и «безопасный, но с паузами managed-язык» — он строит третий вариант: производительный C++ как ядро, и тонкую, предсказуемую надстройку сборки мусора только для одной конкретной категории объектов (об этом — раздел про Garbage Collector).

Почему появился UObject

Ограничение из предыдущего раздела формулирует задачу: нужна отдельная категория объектов, для которых движок берёт на себя автоматическое управление временем жизни, интеграцию с редактором и сериализацию — но при этом основная масса кода движка (математика, контейнеры, низкоуровневые системы) остаётся обычным, «голым» C++ без этих накладных расходов. Ответ Epic — ввести явную границу: любой класс, которому нужны эти возможности, наследуется от общего базового класса UObject, и именно этот факт наследования — сигнал для всей остальной инфраструктуры движка (сборщика мусора, редактора, системы сериализации), что с этим конкретным объектом нужно обращаться по особым правилам. Обычные C++ классы, не отвечающие этим требованиям (например, простая математическая структура вроде вектора), остаются вне этой системы — и не платят за возможности, которые им не нужны.

Подробный разбор внутреннего устройства UObject — конструктора, Class Default Object, разницы между UObject и AActor — вынесен в отдельную статью (см. блок «что изучить дальше» в конце), потому что тема достаточно объёмная, чтобы заслуживать собственного полного разбора по этому же стандарту. Здесь важно зафиксировать только одно: UObject — это ответ на конкретное инженерное ограничение, а не произвольное архитектурное решение.

Почему появился Reflection

Введение UObject как границы решает вопрос «какие объекты особенные», но не решает следующий, не менее важный вопрос: как движковая инфраструктура — сборщик мусора, редактор, система сохранения — узнаёт, какие именно поля есть у твоего конкретного класса-наследника UObject, если сама эта инфраструктура написана один раз, задолго до того, как ты напишешь свой класс?

Обычный C++ стирает почти всю информацию о структуре типа после компиляции (это явление называется type erasure) — в скомпилированном бинарнике нет встроенного, доступного в рантайме списка «у класса ASwordActor есть поле float BaseDamage по такому-то смещению в памяти». Компилятор точно знает об этом на этапе сборки, но не оставляет это знание доступным программе во время выполнения. Для написания игрового кода этого обычно достаточно — ты и так знаешь имена своих полей на этапе написания кода. Но для написания универсального редактора, который должен уметь показать Details-панель для абсолютно любого класса, который когда-либо напишет любой программист на этом движке, включая классы, которые будут написаны через годы после релиза версии редактора — это ограничение фатально. Редактор физически не может быть написан так, чтобы «знать» заранее о каждом будущем классе каждого будущего проекта.

Решение — генерация кода поверх твоего класса, до основной компиляции

Epic решает эту проблему не изменением языка C++ (это было бы невозможно — компилятор C++ не подконтролен Epic), а дополнительным шагом сборки перед основной компиляцией: Unreal Header Tool (UHT) — отдельная программа, которая сканирует твои заголовочные .h файлы, находит специальные макросы (UCLASS, UPROPERTY, UFUNCTION) и генерирует дополнительный C++ код — файл .generated.h — который регистрирует структуру твоего класса в рантайм-системе движка: список полей, их типы, их смещения в памяти, список функций. Этот сгенерированный код и есть Reflection в Unreal — рантайм-доступная информация о структуре класса, синтезированная автоматически из твоего исходного кода до того, как обычный компилятор C++ вообще увидит файл.

Обычная сборка C++ проекта:

твой .cpp/.h файлы  →  компилятор (clang/MSVC)  →  бинарник
                        (информация о структуре класса
                         стирается после компиляции)


Сборка проекта на Unreal Engine:

твой .h файл с UCLASS()/UPROPERTY()
        │
        ▼
Unreal Header Tool читает .h, ВИДИТ макросы,
генерирует MyClass.generated.h — код, который
регистрирует структуру класса в UClass/FProperty
        │
        ▼
твой .cpp/.h + .generated.h  →  компилятор (clang/MSVC)  →  бинарник
                                 (теперь бинарник содержит и твою логику,
                                  И рантайм-описание структуры класса —
                                  редактор и GC могут прочитать его в рантайме)

Почему нужен Garbage Collector

Reflection решает проблему «движок знает структуру твоего класса в рантайме» — но это же самое знание оказывается ровно тем недостающим кусочком, который нужен для решения проблемы безопасного управления памятью, сформулированной в разделе 6: если система Reflection уже умеет находить все поля-указатели на другие UObject внутри твоего класса (через UPROPERTY, помечающий именно такие поля), то движок может построить полный граф ссылок между всеми живыми UObject-объектами в игре — кто на кого ссылается — и периодически обходить этот граф, начиная от заведомо «живых» корневых объектов (мир, GameInstance и подобные), помечая всё достижимое как живое, и удаляя всё недостижимое. Это и есть Garbage Collector Unreal — механизм, который стал возможен именно благодаря Reflection, а не появился независимо от него.

Упрощённая модель прохода GC (mark-and-sweep):

Корневые объекты (GameInstance, UWorld, объекты с AddToRoot)
        │
        ▼ обход по UPROPERTY-ссылкам (известным благодаря Reflection)
        │
   ┌────┴────┐
   ▼         ▼
Actor A   Actor B ──▶ Component X ──▶ InventoryItem Y
   │
   ▼
(если сюда никто больше не ссылается — объект НЕ помечен как живой)

После обхода: всё, что НЕ было помечено как достижимое,
считается мусором и освобождается при следующем проходе GC.

Важно, что этот GC работает не как в managed-языках вроде C# или Java — он не сканирует непредсказуемо в любой момент, а запускается по управляемому расписанию (обычно раз в некоторое количество секунд, точный интервал настраивается), и сам обход спроектирован так, чтобы укладываться в бюджет кадра, а не останавливать игру целиком. Это прямое следствие ограничения №1 из раздела 6 — предсказуемость важнее мгновенной реакции на освобождение памяти.

Как всё это связано — единая цепочка причин

Теперь, когда каждый элемент разобран по отдельности, стоит явно проследить всю цепочку целиком — потому что именно её целостность, а не отдельные факты, и есть главный урок этой статьи.

1. Проблема: писать всю инфраструктуру игры заново для каждого проекта — экономически нежизнеспособно.
2. Решение 1 — Framework: движок берёт управление главным циклом на себя (инверсия управления), твой код становится набором точек расширения.
3. Ограничение: движку реального времени нужен предсказуемый, быстрый язык без пауз managed-рантайма — выбран C++.
4. Новая проблема от этого выбора: ручное управление памятью на C++ для тысяч взаимно ссылающихся игровых объектов, которыми управляет не только программист, — источник use-after-free.
5. Решение 2 — UObject: явно выделенная категория объектов, для которых движок берёт на себя автоматическое управление и интеграцию с инфраструктурой; остальной C++ остаётся «обычным» и без этих накладных расходов.
6. Новая проблема от этого выбора: универсальный редактор и другая инфраструктура должны «знать» структуру абсолютно любого будущего класса — но C++ стирает эту информацию после компиляции.
7. Решение 3 — Reflection через UHT и макросы: отдельный шаг сборки генерирует рантайм-описание структуры класса из размеченного макросами исходного C++ кода.
8. Возможность, которую это открывает: зная граф UPROPERTY-ссылок между объектами, движок может автоматически находить недостижимые объекты.
9. Решение 4 — Garbage Collector: периодический, управляемый по расписанию обход этого графа, освобождающий недостижимые UObject.

Влияние на Blueprint

Blueprint — визуальный язык программирования Unreal — не отдельная, независимо построенная система поверх C++. Он напрямую паразитирует (в хорошем смысле) на инфраструктуре Reflection, описанной выше: когда UHT генерирует рантайм-описание твоего класса из UPROPERTY/UFUNCTION, ровно это же описание использует редактор Blueprint, чтобы показать твоё C++ поле как настраиваемый пин на ноде или твою C++ функцию как вызываемую ноду в графе. Blueprint не «знает» о твоём классе никаким отдельным путём — он видит ровно то же самое рантайм-описание структуры, что и GC, и редактор Details-панели, и система сериализации. Это объясняет практическое следствие, которое иначе выглядело бы как произвольное правило: если ты хочешь, чтобы дизайнер увидел твоё поле или функцию в Blueprint, единственный способ — тот же самый механизм Reflection (UPROPERTY(BlueprintReadWrite), UFUNCTION(BlueprintCallable)), а не какой-то отдельный «Blueprint API».

05Когда рассуждать в этих категориях — и когда это избыточно

Это единственная адаптация раздела «когда использовать / когда не использовать» под тему, у которой нет единственной функции с сигнатурой — здесь «использование» означает «применение этого способа рассуждения», а не «вызов конкретного API».

Как этим можно злоупотребить

У самого способа мышления тоже есть цена, и её можно платить впустую. Прогонять полную цепочку «проблема → ограничение → решение» для каждой мелкой правки — например, останавливаться и раздумывать об архитектурных причинах перед тем, как поменять число в уже существующей, давно устоявшейся настройке компонента — не инженерная строгость, а паралич анализа: время, которое можно было потратить на реальную задачу, уходит на пересборку рассуждения, которое уже давно проделала команда Epic и, скорее всего, твоя собственная команда тоже. Признак того, что рассуждение зашло не туда — если оно занимает больше времени, чем сама правка кода, а результат всё равно совпадает с очевидным, стандартным решением.

Как это использует сама Epic

Показательный факт: даже сам редактор Unreal Engine — не отдельная программа, написанная в обход этой архитектуры, а такое же Unreal-приложение, построенное на том же самом фреймворке, что и твоя игра. Классы вроде UCharacterMovementComponent, отвечающего за движение персонажа, не имеют собственного отдельного «привилегированного» способа получать управление каждый кадр — они точно так же переопределяют TickComponent, ту же самую точку расширения, доступную и твоему собственному компоненту. Когда ты открываешь исходный код этого класса (полезный навык, отдельно разбираемый в других статьях энциклопедии) и видишь знакомую сигнатуру TickComponent, ты видишь не «магию движка», а тот же самый механизм, которым пользуешься сам — просто применённый Epic к более сложной задаче. Это прямое следствие инверсии управления: у движка нет обходного, закрытого от остальных способа получать управление в обход системы, которую он сам же и предоставляет всем разработчикам.

06Типичные ошибки

07Практика

08Частые вопросы

09Что читатель должен начать замечать

После этой статьи незнакомый макрос или спецификатор в чужом коде перестаёт быть поводом просто скопировать его из туториала — вместо этого возникает рефлекс спросить, какую именно инфраструктуру движка (GC, редактор, Blueprint, сериализацию) он подключает, и заплачена ли эта цена не зря.

Указатель на UObject без UPROPERTY в чужом или своём коде теперь читается не как мелкая недоработка, а как потенциальный use-after-free — потому что после раздела про Garbage Collector ясно: невидимость для GC не абстрактный риск, а прямое следствие того, как устроен обход графа ссылок.

А при столкновении с любой новой, ещё не изученной системой движка (Niagara, Mass Entity, Chaos) естественным первым вопросом становится не «как этим пользоваться», а «какую проблему предыдущего слоя архитектуры она решает, и какое новое ограничение порождает» — тот самый способ мышления, который эта статья описывает как главный урок, а не набор из пяти фактов.

10Итоги

• Unreal Engine — фреймворк, а не библиотека: он владеет главным циклом программы, и твой код — это набор точек расширения, вызываемых движком в заранее определённых местах (инверсия управления), а не набор функций, которые ты вызываешь сам и в том порядке, который выбираешь сам.
• Инверсия управления — не эстетика, а единственный способ сделать один и тот же движок переиспользуемым между проектами с разной игровой логикой: движок гарантирует один корректный порядок инициализации для любого проекта, а твоя ответственность сужается до заполнения уже безопасных точек расширения.
• C++ выбран как язык реализации из-за жёсткого бюджета кадра: managed-языки с непредсказуемым GC вносят паузы, которые движок реального времени не может себе позволить, — но и чистый C++ с ручным new/delete не масштабируется на тысячи взаимно ссылающихся объектов, временем жизни которых управляет не только программист, а ещё редактор, загрузка уровней и сеть.
• UObject — не «базовый класс для всего», а осознанно проведённая граница: по одну сторону — объекты, за которых движковая инфраструктура (GC, редактор, сериализация, сеть) берёт на себя ответственность и накладные расходы; по другую — обычный C++, который эту цену не платит, потому что она ему не нужна.
• Reflection существует потому, что универсальной инфраструктуре движка (редактору, сериализации) нужно «знать» структуру абсолютно любого, в том числе ещё не написанного класса, а обычный C++ стирает эту информацию после компиляции — Unreal Header Tool восстанавливает её отдельным шагом сборки, генерируя рантайм-описание класса из UCLASS/UPROPERTY/UFUNCTION.
• Garbage Collector стал возможен именно благодаря Reflection, а не появился независимо от неё: зная через UPROPERTY, какие поля — ссылки на другие UObject, движок способен построить граф достижимости и освобождать недостижимые объекты по управляемому, предсказуемому расписанию, а не в произвольный момент.
• Blueprint не имеет собственного, отдельного от C++ источника знаний о твоих классах — он читает ровно то же Reflection-описание, что и GC и редактор Details-панели, поэтому единственный способ сделать поле или функцию доступной дизайнеру — тот же UPROPERTY/UFUNCTION, что использует остальная инфраструктура.
• Это не пять изолированных фактов, а одна цепочка причин и следствий, и запоминать стоит именно цепочку: «какую проблему предыдущего слоя решает эта система, и какое новое ограничение она в свою очередь порождает» — вопрос, применимый к любой ещё не изученной системе движка, включая те, что появятся в Unreal уже после того, как ты пройдёшь эту энциклопедию.