什么是游戏开发的实体系统框架

本是古典何须时尚 2022-08-04 01:42 147阅读 0赞

原文地址：http://blog.csdn.net/aisajiajiao/article/details/19011259

上周我发布了[Ash][],一个Actionscript游戏开发实体系统框架,许多人问我这个问题"什么是实体系统框架?"本文就是我详尽的答案.

实体系统逐渐流行起来了,比较著名的有像[Unity][],不太知名的框架像Actionscript框架[Ember2][],[Xember][]和我自己的[Ash][].使用这个有一个很好的理由:它们简化了游戏架构,鼓励在你的代码中进行清晰的职责分工而且用起来很有趣.

在本文中我将向你展示一个基于实体的架构从经典而流行的游戏循环演变而来.这可能会花点时间.例子将使用Actionscript因为这正好是我当前使用的语言,但其架构理念可以用于所有的编程语言.

这基于我在2011年在[try\{harder\}][try_harder]上的一次[展示][Link 1]

#### 例子 ####

贯穿整篇文章,我将使用一个简单的[小行星游戏][Link 2]作为一个例子.我比较喜欢使用小行星游戏是因为涉及到了大游戏中很多系统的简化版本-渲染,物理,ai,用户所控制的角色和npc.

#### 游戏循环 ####

要理解为什么我们使用实体系统,你得了解经典且流行的[游戏循环][Link 3].小行星游戏的游戏循环可能会类似下面展示的:

1.  function update(time:Number):void 
2.  \{ 
3.   game.update(time); 
4.   spaceship.updateInputs(time); 
5.   for each (var flyingSaucer:FlyingSaucer in flyingSaucers) 
6.   \{ 
7.   flyingSaucer.updateAI(time); 
8.   \} 
9.   spaceship.update(time); 
10.  for each (var flyingSaucer:FlyingSaucer in flyingSaucers) 
11.  \{ 
12.  flyingSaucer.update(time); 
13.  \} 
14.  for each (var asteroid:Asteroid in asteroids) 
15.  \{ 
16.  asteroid.update(time); 
17.  \} 
18.  for each (var bullet:Bullet in bullets) 
19.  \{ 
20.  bullet.update(time); 
21.  \} 
22.  collisionManager.update(time); 
23.  spaceship.render(); 
24.  for each (var flyingSaucer:FlyingSaucer in flyingSaucers) 
25.  \{ 
26.  flyingSaucer.render(); 
27.  \} 
28.  for each (var asteroid:Asteroid in asteroids) 
29.  \{ 
30.  asteroid.render(); 
31.  \} 
32.  for each (var bullet:Bullet in bullets) 
33.  \{ 
34.  bullet.render(); 
35.  \} 
36. \}

游戏循环在固定的间隔被调用,通常是每秒60次或者每秒30次来更新游戏.当我们在每帧更新各种各样的游戏对象检查它们之间的碰撞然后将他们全部绘制时循环中的操作顺序是很重要的.

这是一个非常简单的游戏循环.它简单是因为:

1.  游戏很简单  
    
2.  游戏只有一个状态

在以前我曾开发一些平台游戏(console games)其游戏循环,一个简单的函数超过了3000行代码.这不漂亮也不聪明.游戏就是这么开发的而且我们不得不忍受它.

实体系统架构衍生于解决游戏循环弊病的一种尝试.它将游戏循环看做游戏的核心,且预先假设在现代游戏架构中简化游戏循环比其他事物重要得多.例如,比视图和控制器分离重要得多.

#### 进程 ####

在这种演变中第一步要考虑的是被称作进程的对象.这些对象可被初始化,定期更新以及销毁.一个进程的接口类似如下所示:

1.  interface IProcess 
2.  \{ 
3.   function start():Boolean; 
4.   function update(time:Number):void; 
5.   function end():void; 
6.  \}

如果我们将游戏循环拆分为许多进程来处理我们可以简化游戏循环,例如,渲染,移动,碰撞检测.要管理这些进程我们创建一个进程管理器.

1.  class ProcessManager 
2.  \{ 
3.   private var processes:PriorirtiesdList; 
4.  
5.   public function addProcess(process:IProcess,priority:int):void 
6.   \{ 
7.   if(process.start()) 
8.   \{ 
9.   processes.add(process,priority); 
10.  return true; 
11.  \} 
12.  return false; 
13.  \} 
14. 
15.  public function update(time:Number):void 
16.  \{ 
17.  for each(var process:IProcess in processes) 
18.  \{ 
19.  process.update(time); 
20.  \} 
21.  \} 
22. 
23.  public function removeProcess(process:IProcess):void 
24.  \{ 
25.  process.end(); 
26.  processes.remove(process); 
27.  \} 
28. \}

这是一个稍微简化版的进程管理器.特别是我们要确定我们以正确的顺序更新进程(顺序由add方法中的priority参数指定)并且我们需要处理在更新循环中移除进程的情况.但你已经了解了概念.如果我们的游戏循环被拆分为多个进程,那我们进程管理器的更新方法是我们新的游戏循环且进程变成了游戏的核心.

#### 渲染进程 ####

作为一个例子我们看下渲染进程.我们需要将渲染代码从原来的游戏循环中抽出来并将其放置在一个进程中,代码类似如下:

1.  class RenderProcess implements IProcess 
2.  \{ 
3.   public function start():Boolean 
4.   \{ 
5.   //initialize render system 
6.   return true; 
7.   \} 
8.  
9.   public function update(time:Number):void 
10.  \{ 
11.  spaceship.render(); 
12.  for each(var flyingSaucer:FlyingSaucer in flyingSaucers) 
13.  \{ 
14.  flyingSaucer.render(); 
15.  \} 
16. 
17.  for each(var asteriod:FlyingSaucer in asteriods) 
18.  \{ 
19.  asteriod.render(); 
20.  \} 
21. 
22.  for each(var bullet:Bullet in bullets) 
23.  \{ 
24.  bullet.render(); 
25.  \} 
26.  \} 
27. 
28.  public function end():void 
29.  \{ 
30.  //clean-up render system 
31.  \} 
32. \}

#### 使用一个接口 ####

但这个并不是很有效率.我们仍旧必须手动渲染不同类型的游戏对象.如果对于所有的可渲染对象我们有一个通用接口,我们可以简化很多事情.

1.  interface IRenderable 
2.  \{ 
3.   function render():void; 
4.  \}

1.  class RenderProcess implements IProcess 
2.  \{ 
3.   private var targets:Vector.<IRenderable>; 
4.  
5.   public function start():Boolean 
6.   \{ 
7.   //initialize render system 
8.   return true; 
9.   \} 
10. 
11.  public function update(time:Number):void 
12.  \{ 
13.  for each(var target:IRenderable in targets) 
14.  \{ 
15.  target.render(); 
16.  \} 
17.  \} 
18. 
19.  public function end():void 
20.  \{ 
21.  //clean-up render system 
22.  \} 
23. \}

之后我们的飞船类将包含一些类似下面的代码

1.  class Spaceship implements IRenderable 
2.  \{ 
3.   public var view:DisplayObject; 
4.   public var position:Point; 
5.   public var rotation:Number; 
6.  
7.   public function render():void 
8.   \{ 
9.   view.x = position.x; 
10.  view.y = position.y; 
11.  view.rotation = rotation; 
12.  \} 
13. \}

代码基于flash显示列表.如果我们使用blitting(早期创建像素游戏的一种做法)或者使用stage3d,可能会有些不同,但原理是相同的.我们需要要渲染的图形,渲染图形的位置和渲染值.渲染函数进行渲染.

#### 使用基类和继承 ####

事实上,这段代码中没有任何东西使其与飞船(spaceship)不同.所有的代码都被可渲染对象共享.它两唯一的不同之处是哪个显示对象被赋值给view属性以及位置和旋转值.因此我们将这代码封装(wrap)到基类并使用[继承][Link 4].

1.  class Renderable implements IRenderable 
2.  \{ 
3.   public var view:DisplayObject; 
4.   public var position:Point; 
5.   public var rotation:Number; 
6.  
7.   public function render() 
8.   \{ 
9.   view.x = position.x; 
10.  view.y = position.y; 
11.  view.rotation = rotation; 
12.  \} 
13. \}

1.  class Spaceship extends Renderable 
2.  \{ 
3.  \}

当然,所有的可渲染物件都会继承自renderable类,所以我们得到如下图所示的一个类层级关系图.

![20140212195849875][]

#### 移动进程 ####

要理解下一步,我们首先需要看下另外一个进程和其影响的类.因此我们尝试一下移动进程,它用于更新物体的位置.

1.  interface IMoveable 
2.  \{ 
3.   function move(time:Number); 
4.  \}

1.  class MoveProcess implements IProcess 
2.  \{ 
3.   private var targets:Vector.<IMoveable>; 
4.  
5.   public function start():Boolean 
6.   \{ 
7.   return true; 
8.   \} 
9.  
10.  public function update(time:Number):void 
11.  \{ 
12.  for each(var target:IMoveable in targets) 
13.  \{ 
14.  target.move(time); 
15.  \} 
16.  \} 
17. 
18.  public function end():void 
19.  \{ 
20. 
21.  \} 
22. \}

1.  class Moveable implements IMoveable 
2.  \{ 
3.   public var position:Point; 
4.   public var rotation:Number; 
5.   public var velocity:Point; 
6.   public var angularVelocity:Number; 
7.  
8.   public function move(time:Number):void 
9.   \{ 
10.  position.x += velocity.x; 
11.  position.y += velocity.y; 
12.  rotation += angularVelocity; 
13.  \} 
14. \}

1.  class Spaceship extends Moveable 
2.  \{ 
3.  
4.  \}

#### 多重继承 ####

这还算好,但不幸的是我们需要我们的飞船既可以移动也可以被渲染出来,并且许多现代程序设计语言不允许[多重继承][Link 5].

即使是在这些允许多重继承的语言里,我们也有这样的问题,这个问题是Moveable类中的position与rotation应该与Renderable类中的position和rotation相等.

一个常用的解决方案是使用继承链,以便Moveable继承自Renderable

1.  class Moveable extends Renderable implements IMoveable 
2.  \{ 
3.   public var velocity:Point; 
4.   public var angularVelocity:Number; 
5.  
6.   public function move(time:Number):void 
7.   \{ 
8.   position.x += velocity.x; 
9.   position.y += velocity.y; 
10.  rotation += angularVelocity; 
11.  \} 
12. \}

1.  class Spaceship extends Moveable 
2.  \{ 
3.  \}

现在飞船既可以移动又可以渲染.我们可将同样的原则应用于其他的游戏对象来得到这样的类层级

![20140212200311468][]

我们甚至可以有只继承自Renderable的静态对象.

![20140212200414500][]

#### 可移动但是不可渲染(Moveable but not Renderable) ####

但如果我们想要一个可移动却不可渲染的对象将会怎样?比如,一个无形的游戏对象?这时我们的类层级失效了,我们需要一种Moveable接口不继承自Renderable的替代方案.

1.  class InvisibleMoveable implements IMoveable 
2.  \{ 
3.   public var position:Point; 
4.   public var rotation:Number; 
5.   public var velocity:Point; 
6.   public var angularVelocity:Number; 
7.  
8.   public function move(time:Number):void 
9.   \{ 
10.  position.x += velocity.x; 
11.  position.y += velocity.y; 
12.  rotation += angularVelocity; 
13.  \} 
14. \}

![20140212200646171][]

在一个简单的游戏中,这样做虽然有点笨但还是掌控的,但在一个使用继承来将进程应用于对象的复杂的游戏中就会迅速变得不可控制,因为你很快发现游戏里的对象不适应一个简单的线性继承树,就像上面的force-field一样.

#### 偏好使用合成超过继承(favour composition over inheritance) ####

长久以来面向对象编程的一条好原则就是[多使用合成][Link 6].在此处应用该原则可避免我们陷入潜在的继承紊乱.

我们仍旧需要Renderable和Moveable类,我们将创建包含这两个类实例的飞船类而不是继承这些类来创建飞船类.

1.  class Renderable implements IRenderable 
2.  \{ 
3.   public var view:DisplayObject; 
4.   public var position:Point; 
5.   public var rotation:Number; 
6.  
7.   public function render(time:Number):void 
8.   \{ 
9.   view.x = position.x; 
10.  view.y = position.y; 
11.  view.rotation = rotation; 
12.  \} 
13. \}

1.  class Moveable implements IMoveable 
2.  \{ 
3.   public var position:Point; 
4.   public var rotation:Number; 
5.   public var velocity:Number; 
6.   public var angularVelocity:Number; 
7.  
8.   public function move(time:Number):void 
9.   \{ 
10.  position.x += velocity.x; 
11.  position.y += velocity.y; 
12.  rotation += angularVelocity; 
13.  \} 
14. \}

1.  class Spaceship 
2.  \{ 
3.   public var renderData:IRenderable; 
4.   public var moveData:IMoveable; 
5.  \}

使用这种方法,我们可以以我们想要的任何方式来合并多种行为(behaviours)而不用遭遇继承问题.

![20140212201038828][]

通过这种合成生成的对象,静态对象,太空船,飞碟,小行星,子弹和force field都叫做实体(entities).

我们的线程依旧没有变化

1.  interface IRenderable 
2.  \{ 
3.   function render():void; 
4.  \}

1.  class RenderProcess implements IProcess 
2.  \{ 
3.   private var targets:Vector.<IRenderable>; 
4.  
5.   public function update(time:Number):void 
6.   \{ 
7.   for each(var target:IRenderable in targets) 
8.   \{ 
9.   target.render(); 
10.  \} 
11.  \} 
12. \}

1.  interface IMoveable 
2.  \{ 
3.   function move():void; 
4.  \}

1.  class MoveProcess implements IProcess 
2.  \{ 
3.   private var targets:Vector.<IMoveable>; 
4.  
5.   public function update(time:Number):void 
6.   \{ 
7.   for each(var target:IMoveable in targets) 
8.   \{ 
9.   target.move(time); 
10.  \} 
11.  \} 
12. \}

但我们不将飞船实体添加到每个线程而是添加飞船实体的成员.因此当我们创建飞船时所做如下:

1.  public function createSpaceship():Spaceship 
2.  \{ 
3.   var spaceship:Spaceship = new Spaceship(); 
4.   ... 
5.   renderProcess.addItem(spaceship.renderData); 
6.   moveProcess.addItem(spaceship.moveData); 
7.   ... 
8.   return spaceship; 
9.  \}

这种方法看起来很棒.它使我们可以自由打乱和匹配不同游戏对象之间的进程支持而无需陷入继承链或者重复造轮子,但这有一个问题.

#### 共享数据怎么样(What about the shared data?) ####

由于移动线程将会改变Moveable实例的值且渲染线程要使用Renderable实例的值,Renderable类实例中的position属性和rotation属性需要与Moveable类实例中的position和rotation属性数值相同.

1.  class Renderable implements IRenderable 
2.  \{ 
3.   public var view:DisplayObject; 
4.   public var position:Point; 
5.   public var rotation:Number; 
6.  
7.   public function render():void 
8.   \{ 
9.   view.x = position.x; 
10.  view.y = position.y; 
11.  view.rotation = rotation; 
12.  \} 
13. \}

1.  class Spaceship 
2.  \{ 
3.   public var renderData:IRenderable; 
4.   public var moveData:IMoveable; 
5.  \}

要解决这个问题,我们需要确保这两个类实例都指向这些属性的相同实例.在Actionscript中这意味着这些属性必须是对象,因为对象可以按引用传递而基础类型是按值传递的.

所以我们引入另一组类,我们称其为组件(components).这些组件是一些值对象,值对象将属性包裹在(wrap)对象中以便在进程间共享.

1.  class PositionComponent 
2.  \{ 
3.   public var x:Number; 
4.   public var y:Number; 
5.   public var rotation:Number; 
6.  \}

1.  class VelocityComponent 
2.  \{ 
3.   public var velocityX:Number; 
4.   public var velocityY:Number; 
5.   public var angularVelocity:Number; 
6.  \}

1.  class DisplayComponent 
2.  \{ 
3.   public var view:DisplayObject; 
4.  \}

1.  class Renderable implements IRenderable 
2.  \{ 
3.   public var display:DisplayComponent; 
4.   public var position:PositionComponent; 
5.  
6.   public function render():void 
7.   \{ 
8.   display.view.x = position.x; 
9.   display.view.y = position.y; 
10.  display.view.rotation = position.rotation; 
11.  \} 
12. \}

1.  class Moveable implements IMoveable 
2.  \{ 
3.   public var position:PositionComponent; 
4.   public var velocity:VelocityComponent; 
5.  
6.   public function move(time:Number):void 
7.   \{ 
8.   position.x += velocity.velocityX \* time; 
9.   position.y += velocity.velocityY \* time; 
10.  position.rotation += velocity.angularVelocity \* time; 
11.  \} 
12. \}

当我们创建飞船我们确保Moveable和Renderable实例共享相同的PositionComponent实例.

1.  class Spaceship 
2.  \{ 
3.   public function Spaceship() 
4.   \{ 
5.   moveData = new Moveable(); 
6.   renderData = new Renderable(); 
7.   moveData.position = new PositionComponent(); 
8.   moveData.velocity = new VelocityComponent(); 
9.   renderData.position = moveData.position; 
10.  renderData.display = new DisplayComponent(); 
11.  \} 
12. \}

进程仍没有受到该改变的影响.

#### 暂停的好地方(A good place to pause) ####

到目前为止我们有了整齐分开的任务.游戏循环(game loop)循环遍历(cycle through)进程,调用每个进程上的更新方法.每个进程包含了一个对象集合,集合中的对象实现了其操作的接口并将调用这些对象的适当方法.这些对象每个都对其数据做单一而重要的作业(task).通过组件系统,这些对象能够共享数据,因此多个线程的组合能够在游戏实体中产生复杂的更新同时保证每个进程相对简单.

这个架构类似于游戏开发中的许多实体系统.架构遵循了良好的面向对象程序设计原则且能够运转.但在更多事情到来之前,我们先开始疯一把

#### 放弃好的面向对象实践 ####

当前的架构使用了良好的面向对象实践,像[封装][Link 7]和[单一职责原则][Link 8](single responsibility)——IRenderable和IMoveable的实现封装了在每帧中游戏实体更新的单一职责的数据和逻辑——而[合成][Link 6]——Spaceship实体是通过组合IRenderable和IMoveable接口的实现而创建的.通过组件系统(system of components)我们确保在恰当的地方数据在实体的不同数据类之间共享.

实体系统改革中的下一步或多或少有点不直观,打破了面向对象程序设计的核心教条之一.我们在Renderable和Moveable实现中打破了数据和逻辑的封装.特别是我们将逻辑从这些类中抽出反而将其放置在进程中

所以这个

1.  interface IRenderable 
2.  \{ 
3.   function render(); 
4.  \}

1.  class RenderProcess implements IProcess 
2.  \{ 
3.   private var targets:Vector.<IRenderable>; 
4.  
5.   public function update(time:Number):void 
6.   \{ 
7.   for each (var target:IRenderable in targets) 
8.   \{ 
9.   target.render(); 
10.  \} 
11.  \} 
12. \}

变成了这个

1.  class RenderData 
2.  \{ 
3.   public var display:DisplayComponent; 
4.   public var position:PositionComponent; 
5.  \}

1.  class RenderProcess implements IProcess 
2.  \{ 
3.   private var targets:Vector.<RenderData>; 
4.  
5.   public function update(time:Number):void 
6.   \{ 
7.   for each(var target:RenderData in targets) 
8.   \{ 
9.   target.display.view.x = target.position.x; 
10.  target.display.view.y = target.position.y; 
11.  target.display.view.rotation = target.position.rotation; 
12.  \} 
13.  \} 
14. \}

而这个

1.  interface IMoveable 
2.  \{ 
3.   function move(time:Number):void; 
4.  \}

1.  class MoveProcesss implements IProcess 
2.  \{ 
3.   private var targets:Vector.<IMoveable>; 
4.  
5.   public function move(time:Number):void 
6.   \{ 
7.   for each(var target:Moveable in targets) 
8.   \{ 
9.   target.move(time); 
10.  \} 
11.  \} 
12. \}

变成了这样

1.  class MoveData 
2.  \{ 
3.   public var position:PositionComponent; 
4.   public var velocity:VelocityComponent; 
5.  \}

1.  class MoveProcess implements IProcess 
2.  \{ 
3.   private var targets:Vector.<MoveData>; 
4.  
5.   public function move(time:Number):void 
6.   \{ 
7.   target.position.x += target.velocity.velocityX \* time; 
8.   target.position.y += target.velocity.velocityY \* time; 
9.   target.position.rotation += target.velocity.angularVelocity \* time; 
10.  \} 
11. \}

(可能)不会立即明白为什么我们这么做,但是包涵一下.从表面上看,我们移除了接口的必要(removed the need for the interface),并且我们给线程更重要的事情来做——而不是简单的将其工作委托给IRenderable或者IMoveable的实现,它自己要做事(it does the work itself).

这样第一个明显的结果是所有的实体必须使用相同的渲染方法,因为渲染代码现在在RenderProcess里.但事实上并不这么回事.例如,我们能够有两个进程比如RenderMoveClip和RenderBitmap且它们能够处理不同的实体集.所以我们并没有丧失任何灵活性.

我们所得到的是重构我们实体的重要能力来产生一个架构,该架构有着明确的分工和简单的配置.重构以一个问题开始.

#### 我们需要数据类吗?(Do we need the data classes) ####

当前,我们的实体

1.  class Spaceship 
2.  \{ 
3.   public var moveData:MoveData; 
4.   public var renderData:RenderData; 
5.  \}

包含两个数据类

1.  class MoveData 
2.  \{ 
3.   public var position:PositionComponent; 
4.   public var velocity:VelocityComponent; 
5.  \}

1.  class RenderData 
2.  \{ 
3.   public var display:DisplayComponent; 
4.   public var position:PositionComponent; 
5.  \}

这些数据类反过来包含三个组件

1.  class PositionComponent 
2.  \{ 
3.   public var x:Number; 
4.   public var y:Number; 
5.   public var rotation:Number; 
6.  \}

1.  class VelocityComponent 
2.  \{ 
3.   public var velocityX:Number; 
4.   public var velocityY:Number; 
5.   public var angularVelocity:Number; 
6.  \}

1.  class DisplayComponent 
2.  \{ 
3.   public var view:DisplayObject; 
4.  \}

数据类由两个进程使用

1.  class MoveProcess implements IProcess 
2.  \{ 
3.   private var targets:Vector.<MoveData>; 
4.  
5.   public function move(time:Number):void 
6.   \{ 
7.   for each(var target:MoveData in targets) 
8.   \{ 
9.   target.position.x += target.velocity.velocityX \* time; 
10.  target.position.y += target.velocity.velocityY \* time; 
11.  target.position.rotation += target.velocity.angularVelocity \* time; 
12.  \} 
13.  \} 
14. \}

但是实体不应该关心数据类.组件共同(collectively)包含实体的状态.数据类为进程的方便而存在.因此我们重构代码以便spaceship实体包含组件(components)而不是数据类

1.  class Spaceship 
2.  \{ 
3.   public var position:PositionComponent; 
4.   public var velocity:PositionComponent; 
5.   public var display:DisplayComponent; 
6.  \}

1.  class PositionComponent 
2.  \{ 
3.   public var x:Number; 
4.   public var y:Number; 
5.   public var rotation:Number; 
6.  \}

1.  class VelocityComponent 
2.  \{ 
3.   public var velocityX:Number; 
4.   public var velocityY:Number; 
5.  \}

1.  class DisplayComponent 
2.  \{ 
3.   public var view:DisplayObject; 
4.  \}

通过移除数据类,使用构成组件(constituent components)替代来定义spaceship,我们移除了spaceship实体需要知道那个进程或许会对其起作用的必要(we have removed any need for the spaceship entity to know what process may act on it).spaceship现在包含定义其状态的组件.任何为进程要求合并这些组件到其他数据类都是别的类的事儿.

#### 系统与节点 ####

当进程需要时,实体系统框架(我们很快会接触到)中的一些核心代码会动态的创建这些数据对象.在这个简化的语境(reduced context)中,数据类将只是由进程使用的集合(数组,链表或者别的依据实现而不同)中的节点.所以为弄清楚这我们将它们重命名为节点.

1.  class MoveNode 
2.  \{ 
3.   public var position:PositionComponent; 
4.   public var velocity:VelocityComponent; 
5.  \}

1.  class RenderNode 
2.  \{ 
3.   public var display:DisplayComponent; 
4.   public var position:PositionComponent; 
5.  \}

进程并没有改变,但是为了保持共同的命名约定我也将它们的名称改变并称其为系统.

1.  class MoveSystem implements ISystem 
2.  \{ 
3.   private var targets:Vector.<MoveNode>; 
4.  
5.   public function update(time:Number):void 
6.   \{ 
7.   for each(var target:MoveNode in targets) 
8.   \{ 
9.   target.position.x += target.velocity.velocityX \* time; 
10.  target.position.y += target.velocity.velocityY \* time; 
11.  target.position.rotation += target.velocity.angularVelocity \* time; 
12.  \} 
13.  \} 
14. \}

1.  class RenderSystem implements ISystem 
2.  \{ 
3.   private var targets:Vector.<RenderNode>; 
4.  
5.   public function update(time:Number):void 
6.   \{ 
7.   target.display.view.x = target.position.x; 
8.   target.display.view.y = target.position.y; 
9.   target.display.view.rotation = target.position.rotation; 
10.  \} 
11. \}

1.  interface ISystem 
2.  \{ 
3.   function update(time:Number):void; 
4.  \}

#### 那实体又是什么呢?(And what is an entity?) ####

最后一点改变--Spaceship类没有什么特别的.他只是一个组件容器.所以我们将只称其为实体并给它一个组件集合.我们将根据这些组件的类类型(class type)来访问它们.

1.  class Entity 
2.  \{ 
3.   private var components:Dictionary; 
4.  
5.   public function add(component:Object):void 
6.   \{ 
7.   var componentClass:Class = component.constructor; 
8.   components\[componentClass\] = component; 
9.   \} 
10. 
11.  public function remove(componentClass:Class):void 
12.  \{ 
13.  delete components\[componentClass\]; 
14.  \} 
15. 
16.  public function get(componentClass:Class):void 
17.  \{ 
18.  return components\[componentClass\]; 
19.  \} 
20. \}

所以我们像这样创建我们的spaceship

1.  public function createSpaceship():void 
2.  \{ 
3.   var spaceship:Entity = new Entity(); 
4.   var position:PositionComponent = new PositionComponent(); 
5.   position.x = Stage.stageWidth / 2; 
6.   position.y = Stage.stageHeight / 2; 
7.   position.rotation = 0; 
8.   spaceship.add(position); 
9.   var display:DisplayComponent = new DisplayComponent(); 
10.  display.view = new SpaceshipImage(); 
11.  spaceship.add(display); 
12.  engine.add(spaceship); 
13. \}

#### 核心的引擎类 ####

我们决不能忘记系统管理器,之前叫做进程管理器

1.  class SystemManager 
2.  \{ 
3.   private var systems:PriorirtiesdList; 
4.  
5.   public function addSystem(system:ISystem,priority:int):void 
6.   \{ 
7.   systems.add(system,priority); 
8.   system.start(); 
9.   \} 
10. 
11.  public function update():void 
12.  \{ 
13.  for each(var system:ISystem in systems) 
14.  \{ 
15.  system.update(time); 
16.  \} 
17.  \} 
18. 
19.  public function removeSystem(system:ISystem):void 
20.  \{ 
21.  system.end(); 
22.  systems.remove(system); 
23.  \} 
24. \}

这将会被加强(enhanced)并处于我们实体系统框架的核心.我们将为其添加我们之前提到的功能以便为系统动态创建节点.

实体只关心组件,系统只关心节点.因此,要完成实体系统框架,当实体改变,为系统所用的节点结合添加或者删除组件式,我们需要监视实体的代码.因为这是实体和系统都知道的那一点代码,我们可能考虑将其作为游戏的中心.在Ash中,我称这为Engine类,它是系统管理器的一个增强版.

当你开始使用或停止使用Engine类时,每个实体和系统都被添加到或者从Engine类删除.Engine类跟踪实体上的组件并创建(和在必要时销毁)节点,将这些节点添加到节点集合中.Engine类也为系统提供了一种方法来得到其需要的集合.

1.  public class Engine 
2.  \{ 
3.   private var entities:EntityList; 
4.   private var systems:EntityList; 
5.   private var nodeLists:Dictionary; 
6.  
7.   public function addEntity(entity:Entity):void 
8.   \{ 
9.   entities.add(entity); 
10.  //create nodes from this entity's components and add them to node lists 
11.  //also watch for later addition and removal of components from the entity so 
12.  //you can adjust its derived nodes accordingly 
13.  \} 
14. 
15.  public function removeEntity(entity:Entity):void 
16.  \{ 
17.  //destory nodes from this entity's components 
18.  //and remove them from the node lists 
19.  entities.remove(entity); 
20.  \} 
21. 
22.  public function addSystem(system:System,priority:int):void 
23.  \{ 
24.  systems.add(system,priority); 
25.  system.start(); 
26.  \} 
27. 
28.  public function removeSystem(system:System):void 
29.  \{ 
30.  system.end(); 
31.  systems.remove(system); 
32.  \} 
33. 
34.  public function getNodeList(nodeClass:Class):NodeList 
35.  \{ 
36.  var nodes:NodeList = new NodeList(); 
37.  nodeLists\[nodeClass\] = nodes; 
38.  //create the nodes from the current set of entities 
39.  //and populate the node list 
40.  return nodes; 
41.  \} 
42. 
43.  public function update(time:Number):void 
44.  \{ 
45.  for each(var system:ISystem in systems) 
46.  \{ 
47.  system.update(time); 
48.  \} 
49.  \} 
50. \}

![20140213211713671][]

要查看该架构的一个实现,[checkout Ash实体系统框架][Ash]并看看例子[小行星游戏的实现][Link 9].

#### 结论 ####

所以,总结一下,实体系统发源于想要简化游戏循环.从哪里衍生出了实体架构,它代表着游戏的状态和系统,系统作用于游戏状态.系统在每帧中都会更新--这就是游戏循环.实体由组件(components)构成,系统作用于含有它们感兴趣的组件的实体.引擎管理者系统和实体并确保每个系统能够访问到一组有对应组件的实体集合.

然而,系统通常不关心作为整体的实体,只关心它们需要的特定组件.因此,要优化该架构并提供额外的净化度(additional clarity),系统作用于静态类型的包含对应组件的节点对象,在节点对象中这些组件都属于同一个实体.

一个**实体系统框架**为这种架构提供了基本的架子(scaffolding)和核心管理,没有提供任何实际的实体或者系统类.你通过创建对应的实体和系统来创建游戏.

一个**基于实体的游戏引擎**将在基本的框架上提供许多标准的系统和实体.

3个Actionscript实体系统框架是我自己的[Ash][],[Tom Davies][]的[Ember2][]和[Alec McEachran][]的[Xember][].[Artemis][]是一个java的实体系统框架,且已经移植到了[C\#][C].

[Ash]: http://www.ashframework.org/
[Unity]: http://unity3d.com/
[Ember2]: https://github.com/tdavies/Ember2
[Xember]: https://github.com/alecmce/xember
[try_harder]: http://www.tryharder.org.uk/
[Link 1]: http://www.richardlord.net/presentations/game-architecture-is-different
[Link 2]: http://en.wikipedia.org/wiki/Asteroids_%28video_game%29
[Link 3]: http://en.wikipedia.org/wiki/Game_programming#Game_structure
[Link 4]: http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29
[20140212195849875]: /images/20220731/07e02539ef244eef8e83673ebe2d557c.png
[Link 5]: http://en.wikipedia.org/wiki/Multiple_inheritance
[20140212200311468]: /images/20220731/989dd58eb8d7478c9bacca1f2759272d.png
[20140212200414500]: /images/20220731/db8431a33029428ba0d3d83e89a6a5fd.png
[20140212200646171]: /images/20220731/26eba85f269d4782a894e48e4289a4dd.png
[Link 6]: http://en.wikipedia.org/wiki/Composition_over_inheritance
[20140212201038828]: /images/20220731/fda3fc7bf7864895995adc908a272e44.png
[Link 7]: http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29
[Link 8]: http://en.wikipedia.org/wiki/Single_responsibility_principle
[20140213211713671]: /images/20220731/c34f91327a6c4178a68a967a00f4a79b.png
[Link 9]: https://github.com/richardlord/Asteroids
[Tom Davies]: http://www.tomseysdavies.com/
[Alec McEachran]: http://alecmce.com/
[Artemis]: http://www.gamadu.com/artemis/
[C]: https://github.com/thelinuxlich/artemis_CSharp