Light Racer's New Game Architecture光速骑士新游戏架构入门（中英文对照版）

Light Racer's New Game Architecture

光速骑士新游戏架构入门（中英文对照版）

By Huibin Jia

Email：huibin.jia@gmail.com

声明：本文翻译经过作者Robert Green授权，一切权利归Robert Green所有。他的站点http://www.rbgrn.net/

Version 1.0 of Light Racer didn't have much to say for architecture. There was a single Activity which dealt with the buttons, showed instructions and displayed the main game View. I'll cover the way the menus are going to work in a different article but suffice to say for now that having a single Activity deal with multiple different things is not a good idea at all in Android. The main View was a SurfaceView and simply started up the main game thread. The Thread class was the main game and besides the Sound Manager and a very light Player class which held the state, path and animation information for any given player, there wasn't a whole lot to it. This made it easy to develop but the new requirements are to have NPCs (Non Player Characters), network multi-player, different 2D and 3D displays and more. How does one tackle such a problem? With a better design, of course.

       光速骑士（Light Racer暂且这么翻译）1.0版本并没有太多的框架可言。他就用一个Activty来处理所有的按键事件，显示指令和显示游戏视图。我XXX，有能力说在Android开发中用单独一个acticity处理那么多事情根本不是一个好主意。主视图是一个SurfaceView用来简单启动游戏线程。这个线程类就是游戏主体部分，除此之外还有声音管理和一个非常小的游戏者类，这个游戏者类为所有玩家提供状态信息，路径信息还有动画信息等。这样开发起来也很容易实现，但是新的需求接踵而来，我们需要有NPCs、网络多用户对战和更多的2D和3D显示效果。如何解决这些问题呢？当然需要一个更好的解决方案。

The new design is much more organized and also more abstract. The following slides will show how I am changing the design to delegate far more responsibility into the Game Objects and Receivers and away from the main class. The main class's job will be simply to initialize the environment, load resources, initialize and configure the world, run the game and watch for changes to the Android environment.

        新的方案更加抽象，需要更多的规划组织。接下来我将展示给你们我是如何重新设计的，我将更多的原先主类的责任委托交给游戏对象和接收者。主类的工作将会变成简单的初始化环境，加载资源，初始化配置周围信息（world找不到好的翻译），运行游戏和监视Android环境变化。

The environment consists of the world (everything a game cares about and will display to the user), various managers like sound and notification managers, any object pools (because Android gets slow if you are creating and GCing lots of objects) and hooks into the Android environment.

       环境包含world（游戏车的所有信息还有显示给用户的所有信息），各种管理者例如声音和消息提示管理者，对象池（因为过多的对象的创建和Gcing会使Android变慢），还有与Android环境交互的接口。

Resources are things like graphics, sounds, fonts, and colors. Many parts of the game need to access the resource pools so it's always a good idea to have them managed by one object and pass that one object to anything requiring resources. For example, all GameObjects are responsible for drawing themselves so they will need to get their bitmaps from the resource manager. The main game class will have the resource manager release its resources when it's time to clean the game environment up.

       资源文件包括图形，声音，字体和颜色等。因为游戏中很多部分都需要访问资源文件，所以设计一个对象传递资源给资源请求者，是个不错的主意。例如，所有的游戏对象需要绘制自身，那么他们就需要从资源管理者那个得到位图图像。还有当清除环境时，游戏主类就用资源管理器在释放所有资源。

Main Class, World and Resources

The next diagram is a bit more concrete and recognizable. Player is the only Game Object on here but you can imagine that there might be others, such as a barrier or a power-up item. All of these things are Game Objects and are responsible for drawing and animating themselves. The Player will be doing collision detection on itself to check for a crash. If I end up adding power-ups, it will also check to see if it has touched or passed over an item. A Player maintains its own position in the world. It also maintains it's state so it knows if it's still alive or crashed. The path is the trail of light. Animation means which frame of what kind of animation is currently being drawn.

       下面这张图更具体，也更好理解。游戏者是这里仅有的游戏对象，但你可以想象这里还有其他的对象，例如障碍物或者弹出的加速物品。所有这些事都是游戏对象在绘制和控制它们做出动作。游戏者会为碰撞做碰撞检测，也会检测是得到了还是错过了加速物品。游戏者会保存自己的方向信息，还有确定存活的状态信息，还有路径信息（就是光尾）和动画信息（就是目前需要绘制的动画的帧）。

Game Objects, Players, Receivers and AI

The big key element in this new design is the Receiver. I couldn't think of a better name at the time and this may be renamed when I do, but a Receiver is responsible for determining the next direction of the player. In LR 1.0, the Android button hooks were tied directly to a field that held the next direction of movement until the physics update could pick it up. It also had the AI code in the same big game class and assumed that any player that was not Player 1 was AI. That won't work for the new requirements so I'm designing this to make 2 policies: 1) The Receiver is entirely responsible for setting the next direction of a Player. 2) If there is no Receiver, the Player shall always continue (interpolate) on its trajectory.

        新方案中很重要的一个设计就是接收者。现在我不能想到更好的一个名字来表示它，先暂且这么叫吧，当我实际做的时候或许可以重新给他起个名字。一个接收者的主要是作用就是决定游戏者的下一个方向。在LR1.0中，XXXX。在原先的臃肿的类中也有AI代码，其中简单的假定不是游戏者1的就是AI。显然在新需求下是不能满足要求的，因此我制订了两个策略：1）接收者全部责任就是设定游戏者下一个方向。2）如果这里没有接受者，这个游戏者将继续它轨迹的方向。

Does policy 2 make sense? When would we not want a Receiver? Wouldn't that player always end up in the wall if it started North and continued without change?

      策略2有意义吗？什么时候不需要接收者呢？难道游戏者会不撞南墙不回头吗？

Let me start by answering that there are several types of Receivers. The Player Receiver is directly tied to the buttons and touch. When a player hits up, that receiver sets the next direction to North. Simple enough. The AI Receiver is abstract and so there can be several different AI implementations. I'm doing 3, which are Easy, Medium and Hard. The different implementations may be better at playing than one another but they all end up outputting only one thing: The next direction for their Player. The network receivers are the most confusing. I'll explain the way multi-player games will work and then get back to them.

      下面我来开始回答大家这几种类型的接收者。游戏接收者直接绑定在按键事件和触摸事件上。当一个游戏者按方向键上时，接收者就会设定下一个方向为向北。非常简单。AI接收者是抽象的，他有三种实现：简单、中等和困难。这三个实现一个比一个难，但是他们都有一个相同的输出，那就是游戏者的下一个方向。网络接收者最难理解。将会在多用户游戏中解释。

In Light Racer, you will be able to host a game or join a game. There can be up to 3 players for the regular game and 4 players for LR3D. The clients each "estimate" what is happening but the host is the real authority. One could say that the actual, authoritative game runs on the host. This means that when the host decides there was a crash, there was a crash. This is an easy strategy to follow because the rule is that the host's world always overrides anything on the client.

        在光速骑士中，你可以建立或者参加一个游戏。常规赛事3个玩家，3D赛是4个玩家。这个客户端似乎在抉择下次方向，实际这些都在服务器上处理。或者说真实的游戏在服务器端运行。这意味服务器决定这里有碰撞，这里就有碰撞。这是一个非常简单易行的策略，因为这个规则就是总是用服务器的world重写客户端的任何事情。

Let's discuss the following example: 让我们讨论下面一个例子：

3 Player Network Example

In this example, there are 3 players. One player is the host of the game, the second is a client and the third is an AI player. The configurations are different in that the host uses a Human Receiver for the person playing, a NetHost Receiver to pick up the input from the remote player and an AI Receiver to control the AI. Every time it ticks and updates the world, it packages the world up and sends it to the client. The client unpackages the world and overwrites its current world. This is because the host is always the authority. The client then processes input from its one Receiver, which is a NetClient Receiver. The NetClient Receiver is dual-purpose. It has a Human Receiver so it can take button presses and touch events from the real player and that will set the next direction, but then it also immediately sends that over to the host via the network connection.

        在这个例子中，这里有三个玩家。游戏者是游戏主机，第二个是客户端玩家，第三个是AI玩家。它们在服务器上的配置信息是不同的。主机用人类接收者对应正在玩游戏的人，用网络主机接收者接收远程的客户玩家的输入，AI接收者来控制AI。每个周期更新一次world，主机会打包world并发送给客户端。客户端解包之后覆盖自己当前的world。这是因为主机是真正运行的。这个客户端从网络客户端接收者处理输入信息。他有双重作用，首先他是一个人类接收者，可以处理用户输入事件，并且他也会立即发信息通过网络发给主机。

If you can imagine that happening around 30 times per second, you can see why the Client World does not need Receivers. Its World is always being updated by the host and the Players in that world are located and on the trajectory that the World dictates. This means that the client simply tells the host what it would like to do and draws what it thinks is happening. The host processes this and tells the client what actually happened. So long as the updates are fast and consistent, this will work. Even if there are small stutters, the interpolation code will take care of it and things will still look mostly smooth.

       你可以认为这个每秒三十次，你就可以理解为什么客户端环境不需要接收者了。它的信息会被服务器实时更新，玩家的位置和轨迹也是有world指挥的。这意味着客户端简单的告诉主机他想做什么，他想下面发生什么就可以了。然后主机处理并且告诉客户端如何做。因此这个更新能够快速同步工作。即使这里有一些阻塞，这个中断代码也会处理好，保证游戏看起来运行流畅。

In a few weeks I will address the issue of 2D and 3D code both running from the same codebase.

       在接下来的几周里我会主要解决2D和3D代码在运行在同一引擎上的问题。

       注意：红色部分是不太确定怎么翻译的，以上翻译仅为业余之作，翻译不当之处还请大家联系我huibin.jia@gmail.com