组件-实体-系统 Entiy-Compoent-System ECS架构整理

继承体系的问题,为什么要用ECS

面向对象的问题

• 当一个新的类型需要多个老类型的不同功能的时候,不能很好的继承出来
• 游戏开发后期会有非常多的类,很难维护
• 游戏中子系统很多,它们对一个对象的关注点往往互不相关,比如渲染.网络,战斗数据,如果都对应一个基础角色对象,这个类就会很大

ECS,通过组合而不是继承的方法来进行实体的构建

• ECS的设计目的是用来把大量的模块进行集成并解耦,用最小的耦合来集成大量分散的系统
• 每个System可以只关注实体有什么,而不是实体是什么,这是与OOP的最大区别
• 在网络同步的预测错误后可以很方便的纠正(所有元素都用Component分离了)
• ECS的一个重要特性就是并发优势,因为提供了数据隔离

Unity推荐ESC的原因

• ECS专注于您正在解决的实际问题，即构成游戏的数据和行为。
• 为了配合使用Job System和Burst 编译器。
• 从以对象为导向的设计转到以数据为导向的设计，代码更为容易，也更易于他人掌握。

示例

假设一个简单的游戏,有石头,树,敌人,玩家三种物体

这个时候需要一个新的类型,可以攻击的树

• 按照OOP的设计大致是这样的
  
  
• ECS的设计大致是这样的
  
  
  
  EvilTree拥有: Position,AI,Sprite,AABB

ECS结构图示

ECS基础规则

* Entity轻量级,甚至只有一个Id;
* System没有状态, Component 不带行为
* System不能调用其他System的函数,共享代码要放到Utils里(如敌对关系),Utils函数无副作用；
* 组件里复杂的副作用要通过队列的方式推迟处理，尤其是单例组件；

实体

一个实体指的是存在于你的游戏世界中的物体。实体在代码上就是一个组件的列表。
由于实体的结构实在是太简单了，所以很多实现都没有专门的设计一个实体的数据结构。相反的，一个实体就是一个ID，所有组成这个实体的组件将会被这个ID给标记，从而明确的知道哪些组件是属于哪个实体的。如果你想的话，你可以在运行时，动态的将组件从实体中移除或者增加一个或多个你感兴趣的组件。比如说，如果玩家发出了一个冰系魔法，将敌人冻住，你只要简单的将它的速度组件移除，那么敌人就静止住了。

组件

没有行为(改变数据),只是用来存储一些数据(全部公开), 每一个组件都描述了实体的某个属性特征。
每个System会以自己的角度对待组件,不同的观察者区别对待主体
单例组件: 属于单一匿名实体,可以直接访问,存放System大部分状态.比如Ipnut单例,从InputSys中剥离的数据.

系统

真正处理游戏逻辑的地方.
System不关注实体到底是什么,只关心组件集合,在这个集合上执行一组行为
只会有很少的System改变组件状态,自己管理复杂性
系统会指明所需要的组件集合,由主逻辑筛选出所有满足要求的实体

守望先锋的ECS

EntityAdmin是个World，存储了一个所有System的集合，和一个所有实体的哈希表(ID为unit32)。

单例组件

示例:命中处理System

• ModifyHealthQueue组件,记录实体身上所有伤害和治疗效果
• MovementState组件,移动数据处理
• 一组Utility函数处理错误纠错,回滚相关Component

几个建议

• System定义组件的组合时,可以把组件标记为只读
• 实体生命周期建议立即创建,延时销毁
• 某些遗留子系统不能接入ECS时,就不要强行接入,保持子系统的整洁
• 事实证明，网络同步真的很复杂，所以必须尽可能的与引擎其余部分解耦，ECS是解决这个问题的好办法。

Unity中的ECS

在PackageManager中下载Entities

参考

• 暴雪<守望先锋>ECS简介
• UnityGithub上的ECS架构
• 知乎 一个ECS实现
• 云风 浅谈《守望先锋》中的 ECS 构架
• Entity Systems are the future of MMOG development 2007
• 理解 组件-实体-系统 （ECS \CES）游戏编程模型