ECS

初步了解

ECS

基于面向数据的架构模式

简介

Entity-Component-System（实体-组件-系统）

Entity-独立物体

只是一个概念上的定义，指的是存在你游戏世界中的一个独特物体，是一系列组件的集合（ID区分）。

Player(Position, Sprite, Velocity, Health)
Enemy(Position, Sprite, Velocity, Health, AI)
Tree(Position, Sprite)
注：括号前为实体名，括号内为该实体拥有的组件

Component-数据

一堆数据的集合，可以使用C语言中的结构体来进行实现。它没有方法，即不存在任何的行为，只用来存储数据。

思路：
每一个组件都继承（或实现）同一个基类（或接口），通过这样的方法，我们能够非常方便地在运行时动态添加、识别、移除组件。每一个组件的意义在于描述实体的某一个特性。
例如：
PositionComponent（位置组件），其拥有x、y两个数据，用来描述实体的位置信息
EnemyComponent空组件标识敌人
特殊组件：如 Singleton Component （单例组件），单例组件在一个上下文中有且只有一个。
PositionComponent(x, y)
VelocityComponent(X, y)
HealthComponent(value)
PlayerComponent()
EnemyComponent()
注：括号前为组件名，括号内为该组件拥有的数据

System-行为

对拥有一个或多个相同组件的实体集合进行操作的工具，它只有行为，没有状态，即不应该存放任何数据。

解释：
游戏中玩家要操作对应的角色进行移动，由上面两部分可知，角色是一个实体，其拥有位置和速度组件，那么怎么根据实体拥有的速度去刷新其位置呢，MoveSystem（移动系统）登场，它可以得到所有拥有位置和速度组件的实体集合，遍历这个集合，根据每一个实体拥有的速度值和物理引擎去计算该实体应该所处的位置，并刷新该实体位置组件的值，至此，完成了玩家操控的角色移动了。
注意，我强调了移动系统可以得到所有拥有位置和速度组件的实体集合，因为一个实体同时拥有位置和速度组件，我们便认为该实体拥有移动的能力，因此移动系统可以去刷新每一个符合要求的实体的位置。这样做的好处在于，当我们玩家操控的角色因为某种原因不能移动时，我们只需要将速度组件从该实体中移除，移动系统就得不到角色的引用了，同样的，如果我们希望游戏场景中的某一个物件动起来，只需要为其添加一个速度组件就万事大吉。

例子
由于代码逻辑分布于各个系统中，各个系统之间为了解耦又不能互相访问，那么如果有多个系统希望运行同样的逻辑，该如何解决，总不能把代码复制 N 份，放到各个系统之中。UtilityFunction（实用函数） 便是用来解决这一问题的，它将被多个系统调用的方法单独提取出来，放到统一的地方，各个系统通过 UtilityFunction 调用想执行的方法，同系统一样， UtilityFunction 中不能存放状态，它应该是拥有各个方法的纯净集合。
样例：
MoveSystem(Position, Velocity)
RenderSystem(Position, Sprite)
注：括号前为系统名，括号内为该系统关心的组件集合

问题

目前问题

以前我们基于Unity的GameObject/MonoBehaviour机制，可以非常简单为创作游戏编写代码，但最终往往让代码陷入难以阅读，维护和优化的境地。这是一系列因素联合导致的：
面向对象模型
由Mono编译的非最优机器码
GC机制
单线程开发
…

解决问题

采用ECS不但在设计上可以更好的进行游戏编程，还可以利用Unity提供的JobSystem和Brush编译器充分发挥多核处理器的性能。
Unity2017以后已经发布了JobSystem，基于JobSystem可以在C#代码中更好的实现多线程批处理技术，JoySystem底层为多线程间的竞争提供的安全保障。
对于开发者而言，更重要的是要使用一种新的思维方式和编码方式来充分利用JobSystem。
…

存在问题

繁多的组件以及轮询问题，数据共享问题
…

案例

整理来源有Demo
链接Jobs and ECS and Burst