ECS架构笔记

ECS的介绍 云风写的非常好: https://blog.codingnow.com/2017/06/overwatch_ecs.html#more

ECS不是银弹,但在3D引擎领域是一个比较合适的框架, 目前的大多数现代3D引擎,或多或少都采用这种设计思想,比如Unity, UnReal。当然后面应该会有更为先进的框架出现。

在这近一年的工作中,我基本经历了从传统渲染树到ECS架构的变化,感受到ECS在这个领域的相对先进性,记录一下。就自己之前做Android的经历,很多人只能接触到MVC/MVP/MVVM(因为它们够简单直白),架构思想被限制在一个界限内。ECS是不适合UI层设计的,但是它提供了一种新的视角和理念。

  1. ECS是一个典型设计思想的体现: 组合大于继承,Entity在这个体系里完全被剥离成一个最纯粹的锚点,他的属性只有一个:存在性。所有的功能都由Component和System协同来完成。Entity只提供了Component锚定和组织作用(组织作用其实也被极度弱化,可以理解为一个最简单直白的集合)。Component和System可以自由靠挂,扩展性很强。
  2. System和Component体现了单一职责的设计理念: 每种类型的System和对应的Component高度契合,两者结合在一起实现了某一类的特定功能(当然,一对一的关系不是绝对的,某些Component可能和会复数的System交互,这是合理的,Component是数据,而数据是中性的)。
  3. System和Component的协同关系某种意义上不是OOP,而是AOP。System是无状态的功能切片,而Component则作为数据和状态的被动维护者。System只处理自己对应的Component,对其他的Component和System基本保持一个不可知状态(在ECS中,System之间协作应该是需要被克制的),保证了功能之间的隔离性。
  4. ECS相较之前传统3D引擎设计思路的一个最明显的区别是: 连”位置”这个概念都会被处理为一个Component。而不是传统思路中,基于位置关系来构造整个场景树。是Entity纯粹存在性的一个体现。ECS是一个集合,而非一棵树,树关系体现通过位置Component之间的串接来体现。
  5. 个人认为ECS在隔离性上做的很好,但是高隔离的代价是通信和数据汇总会相对困难,不过前者一般是由引擎的调用者来实现的业务逻辑。后者,Entity作为一个锚点,完全可以基于这个锚点将其靠挂的Component全部获取,来得到汇总的数据,这个操作是外面逻辑进行,还是引擎提供便利化封装,甚至专门做一个汇总型的Component(不过已经破坏了ECS的隔离性,一种类型的Component会感知到其他类型的Component,甚至了解其细节),应该有一定的选择自由度。
  6. ECS处理的是这样一个场景: 有一堆实体的集合,每个实体有一些共性,但是也会有自己的特殊性和处理逻辑。后期新实体和新特性的引入要对旧逻辑造成最小的影响。
发布了426 篇原创文章 · 获赞 48 · 访问量 64万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览