ECS框架的初步探究

  欢迎参与讨论,转载请注明出处。

前言

  在阅读这篇文章之前,你需要了解一下何为ECS框架。关于ECS框架,其实近年来一直想去尝试,终于在近日有所体悟,遂有此文。

详解

  ECS框架的存在实际上很早就出现了(我记得最初在2003年),近年随着《守望先锋》架构设计与网络同步一文出现后瞬间成了炙手可热的新星。
  ECS框架与帧同步锁定类似,皆只是拥有一个概念,但无确切的实现标准。但事实上已经不少现成的实现(如Entitas),不过我觉得Entitas在与Unity的结合上不符合我的审美,于是自己动手造了个轮子。
  ECS框架的概念其实相当直观:Entity-Component-System三件套。

  • Entity即实体,作为Component的经纪人,可拥有多个Component。
  • Component即组件,作为数据存储的容器,原则上只包含内部数据自处理的函数。Component以Entity作为标识,以此判断所属。
  • System即系统,作为业务函数的集合,会与Component对接实现业务运行(System处理Component)。

  以上三点可谓看过相关文章的都懂,只是落实到具体实现上仍会有不少不明不白之处(Entity是作为容器还是标识符?Component可否嵌套Component?System之间可否相互调用?)。以上问题并没有确切的答案,只能是落实实现时根据需求而定。

实现

  所谓实践出真知,在此之前我写了个贪吃蛇,这是个不错的素材,于是便将其ECS化。这下也可将两者进行对比,品味其中区别。

Entity

  由于这款游戏是使用Unity制作的,那么自然最好与Unity本身相结合。我首先考虑到的便是与Unity本身的GameObject-Behavior(其实是Component,为防误解,特此改称)框架结合(业务环境下有调用它们的需求),于是选择将Entity做成一个Behavior:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
using System;
using UnityEngine;
namespace Game.Core {
public class Entity : MonoBehaviour {
public static event Action<Entity> NewTickEvent;
public static event Action<Entity> DestroyTickEvent;
protected void Start() {
if (Entity.NewTickEvent != null) {
Entity.NewTickEvent(this);
}
}
protected void OnDestroy() {
if (Entity.DestroyTickEvent != null) {
Entity.DestroyTickEvent(this);
}
}
}
}

  可以看出,Entity的生命周期也与GameObject进行了捆绑,并且设置了两个event令System可以进行监控。
  再来看看Entity的具体实例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
using UnityEngine;
namespace Game.Entitys {
using Core;
using Components;
public class Food : Entity {
public Position position = new Position();
protected void Awake() {
this.position.Init(this);
}
protected new void OnDestroy() {
base.OnDestroy();
this.position.Destroy();
}
}
}

food

  可以看出Food实体创建了一个Position组件,托Unity编辑器的服,我们可以清晰地看到Position的数据构成,并可方便地进行编辑(包括运行时)。当然可以看得出这里Component的创建方式相当别扭(实例化后仍需Init),这是为了对接Unity的序列化功能,若不这么做的话,某些数据将会序列化失败(如Collision Slot)。

Component

  Component的初始实现便很简单了,只需要对接Entity以及预留Init与Destroy接口即可:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
using System;
namespace Game.Core {
[Serializable]
public class Component {
[NonSerialized]
public Entity entity;
public virtual void Init(Entity entity) {
this.entity = entity;
}
public virtual void Destroy() {}
}
}

  这里令Component拥有entity是为了便于识别身份,[Serializable]标识表示该对象可序列化(与编辑器交互),[NonSerialized]标识表示不让该变量序列化(没有显示在编辑器的需求)。接下来看看Position组件的具体实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
using System;
using System.Collections.Generic;
using UnityEngine;
namespace Game.Components {
using Core;
using Solts;
public class Position : Component {
public static Dictionary<Entity, Position> Map = new Dictionary<Entity, Position>();
public static List<Position> List = new List<Position>();
public Vector2Int value;
public Collision collsionSlot;
public override void Init(Entity entity) {
base.Init(entity);
Position.Map.Add(entity, this);
Position.List.Add(this);
}
public override void Destroy() {
Position.Map.Remove(this.entity);
Position.List.Remove(this);
}
}
}

  关于ECS框架有一个很普遍的问题:在System要如何获取到Component?我的解决方法便是为有获取需求的Component设立存储容器,当然这种写法有点死板,应该专门设立容器管理类进行自动化处理,这是个可改善的方向。

System

  System纯粹来看便是个函数集,在Entitas的实现是专门设立Behavior装载System以运行。而我选择分离:System即Behavior,两者倒没什么根本上的区别,全凭个人喜好罢了。在以Behavior的实现下并不需要System基类,以下以涉及到坐标与碰撞的Field系统为例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
using System.Collections.Generic;
using UnityEngine;
namespace Game.Systems {
using Core;
using Components;
using Entitys;
public class Field : MonoBehaviour {
public const float SIZE = 0.32f;
private static List<Entity> SyncList = new List<Entity>();
public static Vector2 ToPosition(int x, int y) {
return new Vector2(x * SIZE + SIZE * 0.5f, y * SIZE + SIZE * 0.5f);
}
public static void AdjustPosition(Position position, Transform transform=null) {
transform = transform == null ? position.entity.transform : transform;
transform.position = Field.ToPosition(position.value.x, position.value.y);
}
private static void Collide(Position a, Position b) {
if (a.value == b.value) {
if (a.collsionSlot != null) {
a.collsionSlot.Run(a.entity, b.entity);
}
if (b.collsionSlot != null) {
b.collsionSlot.Run(b.entity, a.entity);
}
}
}
private static void Sync(Position position, Joint joint) {
joint.laterPos = position.value;
}
protected void Awake() {
Entity.NewTickEvent += this.NewTick;
Entity.DestroyTickEvent += this.DestroyTick;
Director.UpdateTickEvent += this.UpdateTick;
}
private void NewTick(Entity entity) {
bool hasPos = Position.Map.ContainsKey(entity);
bool hasJoi = Joint.Map.ContainsKey(entity);
if (hasPos) {
Field.AdjustPosition(Position.Map[entity]);
}
if (hasPos && hasJoi) {
Field.SyncList.Add(entity);
}
}
private void UpdateTick() {
for (int i = 0; i < Position.List.Count; i++) {
for (int j = i + 1; j < Position.List.Count; j++) {
Field.Collide(Position.List[i], Position.List[j]);
}
}
foreach (var entity in Field.SyncList) {
Field.Sync(Position.Map[entity], Joint.Map[entity]);
}
}
private void DestroyTick(Entity entity) {
if (Field.SyncList.Contains(entity)) {
Field.SyncList.Remove(entity);
}
}
}
}

  可以看出,继承Behavior的System可以很方便地使用自带的各种回调函数(如Awake),业务函数也变得清晰无比,只需要提供相应Component即可(如AdjustPosition)。对于一些需要复合组件的业务(如Sync),则会专门设立容器(SyncList)进行存储,对Entity的NewTickEvent与DestroyTickEvent进行监控便可筛选出合适的对象,且所有组件可通过Entity从组件容器进行获取,十分方便。
  当然也不要忘记与编辑器结合的优势,System也可以将变量序列化与编辑器交互:
system
  当然Unity可进行序列化的部分只有实例变量,所以需要作此处理:

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Test : MonoBehaviour {
private static Test Instance;
public static int Get() {
return Instance.value;
}
public int value;
protected void Awake() {
Food.Instance = this;
}
}

  因为System是单例Behavior,所以这么做是安全的。如此便可操作实例对象了。

后记

  总的而言,ECS框架主要是一种对OOP思想的反思,甚至可以说是一种复古(函数式编程风格)。也是一种彻底的组件模式实现,彻底地奉行数据-逻辑分离。它使得我们更容易地去抽象、描述游戏事物。当然我认为它在某种程度上是反直觉的、抽象的(某些只会属于某个对象所属的业务却要分开写,并且用组件去涵盖)。所以我认为它更适用于某些场景下,如动作游戏里的地图单位,分为多种样式(物件、道具、战斗单位、NPC、飞行道具等),这种时候使用传统的继承+子对象写法确实不如ECS来得好了。再比如UI方面,我认为还是MVC框架更为王道。所以切忌教条主义,一切跟着实际需求走。