ECS由浅入深第一节
ECS由浅入深第二节
ECS由浅入深第三节
在 ECS 中，System 是负责所有逻辑处理的地方。它们观察、筛选并操作 Entity 的 Component 数据，从而驱动整个游戏世界的运转。本篇将深入探讨 System 的运行机制、数据流处理，以及在纯数据驱动的 ECS 环境下如何实现各种复杂的行为和交互。
System 的生命周期与调度
在一个通用的 ECS 框架中，System 通常会遵循一个简单的生命周期：
- 初始化 (
OnCreate)： System 在其生命周期开始时（通常是游戏启动时）被调用一次，用于初始化内部状态或缓存必要的数据。 - 更新 (
OnUpdate)： 这是 System 最核心的方法，在每个游戏帧或固定的时间步长内被反复调用。System 在此方法中执行其主要逻辑，遍历 Entity 并处理 Component 数据。 - 销毁 (
OnDestroy)： System 在被销毁时（通常是游戏结束或 System 被移除时）被调用一次，用于清理资源，例如释放原生内存（Native Memory）或解除事件订阅。
在我们简化的 ISystem 接口中，我们已经有了 OnUpdate。OnCreate 和 OnDestroy 可以在 GameLoop 管理 System 的添加和移除时调用。
// ISystem (回顾)
public interface ISystem
{
void OnCreate(EntityManager entityManager); // 新增 OnCreate
void OnUpdate(EntityManager entityManager);
void OnDestroy(EntityManager entityManager); // 新增 OnDestroy
}
// 示例：可以有一个 SystemManager 来管理 System 的生命周期和调度
public class SystemManager
{
private List<ISystem> _systems = new List<ISystem>();
private EntityManager _entityManager;
public SystemManager(EntityManager entityManager)
{
_entityManager = entityManager;
}
public void AddSystem(ISystem system)
{
_systems.Add(system);
system.OnCreate(_entityManager); // 调用创建生命周期
}
public void UpdateAllSystems()
{
foreach (var system in _systems)
{
system.OnUpdate(_entityManager); // 调用更新生命周期
}
}
public void RemoveSystem(ISystem system)
{
system.OnDestroy(_entityManager); // 调用销毁生命周期
_systems.Remove(system);
}
public void Dispose()
{
// 销毁所有系统
foreach (var system in _systems)
{
system.OnDestroy(_entityManager);
}
_systems.Clear();
}
}
在实际的 ECS 框架中，System 的调度会更加复杂。例如，Unity DOTS 会使用 System Group 来组织 System 的执行顺序，并允许你指定 System 在哪个 Group 中执行，以及相对于其他 System 是提前或延后执行。这对于确保数据依赖正确性和逻辑执行顺序至关重要（例如，移动系统应在渲染系统之前运行）。
ECS 中的行为与状态管理
在传统 OOP 中，一个对象的行为和状态通常封装在其类中。但在 ECS 中，System 如何实现复杂的行为和状态变化呢？答案是：通过读取、修改和添加/移除 Component。
状态通过 Component 表示： 任何需要跟踪的“状态”都应该是一个 Component。
Health { public int Value; }IsAttacking { public bool Value; }CurrentTarget { public Entity Value; }
行为通过 System 驱动状态变化： System 遍历拥有特定状态 Component 的 Entity，并根据逻辑修改这些状态 Component。
例如，一个 AI 行为系统可能这样工作：
AIStateSystem： 遍历拥有AIComponent和Position的 Entity。根据它们当前的AIState(Component) 和周围环境（也可能是其他 Entity 的 Component），决定下一个目标位置，并将结果写入该 Entity 的TargetPositionComponent。MovementSystem： 遍历拥有Position和TargetPositionComponent的 Entity，根据TargetPositionComponent更新Position和Velocity。
这样，行为就被分解成了多个小块的 System，每个 System 负责一部分数据转换。
ECS 中的事件系统设计
由于 Component 都是纯数据，且 System 独立运行，传统的观察者模式或事件委托机制在 ECS 中会带来额外的复杂性和性能开销（例如，GC 压力）。ECS 更倾向于一种**“数据驱动的事件”或“基于 Component 的事件”**模式。
以下是几种常见的 ECS 事件处理模式：
1. 基于一次性 Component 的事件（One-Shot Component）
这是最简洁直观的方式。当一个事件发生时，我们不触发一个回调，而是给相关的 Entity 添加一个特殊的“事件 Component”。然后，一个专门的 System 会在下一帧（或某个固定时间）遍历这些事件 Component，处理完后将它们移除。
- 优点： 简单、高效、易于并行化、无 GC。
- 缺点： 事件是单帧处理，如果需要跨多帧响应，或者事件处理逻辑复杂，可能需要更精细的设计。
示例：DamageEvent
- 定义一个事件 Component：
public struct DamageEvent : IComponentData { public int DamageAmount; public Entity Instigator; // 谁造成了伤害 } - 当发生伤害时，给被伤害的 Entity 添加
DamageEvent：// 假设在某个攻击 System 中 public void DealDamage(EntityManager em, Entity targetEntity, int amount, Entity attacker) { em.AddComponent(targetEntity, new DamageEvent { DamageAmount = amount, Instigator = attacker }); } DamageReactionSystem处理伤害事件：public class DamageReactionSystem : ISystem { public void OnCreate(EntityManager em) { } public void OnDestroy(EntityManager em) { } public void OnUpdate(EntityManager entityManager) { Console.WriteLine("--- Running DamageReactionSystem ---"); // 遍历所有拥有 Health 和 DamageEvent 的 Entity foreach (var (entity, health, damageEvent) in entityManager.ForEach<Health, DamageEvent>()) { // 注意：由于 GetComponent 返回的是 struct 副本，直接修改 health.Value 是无效的 // 必须重新AddComponent来更新，或通过特殊机制（如指针/NativeArray） // 我们的简化框架需要先移除再添加，实际高效框架会直接在内存中修改 Health newHealth = health; newHealth.Value -= damageEvent.DamageAmount; entityManager.RemoveComponent<Health>(entity); entityManager.AddComponent(entity, newHealth); Console.WriteLine($" Entity {entity} took {damageEvent.DamageAmount} damage from {damageEvent.Instigator}. New Health: {newHealth.Value}"); // 处理完事件后，移除 DamageEvent Component entityManager.RemoveComponent<DamageEvent>(entity); } } }- 在
GameLoop中加入DamageReactionSystem。
2. 基于 Buffer Component 的事件队列 (BufferElementData)
对于需要记录一系列事件，或者事件需要跨帧处理的场景，Buffer Component（在 Unity DOTS 中是 IBufferElementData）是更合适的选择。它允许一个 Entity 拥有一个可变大小的数组来存储数据。
- 优点： 灵活处理多个事件、适合历史记录或队列。
- 缺点： 相比一次性 Component 稍微复杂一点点。
示例：伤害记录
// 定义一个 Buffer Element，表示一次伤害记录
public struct DamageRecord : IComponentData // 在通用 ECS 中，可以也用 IComponentData 接口表示
{
public int Amount;
public Entity Source;
public float TimeStamp;
}
// EntityManager 可以扩展 AddBuffer/GetBuffer 方法来管理这种可变长度的 Component
// 比如：Dictionary<Entity, Dictionary<Type, List<IComponentData>>> 来存储 Buffer
// 这里为简化，暂不实现完整的 AddBuffer/GetBuffer 方法，只作为概念阐述。
// 假设我们可以给 Entity 添加一个 List<DamageRecord> 作为它的一个“Component”
// （在真实 ECS 中这会是专门的 BufferComponent 机制）
// 当发生伤害时，将 DamageRecord 添加到 Entity 的 DamageRecord 列表中
// DamageHistorySystem 遍历这些列表进行分析，并清空或保留部分记录。
3. 单例 Component 作为事件总线
在某些需要全局事件分发但又想保持 ECS 风格的场景，可以创建一个单例 Entity（只存在一个实例的 Entity），并给它添加一个特殊的 Component 作为事件队列。System 可以向这个队列发送事件，其他 System 则从这个队列读取并处理事件。
- 优点： 集中式事件管理。
- 缺点： 可能违背一些 ECS 独立性原则，慎用。
Entity 之间的交互：如何“找”到彼此？
在 ECS 中，System 如何让 Entity 之间进行互动呢？毕竟 Entity 只是 ID，没有直接的引用关系。答案是：通过 Component 存储 Entity ID。
引用其他 Entity 的 Component：
如果 Entity A 需要引用 Entity B，可以在 Entity A 的某个 Component 中存储 Entity B 的 ID。public struct TargetComponent : IComponentData { public Entity TargetEntity; }System 在处理
TargetComponent时，可以通过TargetEntity的 ID 从EntityManager中获取其 Component 数据。// 在一个攻击 System 中 foreach (var (attackerEntity, targetComp) in entityManager.ForEach<AttackerComponent, TargetComponent>()) { // 假设 AttackerComponent 包含了攻击力 // 获取目标 Entity 的 Health Component Health targetHealth = entityManager.GetComponent<Health>(targetComp.TargetEntity); if (targetHealth.Value > 0) { // DealDamage 是我们上面定义的辅助方法 DealDamage(entityManager, targetComp.TargetEntity, 10, attackerEntity); } }父子关系与层级结构：
传统的GameObject有Transform组件来构建父子层级。在 ECS 中，这也可以通过 Component 来实现：public struct ParentComponent : IComponentData { public Entity ParentEntity; } public struct ChildComponent : IComponentData { // 存储子 Entity 的 ID，如果一个父 Entity 有多个子 Entity，可能需要 Buffer Component }然后，一个专门的
TransformSystem负责根据ParentComponent来更新子 Entity 的世界坐标 (WorldPosition) Component，确保子 Entity 的位置相对于父 Entity 正确更新。通过查询找到 Entity (EntityQuery)：
System 不会直接遍历所有 Entity。它们会使用查询 (Query) 机制，只获取那些拥有特定 Component 组合的 Entity。
在我们简化的EntityManager中，ForEach<T1, T2>()方法就是一种简单的查询。真实的 ECS 框架会提供更强大和高效的查询 API，例如 Unity DOTS 的EntityQuery，它允许你指定：WithAll<T1, T2>：必须拥有所有这些 Component。WithAny<T1, T2>：拥有这些 Component 中的任意一个。WithNone<T1, T2>：不拥有这些 Component。Exclude<T1>：排除拥有这些 Component 的 Entity。ReadOnly<T1>：只读访问 Component，这有助于并行化。
这些查询机制让 System 能够精确地锁定它们需要处理的数据，从而提高效率和清晰度。
结构体与引用类型 Component 的考量
在设计 ECS Component 时，我们强烈推荐使用 struct（值类型） 作为 Component。
- 优点：
- 内存高效： 值类型通常分配在栈上或连续的内存块中，减少了堆内存分配和垃圾回收（GC）的压力。
- 缓存友好： 连续存储有助于 CPU 缓存命中。
- 隐式复制： 传递时是值拷贝，避免了意外的副作用。
- 缺点： 无法包含引用类型字段（如
string,class对象），需要小心设计。
如果确实需要在 Component 中存储引用类型数据（例如，一个 Mesh 引用、一个 Material 引用，或一个复杂的动画状态机），这被称为 Managed Component（在 Unity DOTS 中是 IComponentData 接口的实现类，或 IComponentData 中包含引用类型字段）。
- 处理 Managed Component： 它们通常不适合大规模并行处理，因为它们存储在堆上，会引发 GC，并且难以在 Job 中安全传递。在通用 ECS 中，你可能需要单独的字典来管理它们，或者在 System 中谨慎处理，避免在高性能路径中频繁访问。
原则是：数据优先，尽可能使用 struct。只有当无法避免时才考虑引用类型，并将其影响降到最低。
小结
System 是 ECS 的核心驱动力。通过理解 System 的生命周期、它们如何通过操作纯数据 Component 来实现复杂行为，以及如何利用数据驱动的事件和 Component 引用来实现 Entity 间的交互，你已经掌握了 ECS 中构建动态世界的关键。我们还探讨了 struct Component 的优势和 Managed Component 的考量。
虽然我们建立的是一个简化的 ECS 框架，但其核心思想和模式与真实的、高性能的 ECS 框架（如 Unity DOTS）是相通的。通过这个过程，你不仅学习了 ECS，更锻炼了对数据结构、算法和性能优化的深刻理解。
在下一篇文章中，我们将进一步探讨 ECS 调试、性能优化，以及如何将你构建的 ECS 逻辑与 Unity 传统 GameObject 进行结合，以应对实际项目的复杂需求。敬请期待！
ECS由浅入深第一节
ECS由浅入深第二节
ECS由浅入深第三节