电竞之家_品味电竞生活移动版

游戏的业务循环就是在调用很多不同的系统，每个系统自己遍历自己感兴趣的对象，只有预定义的组件部分可以被子系统感知到，这样每个系统就能具备很强的内聚性。注意、这和传统的面向对象或是Actor模型是截然不同的。OO或Actor强调的是对象自身处理自身的业务，然后框架去管理对象的集合，负责用消息驱动它们。而在ECS中，每个系统关注的是不同的对象集合，它处理的对象中有共性的切片。这是很符合守望先锋这种MOBA类游戏的。这类游戏关注的是对象间的关系，比如A攻击了B对B造成了伤害，这件事情是在A和B之间发生的，在传统模型中，你会纠结于伤害计算到底在A对象的方法中完成还是在B的方法中完成。而在ECS中不需要纠结，因为它可以在伤害计算这个System中完成，这个System关注的是所有对象中，和伤害的产生有关的那一小部分数据的集合。

ECS的设计就是为了管理复杂度，它提供的指导方案就是Component是纯数据组合，没有任何操作这个数据的方法；而System是纯方法组合，它自己没有内部状态。它要么做成无副作用的纯函数，根据它所能见到的对象Component组合计算出某种结果；要么用来更新特定Component的状态。System之间也不需要相互调用（减少耦合），是由游戏世界（外部框架）来驱动若干System的。如果满足了这些前提条件，每个System都可以独立开发，它只需要遍历给框架提供给它的组件集合，做出正确的处理，更新组件状态就够了。编写Gameplay的人更像是在用胶水粘合这些System，他只要清楚每个System到底做了什么，操作本身对哪些Component造成了影响，正确的书写System的更新次序就可以了。一个System对大多数Component是只读的，只对少量Component是会改写的，这个可以预先定义清楚，有了这个知识，一是容易管理复杂度，二是给并行处理留下了优化空间。