[翻译]LightRacer游戏架构

    1.0版本的Light Racer架构可说的不多。仅有一个单一的Activity，进行按钮的处理，显示游戏相关数据和显示GameView。我将在另一篇文章中说明游戏的画面是如何工作的，但是现在我先声明一下的就是：在Android中，单个Activity处理所有的事情不是一个好的主意。主视图是一个SurfaceView，只是它在游戏Main Class中启动。除了SoundManager和一个轻量级的播放器类（为给定的玩家保存状态、路径和动画信息），这个Main Class负责处理全部的事情了。这使得开发起来相对比较容易，但是当有新需求来的时候，例如需要有多个NPC，多个玩家，不同的2D和3D的显示等等，单个Activity如何处理这些问题呢？当然需要一个更好的设计了。

    新的设计是更有组织，也更抽象。下面将演示我是如何改变我的设计，来从Main Class中抽象出Game Object和Receivers，并给他们引入更多的职责。这个Main Class仅仅负责初始化环境，加载资源，初始化和配置World，运行游戏，并检测Android环境的变化。

    整个环境由：World（游戏所关注的，并且会显示给用户的），各种Manager（如声音、通知manager），以及各种对象池（因为如果不断的创建和回收对象，Android将变得很慢）。

    资源就是图形、声音、字体和颜色等等这类东西。游戏的许多部分都需要访问资源池，所以将这些资源统一由一个对象进行管理并且将其传递给需要调用资源的地方去，是一个很好的想法。例如，所有的GameObject都需要画图，因此他们需要通过资源管理器获取需要的bitmap。当需要清理游戏环境的时候，Main Class 将会调用资源管理器来进行资源的释放。

Main Class, World and Resources

    下图更加具体。Player 在这里是唯一的Game Object，但是你可以想象还有其他的，如一个障碍，或者是一个power-up item。所有这些都是Game Object，并且要负责绘图和动画。Play还需要做碰撞检测。如果最终加入了一个power-up item，还需要检查是否已经触及或者超过它了。一个Play是自我维护的，他知道自己的状态，知道自己是否还是活着的，或者已经死掉了。Play活动的轨迹就是它的路径，Play的动画，就是决定当前应该画哪一帧图画。

Game Objects, Players, Receivers and AI

    在这个新设计中Receiver是最大的关键点。目前，还不能想到一个更好的名字，想到的话，会重新命名，但它的功能不会改变，仍旧负责决定Player下一个行动方向。在LightRacer1.0版本中，Android的操作按钮直接绑定到一个字段，这个字段来控制Player的运动方向，这个字段的维护是通过检测物理方向的是否改变。在Game Class这儿大类中还有AI方面的代码，除了一号角色外的角色都是AI控制的。在新需求中采用了新的设计，采用了以下两个策略：1）Receiver完全是为了设置Player未来方向。 2）如果没有Receiver，Player永远继续其轨迹。

     这两条策略有意义吗？什么时候我们不需要Receiver？如果Player一直朝北，不改变方向，如果能做到不撞墙？

    下面我来回答以上问题。Receiver有多种类型。Player Receiver 与button和touch绑定在一起，当一个Player hits up时，Receiver就会设置下一个方向朝北。AI Receiver是一个抽象类，因此有多个不同的AI实现。我提供了三个：Easy、Medium、Hard。所有这些实现都是实现同样的目的：为Player确定下一个方向。Netwrok Reeiver有点令人困惑，我会在解释多玩家游戏之后，再来说明它。

    在Light Racer中，玩家可以发起一个游戏，也可以加入一个游戏。常规游戏可以有3名玩家，LR3D可以有4名玩家。每个Client预测当前正在发生什么，但是Host才是真正的权威。可以说，实际上，游戏是在Host上运行的，这意味着，当Host决定有一个碰撞，Client上就会有一个碰撞。这是一个简单的策略，因为遵循的规则是，Host的世界总是优于Client的。

     让我们来讨论以下的例子：

3 Player Network Example

    在这个例子中，有3个Player。一个Player是Host，第二个是Client，第三个是AI Player。Host 上的真人Player使用Human Receiver ，NetHost Receiver从Remote Player收集输入，AI Receiver 控制AI。每次Host 开始一个新循环，它更新world，并将整个world打包发送给Client。Client解包并覆盖当前的world。这是因为Host始终是权威。Client然后通过自己的NetClient Receiver处理输入。NetClient Receiver 有双重用途，它有一个Human Receiver，因此它可以收集来自真实Player的button点击事件和touch事件，然后设置下一次方向。然后，它会将这些变化通过网络发送给Host。

    如果每秒循环30次的话，你就知道为什么Client World为什么不需要Receiver。Client World是由Host更新，这意味着Client只需要告诉Host，它想做什么，以及画出client期望发生的。Host处理这些信息，并告诉Client实际上正在发生的。只要更新快且前后一致，就能达到目的。即使偶有小的卡壳，interpolation code 将会来处理，这样游戏运行起来仍将是很顺利的。

http://www.rbgrn.net/content/216-light-racers-new-game-architecture