02_Unity ECS

我对ecs系统的一点看法

2018-10-04  本文已影响448人  silekey

谈论什么

这里我主要从工程或设计的角度讨论, 至于ecs对性能的优化方面

的事情我这不做过多介绍.

为什么要把c与s分开

这是我在用ecs系统时最大的一个问题,现将我的一点想法与大家分享

原因在于将c与s分开之后,就可以降低逻辑之间的关系,极大的降低系统复杂度

原理如下:

当system(逻辑)需要其他数据,直接找到entity好了,数据都在上面。

没有必要与其他system(逻辑)有关联

所有的关联都在entity及其component上

在拓扑关系里,若将所有entity看成一个节点,那么所有system都依赖这个

节点,而且entity与compoent又不依赖system,这样一个星形的单方向的拓扑结构

极大的简化了系统的之间的关系与复杂度。

下面讲的优点都在这基础上具体的表现。

ecs系统的优点

只有component能存数据,只有system能有行为, entity结构永远不变

规则就这么简单,比较容易记住

由于ecs系统的所有操作都是对entity内的数据(Component)的直接修改

因此大大的降低了不确定性与花费的 精力

举例: 系统庞大之后, 做一个系统或功能可能要依赖好几个系统

用面向对象或ec系统的时候,你可能需要调

用一些函数

而这些函数有可能代价很高很复杂, 比如内部调用的文件存储、

网络、渲染api这类复杂的操作,需要很小心的调用

不然很可能就会有性能问题。

而在ecs系统中即便是调用的辅助函数, 本质都是对数据的操作

能够很方容易估算出调用的代价,而且代价也相对较小。

正因为ecs创建entity代价小,

创建对象直接生产,不需要内存池对象池也相应减少了代码复杂性

由于ecs系统强制把数据和行为分开了, 写逻辑的程序就不容易出错了。

因为本质上写的东西就是对纯数据的操作。

规范更容易推进, system里面不保存任何数据, 规则也很清晰,容易执行

需要记录的东西都使用component来记录

这样大家就不会出现数据存储在一些奇怪的地方

原有的方式,每个系统的调用, 需要用到的数据可能有各种获取方式

比如调用某个或多个方法来获取。

而ecs系统则统一使用类型的组合作为数据的获取条件

游戏中常需要保存游戏进度, 或是同步数据给服务器。

ecs系统里只要把特定的component筛选出来序列化就可以, 非常方便

所有的system 可以做到只依赖 相应的component

直接的交互也使用component来进行, 这样就极大的降低了代码间的耦合

ecs系统缺点

一些功能的重用必须要有整个ecs环境才能运作, 模块独立性不高

一些底层功能, 如网络,文件操作使用ecs就不好做封装

正因为模块间无法隐藏数据, 导致一个问题就是设计不好的数据会影响所有系统

对写的不好的代码容忍度比较低

无法像ec系统, 比如com组件那样将所有的代码都用一套来封装

新的编程模型需要新的思考方式,大家需要习惯一下

编程演化

基本编程方式的发展就是各种简化

ecs系统总结

ecs的最大收益的,其实是做逻辑的程序,可以更加容易的写出优秀的代码。

ecs系统在我看来就是ec系统的一个子集,在ec系统上加上一些

限制条件容易做成一个ecs系统,ecs系统的好处是我们能够

更加容易的写出高质量的代码。

由于ecs的局限性, 主要用于上层架构, 不会用于底层架构

至于在ecs中需要调用到的外部api,通常都会在ecs中加个中间层并入已有的ecs系统中

比如要做网络同步, 就需要创间一个网络相关的system,再把数据同步出去

吐槽一下unity 的ecs系统

上一篇下一篇

猜你喜欢

热点阅读