ECS 游戏框架背景知识

1. 系统、实体、组件

组件是游戏数据的集合 [1]
实体是组件的集合
系统是方法的集合

因此：
一个实体的意义取决于其组件的组合
一个系统的意义取决于其方法集处理的组件集

例如：
一个实体是否拥有运动组件代表着玩家能否操控这个实体运动
是否拥有碰撞体组件代表着这个实体是否参与碰撞
是否拥有刚体组件代表着这个实体是否参与物理模拟
是否拥有角色组件代表这个实体是否参与伤害流程
一个系统获取到实体的运动组件，计算实体的速度，然后获取到实体的碰撞体组件，检查是否干涉，最后得到实体的移动后的位置，赋回给实体的运动组件，并设置实体的位置，那么这个系统就是运动系统

2. 为什么要用 ECS

2.1 逻辑与数据解耦

游戏的状态完全可以用一段数据来定义。
游戏的所有内容，就是游戏数据和处理数据的方法。[2]

从头开始构建一个游戏，首先要思考数据和方法的关系。
数据和方法都封装到一个地方，就是面向对象。

如果我们尝试使用将数据封装在操作中的对象来构建游戏，那么我们将在所有这些不同的系统之间建立依赖关系，因为它们都希望用玩家的位置数据进行封装
除非我们将游戏编码为一个单一的、庞大的类，但显然这个庞大的类就是一坨屎山
因此我们不可避免地将游戏的某些部分分解为单独的系统，并向这些系统（物理系统、图形系统）提供数据，同时将游戏逻辑的其他元素包含在游戏对象本身中

例如，我有两个逻辑，移动和渲染，如果我需要
可以移动但是不能渲染的
可以渲染但是不能移动的
可以渲染并且可以移动的
那么我就会去继承移动类和渲染类，做出一个若干层的继承树 [3]