Document Faset architecture and roadmap through MVP
This commit is contained in:
Emil
@@ -0,0 +1,128 @@
|
||||
# 03. Сравнение существующих подходов
|
||||
|
||||
**Статус на 18.09.2026.** Исследование и проектные решения, не описание реализованного движка. Канонические решения — [ARCHITECTURE.md](../ARCHITECTURE.md), порядок до и после MVP — [PLAN.md](../../PLAN.md). Сведения о других движках сохраняются как исследовательский контекст; прежние рекомендации, помеченные **superseded**, не задают стек Faset.
|
||||
|
||||
Матрица ниже — история оценки чужих подходов, не обещание реализовать все перечисленные возможности. Выбор Faset уже сделан: C++/EnTT, собственные retained C++ UI и Vulkan 1.3 renderer/RenderGraph, Slang/SDL3, CMake/Ninja/Clang и clang-cl, Box2D/Box3D; Lua добавляется отдельным обязательным этапом и остаётся необязательным для конкретной игры. MCP ограничен редакторским authoring/import/build/PlayStop/logs, отсутствует в Player и не инспектирует runtime world.
|
||||
|
||||
Это не таблица «лучший engine». У каждого проекта другая целевая цена сложности. Вопрос: какую идею забрать в новый движок, а какую не импортировать.
|
||||
|
||||
## 1. Сводная матрица
|
||||
|
||||
| Движок/подход | Сильный mental model | Что особенно полезно | Цена/риск | Вывод для нового движка |
|
||||
|---|---|---|---|---|
|
||||
| Godot | Node + Scene + Resource | композиция сцен, единый editor, простая project structure, remote scene/debug | Node легко превращается в object soup; 2D/3D имеют отдельные типы; физика не обещает determinism | взять scene/resource UX и explicit 2D/3D parity; remote inspection оставить сравнением, без runtime MCP |
|
||||
| Unity | GameObject + Component + Prefab + Asset Database | быстрый authoring, prefab variants, package model, большой ecosystem | скрытое состояние import/cache, сложный execution order, heavy editor/runtime coupling | взять prefab overrides, actions, frame debugger; сделать source/cache boundaries более прозрачными |
|
||||
| Unreal | Actor/Component + Level/Asset + отражение | мощные editor tools, world/level authoring, Details/Outliner, trace/Insights, source-control UX | высокая когнитивная и build complexity, tick/GC/reflection pitfalls | взять details/outliner/trace patterns; не следовать enterprise-scale breadth |
|
||||
| O3DE | Entity Component System + Editor/Runtime/System components + Gems | четкая component composition, Asset Processor, modular Gems, editor/runtime split | большой surface area, много abstractions, тяжелый onboarding | взять component categories, asset pipeline, plugins; держать API меньше |
|
||||
| Bevy | ECS World + Resources + Systems + plugins | data-driven composition, explicit schedules, modular render/asset systems, code-first ergonomics | code-first UX, evolving APIs, ECS complexity для новичка | взять explicit schedule/resources/plugin boundaries; добавить визуальный authoring layer |
|
||||
|
||||
## 2. Godot: композиция и маленький проект
|
||||
|
||||
Godot явно строит философию вокруг object-oriented composition, scenes как reusable units и возможности сочетать editor и code ([design philosophy](https://docs.godotengine.org/en/stable/getting_started/introduction/godot_design_philosophy.html)). Scene Tree и FileSystem легко объяснить новичку. Inspector, Project Settings и editor plugins превращают metadata в UX surface ([Inspector](https://docs.godotengine.org/en/stable/tutorials/editor/inspector_dock.html), [Project Settings](https://docs.godotengine.org/en/stable/tutorials/editor/project_settings.html), [EditorPlugin](https://docs.godotengine.org/en/stable/classes/class_editorplugin.html)).
|
||||
|
||||
**Перенять:**
|
||||
|
||||
- любой node/subtree может стать сценой;
|
||||
- сцена открывается и запускается независимо;
|
||||
- ресурсы имеют собственное редактирование;
|
||||
- import errors видны рядом с ассетами; remote scene Godot сохраняется здесь как сравнение, не требование runtime MCP Faset.
|
||||
|
||||
**Не перенять без критики:**
|
||||
|
||||
- смешивание lifecycle, hierarchy и behaviour в огромном количестве Node types;
|
||||
- неявные глобальные singletons как основной способ коммуникации;
|
||||
- отдельные 2D/3D API там, где общий concept был бы удобнее.
|
||||
|
||||
## 3. Unity: скорость результата и prefab contract
|
||||
|
||||
Unity показывает, насколько powerful один consistent loop `GameObject → Component → Inspector → Prefab → Play`. Prefab поддерживает nested instances и variations ([Prefabs](https://docs.unity3d.com/6000.1/Documentation/Manual/Prefabs.html)); контекстный Prefab Mode и breadcrumbs уменьшают риск редактировать не тот уровень ([Prefab Mode](https://docs.unity3d.com/6000.5/Documentation/Manual/EditingInPrefabMode.html)). Asset Database разделяет source, meta identity и cached artifacts ([Asset Workflow](https://docs.unity3d.com/2019.3/Documentation/Manual/AssetWorkflow.html)).
|
||||
|
||||
**Перенять:**
|
||||
|
||||
- inspector-driven authoring;
|
||||
- prefab instance source/override visualization;
|
||||
- named action input вместо raw keys;
|
||||
- Frame Debugger, который делает render pipeline пошагово обозримым ([Frame Debugger](https://docs.unity3d.com/Manual/FrameDebugger.html)).
|
||||
|
||||
**Не перенять без критики:**
|
||||
|
||||
- dependency на opaque generated Library/cache;
|
||||
- «магический» execution order; scheduling should be explicit;
|
||||
- authoring-правки компонентов в обход общего command/history layer. Gameplay изменяет runtime-компоненты через runtime API без редакторского Undo; structural changes применяются через отдельный runtime command buffer.
|
||||
|
||||
## 4. Unreal: масштабируемая authoring-система
|
||||
|
||||
Unreal показывает ценность богатого Outliner + Details panel: actor можно найти в иерархии и редактировать свойства в контексте ([Level Editor](https://dev.epicgames.com/documentation/en-us/unreal-engine/level-editor-in-unreal-engine), [Details panel](https://dev.epicgames.com/documentation/en-us/unreal-engine/level-editor-details-panel-in-unreal-engine)). Source Control встроен в Content Browser и показывает checkout/history/diff ([Source Control](https://dev.epicgames.com/documentation/en-us/unreal-engine/source-control-in-unreal-engine)). Tick groups и dependencies делают порядок работы подсистем явным ([Actor Ticking](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-ticking-in-unreal-engine)). Unreal Insights демонстрирует, что trace должен включать gameplay, objects, physics и cook, а не только FPS ([Insights](https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-insights-reference-in-unreal-engine-5)).
|
||||
|
||||
**Перенять:**
|
||||
|
||||
- Outliner/Details split;
|
||||
- human-readable reflection metadata;
|
||||
- explicit runtime/editor distinction;
|
||||
- trace channels и frame/object history;
|
||||
- asset source-control status.
|
||||
|
||||
**Не перенять:**
|
||||
|
||||
- broad enterprise feature set;
|
||||
- повсеместный per-actor ticking;
|
||||
- сложную рефлексию без генерации schema и compile-time validation.
|
||||
|
||||
## 5. O3DE: component boundaries и pipeline
|
||||
|
||||
O3DE формулирует entity/component model, причем компоненты могут объявлять required/provided services, что предотвращает невалидное состояние entity. Отдельные editor components и system components — полезная архитектурная граница ([ECS overview](https://www.docs.o3de.org/docs/user-guide/programming/components/overview)). O3DE также явно выделяет Asset Processor, authoring tools, plugins и build system ([Key Concepts](https://docs.o3de.org/docs/welcome-guide/key-concepts)).
|
||||
|
||||
**Перенять:**
|
||||
|
||||
- schema-level component dependencies;
|
||||
- editor component, runtime component, system service;
|
||||
- importer/processors as first-class pipeline;
|
||||
- modules/plugins with declared dependencies.
|
||||
|
||||
**Осторожно:**
|
||||
|
||||
- dependency graph component-услуг не должен быть непостижимым; показывать его в Inspector;
|
||||
- не создавать micro-service архитектуру внутри маленького движка.
|
||||
|
||||
## 6. Bevy: explicit data flow и systems
|
||||
|
||||
Bevy предлагает code-first ECS, typed Assets и plugin composition. В релизных материалах подчеркиваются modularity, render phases, entity/component-driven draw functions и explicit resources ([Bevy 0.6](https://bevy.org/news/bevy-0-6)); новый scene system делает сцены composable, patchable и dependency-aware ([Bevy 0.19](https://bevy.org/news/bevy-0-19)).
|
||||
|
||||
**Перенять:**
|
||||
|
||||
- schedule phases и typed `Res`/components;
|
||||
- asset handles + async loading;
|
||||
- plugins as composition units;
|
||||
- render extraction вместо обращения gameplay напрямую к GPU.
|
||||
|
||||
**Не перенять:**
|
||||
|
||||
- code-only authoring как единственный путь;
|
||||
- нестабильную публичную surface без compatibility policy;
|
||||
- предположение, что ECS автоматически делает every workload faster.
|
||||
|
||||
## 7. Синтез
|
||||
|
||||
Сильнейший общий паттерн не «ECS» и не «scene graph», а наличие **понятного authoring contract**:
|
||||
|
||||
```text
|
||||
Object in editor
|
||||
= stable identity
|
||||
+ inspectable schema
|
||||
+ composable parts
|
||||
+ explicit references
|
||||
+ reversible changes
|
||||
+ runtime mapping
|
||||
```
|
||||
|
||||
Для нового движка разумно выбрать:
|
||||
|
||||
- Godot-подобную простоту сцен;
|
||||
- Unity-подобный prefab/Inspector loop с nested composition и явными overrides; variants и Apply to template — после MVP;
|
||||
- Unreal-подобные trace/Outliner/Details;
|
||||
- O3DE-подобное разделение editor/runtime/system и Asset Processor;
|
||||
- Bevy-подобные schedules/plugins/render extraction.
|
||||
|
||||
И сознательно не переносить их масштаб, legacy и неявные соглашения.
|
||||
|
||||
Прежние варианты C#/Flecs, готовый UI toolkit и прямое редактирование Player через automation **superseded**. Blender используется в официальной сборке: обычный glTF/GLB импорт самодостаточен; optional Python add-on добавляет устойчивые IDs и удобную кнопку экспорта. Его отсутствие не блокирует импорт, но ограничивает гарантии reimport после rename частей. MVP — два маленьких 2D/3D-демо с baseline PBR/тенями и самостоятельным экспортом под Linux/Windows; передовые графические технологии развиваются после него.
|
||||
Reference in New Issue
Block a user