« 3d engine 项目招聘 | 返回首页 | 惰性编译资源仓库中的源文件 »

ECS 中的 Entity

我认为 ECS 框架针对的问题是传统面向对象框架中,对象数量很多而对象的特性非常繁杂,而针对对象的不同方面 aspect 编写处理逻辑会非常繁杂。每个针对特定的方面执行业务,都需要从众多对象中挑选出能够操作的子集,这样性能低下,且不相关的特性间耦合度很高。

所以 ECS 框架改变了数据组织方式,把同类数据聚合在一起,并用专门的业务处理流程只针对特定数据进行处理。这就是 C 和 S 的概念:Component 就是对象的一个方面 aspect 的数据集,而 System 就是针对特定一个或几个 aspect 处理方法。

那么,Entity 是什么呢?

我认为 Entity 主要解决了三个问题。

  1. 生命期管理。如果我们把对象的不同方面分拆到了不同的 Component 中,同类的 Component 群聚在一起。这样就达到了 System 间的解耦。但是这些 Component 依然在生命期上属于一个整体,换句话说,它们还是属于一个对象。所以 Entity 就是联系同一对象上不同组件生命期的东西。我们可以通过删除一个 Entity 来从世界中剔除一组相关的 Component 。

  2. 组件关联性。有些系统只处理单一类型的 Component ,那么它们可以无视对象身上的其它方面。但很多系统必须处理一个对象所属的多个方面 ,例如你需要把物理系统针对碰撞体计算出来的结果反馈给对象的空间位置信息。碰撞体组件 A 和空间变换组件 B就发生了联系。整个世界中有众多的 A 和众多的 B ,Entity 就是负责把特定的 A 和特定的 B 关联在一起。

  3. 跨世界的对象关联。这个需求多见于 C/S 结构的网络游戏。服务器和客户端有两个世界,但是两个世界中的对象是互为镜像,它们是有关联的。我们需要有一个手段知道服务器上的某个对象到底对应着是客户端上哪个对象。这里的对象就指 Entity ,两个世界中的互为镜像的 Entity 有两个独立的数据拷贝,所以,我们需要用一个 id 来指代它们其实是同一个东西。这就是为什么 ECS 框架中,Entity 为何用 id 来表示的原因之一。


我们一开始开发 ECS 框架时,限制了一个 Entity 上只能由不同类型的 Component 构成,不允许多个同类的 Component 加到同一个 Entity 上。

现实需求总是复杂的。往往我们会碰到更复杂的数据组织需求。例如,一个玩家身上有多个 buf ;一个场景物件需要由多个几何体来描述碰撞体。这都涉及多个同类 Component 组合成一个 Entity 。

Unity 采取的方案是支持同类 Component 组合。例如你可以给一个对象添加多个碰撞体。但我认为并非很好的解决方案。

因为,从 Entity 索引特定的 Component 变得复杂,遍历世界中所有同类 Component 接口不仅需要关心每个 Component 隶属于哪个 Entity ,还需要关心是 Entity 上多个同类 Component 中的哪一个。很难简单的把同类 Component 置于一个简单集合中。

另外需要把同类子物件摊平为单个组件。就以碰撞体为例,它原本可分为集合形状和空间位置两部分,或者你还可以给碰撞体添加颜色(用于开发调试)、分层等等其它属性,但由于我们需要把多个碰撞体加在物件上,不得不把碰撞体的所有属性都加到同一个叫碰撞体的特定类型 Component 上。

这样是不利于 ECS 框架原有希望做到的数据解耦:例如空间剔除器只关心空间位置和包围盒,并不关心形状、阻挡属性等等;而物理系统则关心几何体的外形描述,质量等等其它方面。

事实上,Unity 也做了场景树这种不同 Entity 间的组合。可以把一个 Entity 挂接到场景树上,让空间关系受另一个 Entity 影响。我认为场景树和 Component 组合在功能上有重叠。


我现在的想法是,应该抽象出另外两类 Component ,一个是 subset ,就是一个 entity id 集合,表示一组 Entity 是一体的,满足前面所说的生命期管理需求和关联性需求。

另一个是 owner ,指向一个 entity id ,表示自身被另一个 Entity 管理。

subset 和 owner 作为可选项,可以随意添加到 Entity 上。根据 System 的实现需求,有时仅用其中之一即可。

subset 的实现可以是一个简单的 table ,但针对 3d engine 来说,我们开发了名为 hierarchy 的数据结构,可以表示一棵树。也就是可以用一个 set 包容下整个树的节点,并储存下针对根节点的空间变换信息。

以场景组织为例,一个场景物件可以有多个碰撞体来描述碰撞信息。这些碰撞体会被物理系统处理。但在场景编辑过程中,我们在场景中挪动物件,则会改变相关碰撞体组的空间位置。所以我们可以把多个碰撞体加入场景物件的 subset 中,储存在一个 hierarchy 数据结构里。当编辑场景时,一个特定的 system 会负责从物件的空间位置更新碰撞体在空间中的位置,方便物理碰撞系统去处理。

Comments

@荞麦 来搞笑的?太羞耻了。。。

如果存在“Entity 上挂多个同类 Component 的问题”,个人觉得是将ECS模式搞错了。因为ECS模式有一个重要的特点。就是,它是将数据和动作分开。如果出现了多个相同的C类,例如,一个地图上有多个Player,那么显然,Player不应该是 Component。

从服务端的角度来说。
ECS模式是什么,举例说明,从DB读出一个Player,假设Player在Login服务器上有ReadLastMapInfo 动作,就是读取最后地图的信息。而Player登录到GameServer上也有一个ReadLastMapInfo 动作,那么,对于Player来说,它就应该有一个 组件是处理 ReadLastMapInfo 这个动作。假设我们还有第三个服务器聊天服务器,聊天服务器也有Player对象,但这个对象就没有 ReadLastMapInfo 这个组件。

数据都在Player对象上,但没有组件就没有动作。

大神呀 ,看不懂呀

关于是不是支持在 Entity 上挂多个同类 Component 的问题我也考虑了很久。

目前的做法是不允许 Entity 上挂同类型的 Component,单位身上挂多个 BUFF 时,为每个 BUFF 创建一个 Entity ,然后在单位的 BuffContainer Component 中记录一个所有挂接的 BUFF 的 Entity ID。依赖 BUFF System 这样的具体系统来负责父 Entity 被销毁时同时清理 BuffContainer 中关联的子 Entity。

暂时好像还没有遇到过从子 Entity 往回找父 Entity 的情况,所以暂时也还没有类似 owner 组件的设计。
有一些类似的情况是 Entity 之间相互关联,则是在各自的对应 Component 中记录对方的 Entity ID。

一直想什么时候像 Unity 那样支持挂多个同类 Component 试试。不过也是没有完全想好,感觉 Unity 的方案是个比较勉强的折衷方案,在准守一些设计原则的情况下也可用,不过确实也存在各种麻烦的问题。

P.S. 这个留言框好小……

Post a comment

非这个主题相关的留言请到:留言本