继承体系的问题,为什么要用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