ECS 架构

Entity-Component-System——数据驱动设计的游戏架构, SoA 内存布局, Archetype, 稀疏集。

概念

ECS (Entity-Component-System) 是现代游戏引擎的核心数据架构，与传统的 OOP 继承树完全相反。在 ECS 中: Entity 只是一个 ID, Component 是纯数据 (无行为), System 是纯逻辑 (无状态)。这种分离带来三个根本优势: 缓存友好的数据布局 (SoA), 自然的并行化, 极高的模块复用性。

核心概念对比

概念	OOP 继承	ECS
对象定义	class Player : Entity { … }	Entity ID = 42
数据	成员变量散布在继承树的各层	Component: Position{x,y,z}, Velocity{vx,vy,vz}
行为	成员方法 + 虚函数	System: MoveSystem(Position, Velocity)
内存布局	AoS (Array of Structs)	SoA (Struct of Arrays)
扩展方式	继承新类	添加新 Component 或新 System

ECS 基础模型

Entity: [ID=1001] // 无数据, 仅标识符
Entity: [ID=1002]
Entity: [ID=1003]

Components (按类型存储, SoA):
 Position: [(1001: 0,1,0), (1002: 5,2,1), (1003: -1,3,0)]
 Velocity: [(1001: 1,0,0), (1003: 0,0,1)]
 Health: [(1001: 100), (1002: 50), (1003: 200)]
 PlayerTag: [(1001)]
 EnemyTag: [(1002), (1003)]

Systems:
 MoveSystem: FOR (Position, Velocity) ← 查询拥有这两个组件的实体
 position += velocity * dt
 // 只遍历: (1001), (1003) — 因为有 Position + Velocity
 DamageSystem: FOR (Health, EnemyTag)
 ...
 RenderSystem: FOR (Position, Model)
 ...

内存布局: AoS vs SoA

AoS (Array of Structs) — OOP 方式:
 struct Entity {
 Position pos;
 Velocity vel;
 Health hp;
 };
 内存: [pos|vel|hp] [pos|vel|hp] [pos|vel|hp] ...
 问题: MoveSystem 只需要 pos 和 vel, 但 hp 也被加载到缓存 (浪费)

SoA (Struct of Arrays) — ECS 方式:
 Position[] pos_array = {(0,1,0), (5,2,1), ...};
 Velocity[] vel_array = {(1,0,0), (0,0,1), ...};
 内存: [pos|pos|pos|...] [vel|vel|vel|...]
 优势: MoveSystem 遍历时, 所有 pos 连续存放, 缓存命中率最大化

Archetype (原型)

Archetype = 一组特定 Component 类型的集合

例如:
 Archetype<Position, Velocity, Health, PlayerTag> → 实体 1001
 Archetype<Position, Health, EnemyTag> → 实体 1002, 1003
 Archetype<Position, Velocity> → 无实体

原型存储 (Unity DOTS / Bevy 方式):
 每个 Archetype 内存块连续存储其实体的所有 Component:

 Chunk (Archetype<Position, Velocity, Health, PlayerTag>, 容量=64):
 [Pos][Pos]...[Pos] [Vel][Vel]...[Vel] [HP][HP]...[HP] [EntityID...]
 <-- 64 个实体, 每列连续排列 -->

迭代效率:
 MoveSystem 需要: Position + Velocity
 匹配的 Archetype: Archetype<Position, Velocity, Health, PlayerTag>
 Archetype<Position, Velocity>
 遍历这些 Archetype 的 Chunk, 逐列读取 → 极佳缓存友好

Sparse Set (稀疏集)

另一种 ECS 存储方案 (EnTT, flecs):

Sparse Set 实现:
 // 每个 Component 类型有一个 Sparse Set
 SparseSet<Position>:
 sparse[]: // Entity → 索引 (大小 = max_entity_count)
 dense[]: // 索引 → Entity 实际数据
 packed[]: // [Position{0,1,0}, Position{5,2,1}, Position{-1,3,0}]

 查询 Position + Velocity:
 选择 dense 更小的 SparseSet, 遍历其 dense
 检查每个 Entity 是否也存在于另一个 SparseSet 中
 // O(min(|A|, |B|)) 迭代, O(1) 检查

 添加/删除 Component = SparseSet 的插入/删除 = O(1)
 比 Archetype 更灵活 (不需要移动 Archetype)
 但缓存局部性不如 Archetype 方案

---