下面是Maze迷宫的坐标计算
01.// maze level data
02.private static int[] mMazeData;

这个一维数组存放所有的tile的类型
01.// maze tile size and dimension
02.private final static int TILE_SIZE = 16;
03.private final static int MAZE_COLS = 20;
04.private final static int MAZE_ROWS = 26;

01.// tile types
02.public final static int PATH_TILE = 0;
03.public final static int VOID_TILE = 1;//death area
04.public final static int EXIT_TILE = 2;//the target
而这个坐标的读取是通过从文件读取的，当然也可以通过写几个数组的形式，但是以文件的形式的话就不需要修改代码就可以实现软件的修改是一种比在代码中写几个大的数组要好的形式。

01./**
02. * Load specified maze level.
03. *
04. * @param activity
05. * Activity controlled the maze, we use this load the level data
06. * @param newLevel
07. * Maze level to be loaded.
08. */
09. void load(Activity activity, int newLevel) {
10. // maze data is stored in the assets folder as level1.txt, level2.txt
11. // etc....
12. String mLevel = "level" + newLevel + ".txt";
13.
14. InputStream is = null;
15.
16. try {
17. // construct our maze data array.
18. mMazeData = new int[MAZE_ROWS * MAZE_COLS];
19. // attempt to load maze data.
20. is = activity.getAssets().open(mLevel);
21.
22. // we need to loop through the input stream and load each tile for
23. // the current maze.
24. for (int i = 0; i < mMazeData.length; i++) {
25. // data is stored in unicode so we need to convert it.
26. mMazeData[i] = Character.getNumericValue(is.read());
27.
28. // skip the "," and white space in our human readable file.
29. is.read();
30. is.read();
31. }
32. } catch (Exception e) {
33. Log.i("Maze", "load exception: " + e);
34. } finally {
35. closeStream(is);
36. }
37. }
mMazeData数组存放了每个tile是什么类型的，MAZE_ROWS一共有多少行，MAZE_COLS一共多少列，TILE_SIZE每个tile的宽度，这样就可以在界面上画出来整个界面的布局

01./**
02. * Draw the maze.
03. *
04. * @param canvas
05. * Canvas object to draw too.
06. * @param paint
07. * Paint object used to draw with.
08. */
09. public void draw(Canvas canvas, Paint paint) {
10. // loop through our maze and draw each tile individually.
11. for (int i = 0; i 0)
22. mLocation = mCellRow * MAZE_COLS;
23.
24. // add the column location.
25. mLocation += mCellCol;
26.
27. return mMazeData[mLocation];
28. }
/**
* Determine which cell the marble currently occupies.
*
* @param x
* Current x co-ordinate of marble on the screen.
* @param y
* Current y co-ordinate of marble on the screen.
* @return The actual cell occupied by the marble.
*/
public int getCellType(int x, int y) {
// convert the x,y co-ordinate into row and col values.
int mCellCol = x / TILE_SIZE;
int mCellRow = y / TILE_SIZE;

// location is the row,col coordinate converted so we know where in the
// maze array to look.
int mLocation = 0;

// if we are beyond the 1st row need to multiple by the number of
// columns.
if (mCellRow > 0)
mLocation = mCellRow * MAZE_COLS;

// add the column location.
mLocation += mCellCol;

return mMazeData[mLocation];
}下面是Marble小球的坐标计算

01.// marble attributes
02.// x,y are private because we need boundary checking on any new values to
03.// make sure they are valid.
04.private int mX = 0;
05.private int mY = 0;
06.private int mRadius = 8;
07.private int mColor = Color.WHITE;
08.private int mLives = 5;

在AmazedView中的onDraw()调用gameTick()的时候会更新小球Marble的坐标：

01./**
02. * Called from gameTick(), update marble x,y based on latest values obtained
03. * from the Accelerometer sensor. AccelX and accelY are values received from
04. * the accelerometer, higher values represent the device tilted at a more
05. * acute angle.
06. */
07. public void updateMarble() {
08. // we CAN give ourselves a buffer to stop the marble from rolling even
09. // though we think the device is "flat".
10. if (mAccelX > mSensorBuffer || mAccelX mSensorBuffer || mAccelY 0) {
19. // user still has some lives remaining, restart the level.
20. mMarble.death();
21. mMarble.init();
22. mWarning = true;
23. } else {
24. // user has no more lives left, end of game.
25. mEndTime = System.currentTimeMillis();
26. mTotalTime += mEndTime - mStartTime;
27. switchGameState(GAME_OVER);
28. }
29.
30. } else if (mMaze.getCellType(mMarble.getX(), mMarble.getY()) == mMaze.EXIT_TILE) {
31. // user has reached the exit tiles, prepare the next level.
32. mEndTime = System.currentTimeMillis();
33. mTotalTime += mEndTime - mStartTime;
34. initLevel();
35. }
36. }

在Marble中更新小球坐标：

01./**
02. * Attempt to update the marble with a new x value, boundary checking
03. * enabled to make sure the new co-ordinate is valid.
04. *
05. * @param newX
06. * Incremental value to add onto current x co-ordinate.
07. */
08. public void updateX(float newX) {
09. mX += newX;
10.
11. // boundary checking, don't want the marble rolling off-screen.
12. if (mX + mRadius >= mView.getWidth())
13. mX = mView.getWidth() - mRadius;
14. else if (mX - mRadius < 0)
15. mX = mRadius;
16. }

if-else中是对左右边界的处理，同样的是对上下边界的处理。

事实上，这种想法完全是没有必要且不符合实际的，作为能和苹果iOS分庭抗礼的Android（各种意义上），当然也会有相当数量的游戏引擎存在。仅仅因为我们处于这个狭小的天地间，与外界接触不够，所以对它们的存在茫然不知罢了。

下面我就罗列出八款常见的Android游戏引擎，以供有需要者参考（收费，下载量过小，不公布源码，以及鄙人不知道（-_-）的引擎不在此列）。
1、Angle

Angle是一款专为Android平台设计的，敏捷且适合快速开发的2D游戏引擎，基于OpenGL ES技术开发。该引擎全部用Java代码编写，并且可以根据自己的需要替换里面的实现，缺陷在于文档不足，而且下载的代码中仅仅包含有少量的示例教程。

最低运行环境要求不详。

项目地址：http://code.google.com/p/angle/
2、Rokon

rokon是一款Android 2D游戏引擎，基于OpenGL ES技术开发，物理引擎为Box2D，因此能够实现一些较为复杂的物理效果，该项目最新版本为 2.0.3 (09/07/10)。总体来说，此引擎最大的优点在于其开发文档相当之完备，并且项目作者对反馈Bug的修正非常之神速，所以该框架的使用在目前也最为 广泛，有人干脆将它称为Cocos2d-iPhone引擎的Android版（业务逻辑和编码风格上也确实很像）。附带一提，国内某个需要注册会员才能下 载的Android游戏框架衍生于此框架，所以大家也不要刻板的认为收费便一定是好的，免费就一定不好。

最低运行环境要求为Android 1.5。

项目地址：http://code.google.com/p/rokon/

3、LGame

LGame是一款国人开发的Java游戏引擎，有Android及PC(J2SE)两个开发版本，目前最高版本同为0.2.6(31/07/10)。其底 层绘图器LGrpaphics封装有J2SE以及J2ME提供的全部Graphics API（PC版采用Graphics2D封装，Android版采用Canvas模拟实现），所以能够将J2SE或J2ME开发经验直接套用其中，两版本 间主要代码能够相互移植。Android版内置有Admob接口，可以不必配置XML直接硬编码Admob广告信息。

该引擎除了基本的音效、图形、物理、精灵等常用组件以外，也内置有Ioc、xml、http等常用Java组件的封装，代价是jar体积较为庞大，PC版 已突破1.2MB，Android版有所简化也在500KB左右。此外，该引擎还内置有按照1:1实现的J2ME精灵类及相关组件，可以将绝大多数 J2ME游戏平移到Android或PC版中。唯一遗憾的是，该项目作者是个极其懒惰的家伙，开发文档从去年说到今年依旧没有提供，只有游戏示例可供下 载。

最低运行环境要求为Android 1.1。

项目地址：http://code.google.com/p/loon-simple/

4、AndEngine

andengine同样是一款基于OpenGL ES技术的Android游戏引擎，物理引擎同样为Box2D（标配|||）。该框架性能普通，文档缺乏，但示例较为丰富。

下载地址（未直接提供jar下载，源码可通过svn提取）：http://code.google.com/p/andengine/

最低运行环境要求不详。

项目地址：http://code.google.com/p/rokon/
5、libgdx

libgdx是一款基于OpenGL ES技术开发的Android游戏引擎，支持Android平台下的2D游戏开发，物理引擎采用Box2D实现。单就性能角度来说，堪称是一款非常强大的 Android游戏引擎，但缺陷在于精灵类等相关组件在使用上不够简化，而且文档也较为匮乏。

最低运行环境要求不详。

项目地址：http://code.google.com/p/libgdx/
6、jPCT

jPCT是一款基于OpenGL技术开发的3D图形引擎(PC环境为标准OpenGL，Android为OpenGL ES)， 以Java语言为基础的，拥有功能强大的Java 3D解决方案。该引擎与LGame（此为2D游戏引擎）相类似，目前拥有PC(J2SE)以及Android两个开发版本。

jPCT的最大优势之一，就在于它惊人的向下兼容性。在PC环境中，jPCT甚至可以运行在JVM1.1环境之中，因为jPCT内部提供的图形渲染接口完 全符合所有的Java 1.1规范（就连已经消失的Microsoft VM乃至更古老的Netscape 4 VM也不例外）。

最低运行环境要求为Android 1.5。

项目地址：http://www.jpct.net/jpct-ae/
7、Alien3d

Alien3d是一款体积非常之小的Android 3D游戏引擎，基于OpenGL ES技术开发。为了压缩体积，它根据不同功能采用多jar方式发布（包括alien3d-engine.jar，alien3d- tiled.jar，alien3d-sprites.jar，alien3d-shapes.jar，alien3d- particles2d.jar，），事实上它的核心文件大约只有40KB，所有相关jar的总和也不足150KB。

最低运行环境要求为Android 1.5。

项目地址：http://code.google.com/p/alien3d/
8、Catcake

Catcake是一款跨平台的Java 3D图形引擎，目前支持PC(J2SE)及Android环境运行（已有iPhone版规划）。该引擎在易用性和运行性能上皆有出色的表现，支持常见的游戏开发功能，诸如精灵动画，音频处理和视频播放等。

最低运行环境要求为Android 1.6。

项目地址：http://code.google.com/p/catcake/

作者：英特尔：卢卷彬, Kiefer Kuah 巨人：余娜娜

下载PDF版本：使用英特尔GPA优化《兵王》游戏的性能

1. 介绍

《兵王》是由巨人网络公司旗下，上海巨贤公司耗时两年自主研发的一款未来战争MMORGP。《兵王》使用了优秀的3D引擎技术，在声光特效方面有极其优秀的表现。为了使《兵王》能够流畅的运行在更多玩家的机器上，我们在英特尔 集成显卡上对游戏进行了优化。英特尔集成显卡的出货量非常大，超过了60%（Q3’2011, Jon Peddie Research统计），其性能和特性也日益增强，是游戏开发者应该重点关注的对象。为了帮助游戏开发者在英特尔集成显卡上优化游戏性能，英特尔推出了一款出色的免费的性能分析工具，英特尔图形性能分析器(Graphics Performance Analyzers, 简称GPA)，不用修改游戏的代码，不用安装特殊的驱动版本就能够使用。游戏开发者可以利用这个工具清晰的了解自己的游戏在什么地方耗费了更多的时间，以进行有针对性的优化。GPA是我们在这次优化中使用的主要工具。

2. 优化准备

以下的分析和优化基于Intel HD Graphics 3000硬件平台，代号Sandybridge(简称SNB)，SNB拥有出色的图形性能，完全可以满足绝大多数网络游戏对性能的需求。我们使用的操作系统为Windows 7， 64位版本，GPA版本为4.2。

关于优化场景的选择，《兵王》支持大规模的群体作战，开发者对这种场景下的游戏性能特别关注，所以我们选择的是以下的一个群体战斗场景，其中有~100个玩家，并且有大量的武器和技能特效，游戏的性能在这个时候遇到很大的挑战，只有10fps左右，如图1所示：

图1，性能分析和优化的目标场景，有~100个玩家和坐骑，大量的技能特效，fps为10左右

3. GPA系统分析器HUD

GPA HUD可以从平台的角度分析游戏的性能，它提供了超过80个关于CPU，D3D runtime和GPU的性能指标，以及Null Hardware，Disable all draw calls， 1x1 ScissorRect， 2x2 Texture，Simple Pixel Shader等覆盖模式，收集这些性能指标和覆盖模式得到的数据，可以帮助我们分析出游戏的瓶颈所在。使用GPA HUD分析游戏的这个场景后我们得到以下的结果：

游戏在该场景下，FPS只能维持在10左右，此时的Null Hardware 和Null Driver覆盖模式分别只能达到14fps和20fps左右，也就是说显卡无限快的时候，游戏也只能跑到14fps，因此游戏在CPU上的性能消耗非常大。游戏有7800多个draw calls，这个一个非常大的数字。大量的draw calls，会导致游戏程序，D3D runtime以及显卡驱动等这些CPU上的计算量增加，由此导致性能非常的低。所以，游戏在这个场景中的优化重点，应该是合并小的画图操作，减少draw calls和State Changes的数量，这样可以同时减少CPU和GPU上的负担。

4. GPA帧分析器

GPA可以抓取游戏的一帧数据，然后使用帧分析器进行离线的详细分析。帧分析器打开一帧的过程，就相当于是重新发送指令让GPU渲染出这一帧。帧分析器界面主要包含上部分的柱状图(A)，它们代表的是游戏中按照调用顺序排列的Clear， Draw Primitive，StretchRect等，我们统称为ergs，可以通过设置X轴和Y轴来快速的定位最耗时的调用，比如X轴设为GPU Duration，Y轴设为GPU Breakdown。界面左边中间(B)是所有ergs的列表，左边下面(C)是Render Target，右边下面(D)是一系列Tab，包括性能数据，ergs的纹理，shader，state，API log等等。我们在目标场景中抓取了一帧数据，下图2是使用帧分析器打开这帧数据的界面：

图2，帧分析器打开场景的界面

从图2所示的帧分析器界面我们可以看出，渲染这一帧GPU花费的时间为71ms。游戏的渲染步骤是先生成阴影贴图（0-1198），然后是正常场景的渲染，最后是后处理以及UI部分。

阴影贴图使用了1198个draw calls，通过GPA帧分析器的纹理tab可以查看这些draw calls所使用的纹理，我们发现，游戏对某些特效也计算了阴影：

图3，生成阴影贴图的draw calls中，发现了特效的纹理，游戏对特效也计算了阴影

如图3所示，选中的那个纹理，以及相邻的纹理，都是特效相关的，而游戏设计之初并没有要求计算它们的阴影，可以移除掉。

另外，游戏花费了5526个draw calls来渲染场景中的所有物体，占了整个一帧的72.6%的时间。这5526个draw calls中，有超过4000个是渲染特效部分，它们占用了整个一帧44.9%的时间，这是优化的重点目标，如图4所示，在界面的render target那里可以看到所有的特效：

图4，渲染特效的draw calls有4079个，占用一帧44.9%的时间

通过查看和分析这些特效，我们发现每一个特效的draw call所渲染的东西都是非常小的，而且它们所使用纹理，多数都是小纹理，如下所示：

图5，特效的draw call都很小，10个draw calls只渲染了一小部分特效

上图5中，选中的这10个相邻的draw calls使用的都是这个128*128的蓝色纹理，所渲染的东西也是相邻的，我们可以考虑合并这几个draw calls。同时，考虑到纹理比较小，我们还可以合并相邻的特效纹理，这样可以减少SETTEXTURE的次数，也减少了CPU端的消耗。

坐骑和人物部分的渲染，也划分得很细，头发，脸孔，衣服，武器等都是由单独的draw call完成。这些也可以进行适当的合并，从而减少draw calls和state changes的数量。

5. 优化策略和结果

5.1 移除特效的阴影计算

如前面的图3所示，游戏中对特效也计算了实时阴影，一般来说，特效是不需要计算阴影的。移除掉这些draw calls后，生成阴影贴图 的draw calls从1198个减少到了860个， 这部分的GPU时间消耗从6.5ms减少到了4.86ms。

5.2 合并特效draw calls和纹理

由前面的分析我们知道，要优化游戏在该场景下的性能，最重要的就是减少CPU端的消耗，也就是要减少游戏的draw calls和State Changes的数量。场景中特效的draw calls数量是最多的，而且特效的draw calls都是非常小的，所以我们首先来合并特效的draw calls。

图6，优化前，使用了37个draw calls来完成右边的特效

图7，优化后，对特效的顶点和纹理都进行了合并，使用一个draw call就完成了类似的特效

从以上图6和图7的对比我们看到，合并优化后，渲染相同的特效，我们减少了draw calls的数量，从37减少到1，纹理也从4个合并到1个。整个一帧，特效的draw calls数量从4000多次减少到了700多次，set texture的次数从3764减少到2029次。整个特效部分的GPU时间从45ms减少到了21ms，提升非常明显！下图8为优化后的结果：

图8，优化后整个特效部分的draw call数量减少到了706个左右，特效的GPU时间从45ms减少到了21ms

5.3 合并人物和坐骑的渲染

游戏对人物的渲染区分很细，帽子，头发，衣服，裤子，鞋子，武器等都由独立的draw calls来完成，对坐骑也是由3个draw calls来完成的，虽然他们使用的是同样的纹理。以下以坐骑为例，将优化前需要3个draw calls完成的渲染，合并为一个draw call来完成。

图9，优化前，使用了3个draw calls来完成一个坐骑的渲染

图10，优化后，合并了坐骑的IB和VB，使用一个draw call就能完成坐骑的渲染

如上图9和图10所示，优化前需要用3个draw calls来完成一个坐骑的渲染，我们合并了坐骑的IB和VB，优化后只需要一个draw call就完成了这个坐骑的渲染。整个一帧有~100个坐骑，合并优化后，节省了~200个draw calls。

我们针对人物也进行了类似的合并优化，也节省了200个左右的draw calls。

5.4 移除重复的SETTEXTURE

为了减少CPU端的消耗，我们还应该尽量减少state changes的数量，在帧分析器对另外一个场景的分析中，我们发现，每个draw call都会设置自己所需要的所有纹理，而不管是否和上一个draw call使用了相同的纹理。

图11， 相邻的2个draw calls，使用一样的纹理，但是他们都重新设置了一次

如图11所示，柱状图中选中的临近的2个draw call，是在画地形部分，即使它们使用的是完全相同的纹理，它们也都重新调用了5次完整的的SETTEXTURE API。该场景中整个一帧总共有1837个SETTEXTURE API 调用。这不是有效率的做法，如果相邻的draw call使用的是同样的纹理，可以不用调用SETTEXTURE再次设置，这样可以减少state changes的数量，提高游戏性能。

以下是优化后的截图，移除掉了重复的不必要的SETTEXTURE API调用，如图12所示，第二个地形draw call本身已经没有调用set texture了。经过优化后，整个一帧所调用的SETTEXTURE API次数从1837次减少到了554次。

图12，优化后，如果纹理没有变化，则不重复设置了

经过以上几种优化，我们把《兵王》在这个场景下的draw calls数量从7839次减少到了3812次，SETTEXTURE API调用次数从3764次减少到了2029次。游戏帧率从10fps提升到了20fps左右，基本能够流畅的运行，达到了游戏开发者的期望。

6. 总结

本文介绍了使用GPA对《兵王》进行性能分析和优化的过程，从中我们可以看出，游戏客户端的性能优化并不难，我们所使用的优化方法也都很常见，但重要的是如何很快的找到这些游戏热点和瓶颈。在《兵王》的性能分析和优化过程中，GPA发挥了非常重要的作用，通过它我们很容易就发现了游戏的瓶颈，进行针对性的优化，游戏的性能得到了很大的提升。我们将继续使用GPA进一步优化游戏。

作者简介

卢卷彬 英特尔公司的应用工程师，他和国内几家大的游戏公司有着多年的合作，帮助他们在英特尔平台上优化游戏客户端的性能。

余娜娜 巨人前传技术部经理，参与开发过3DRPG《仙剑奇侠传三-问情篇》，3DMMORPG《巨人》、《兵王》。主要致力于3D引擎的研制开发，与Intel的几年合作中，极大提升了自主研发的3D引擎的特性，在效果提升的基础上，同屏人数也大大提升。

Kiefer Kuah 英特尔的软件工程师，他主要负责游戏在英特尔平台上的优化工作。

sessionStorage.varName = “生成新变量”;
sessionStorage.varName = “变量操作”;
delete sessionStorage.varName;  //删除变量

另外一种是本地存储，当网页下次被打开的时候，你仍然可以访问上次打开该网页时存储的数据，比如本地存储的网站用户名就可以使用这种方式。
用法和基于会话的存储一样，只是前缀名改成了localStorage

localStorage.varName = “生成新变量”;
localStorage.varName = “变量操作”;
delete localStorage.varName;  //删除变量

从上面可以看出web storage其实也只是解决了轻量级的数据存储问题，如果是大量的数据查询，比如商品列表，还是得靠数据库,HTML5中有Web Database来支持这一操作，基本操作和SQL一致。
注1：现在的浏览器基本都支持多窗口了，一个窗口对应一个网页
注2：官方参考

介绍

 性能分析开始

 系统分析

帧分析

1. 生成阴影贴图：~170 个 DP Calls, 15.9% frame time。场景中所有的物体都计算了实时阴影。我们可以使用静态阴影来替代其中的一部分，比如某些距离远的，固定的物体。
2. 天空盒: 3个 DP Calls，4.7% frame time。实际上在该场景中看不到天空，我们可以在渲染天空盒之前进行可见性检测。如果不可见，则不渲染。
3. Terrain：50个 DP Calls，34.9% frame time。和大多数网络游戏一样，地形总是最耗时的部分，是优化的重点。
4. 人物和其他地上物件：~240个DP Calls，22.4% frame time。没有发现明显的可以优化的地方。
5. 后处理：8个DP Calls，8.4% frame time。没有发现明显的可以优化的地方。
6. UI：55 DP Calls，7.4% frame time。有许多UI元素过小，可以合并一下再渲染。UI并不是每帧都变化的，可以重复利用上一帧的结果。

优化策略和结果：

 1. 阴影贴图生成

 4. UI

 5. 减少State Changes数量

优化总结：

 Appendix A:

Platform Configuration:CPU:  Intel Core i7-2720QM @ 2.20GHz, with HD 3000 graphics

在上一篇内容中，我们了解到建好项目后生成的Game1类是继承自Microsoft.Xna.Framework.Game类型，然后再重写其中的方法，也就是说，我们的游戏主体这个Game1并不一定非要是这样的命名，当然你可以更改一个其他的名字，但是在改类名后，对应的在Program类的Main法中new的对象得相对应的变更为你改过的类型。

一、Game1中的字段：

GraphicsDeviceManager graphics;

SpriteBatch spriteBatch;

其中GraphicsDeviceManager为绘制界面管理类型。

SpriteBatch 为精灵处理类型（绘制处理类型）。

二、构造方法：

01.public Game1() {
02. graphics = new GraphicsDeviceManager(this); //初始化为界面管理对象
03. Content.RootDirectory = "Content"; //设置内容读取的目录
04.}
构造方法中：将graphics对象先创建出来，并规定Content的目录在Content文件夹之下。

三、Initialize方法：

01.protected override void Initialize() {
02. base.Initialize();
03.}
作用：改写原父类型的初始方法。

说明：因为Microsoft已经把繁复的初始内写在父类型当中变得相当简化，直接调用base(基底类型)使用即可所以可以让我们专心在游戏重点的初始化。

也就是说，Microsoft为我们提供可更改初如化的机会。

四、LoadContent方法：
01.protected override void LoadContent() {
02. spriteBatch = new SpriteBatch(GraphicsDevice);
03.}
作用：在游戏启动时加载资源，如声音、图片、3D模型、字体等。
说明：方法中根据GraphicsDevice（绘制界面）创建了spriteBatch（绘制处理）对象。同时可以看到，在LoadContent方法中，并没有Base.LoadContent()方法，因为父类为Game基础来，在该类中并不需要去加载游戏资源，只有在我们制作游戏时才需要加载资源。

五、UnloadContent方法：

01.protected override void UnloadContent() { ... }
该重写方法是用来回收内容。在关闭游戏时，需要将游戏资源释放掉可以在该方法中完成。

六、Update方法：

01.protected override void Update(GameTime gameTime) {
02. if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
03. this.Exit();
04. base.Update(gameTime);
05.}
作用：重写了逻辑更新的方法。

其中：GameTime对象可以取得游戏时间。

GamePad对象可以得知玩家1是否按下了倒退键而退出游戏。

七、Draw方法：

01.protected override void Draw(GameTime gameTime) {
02. GraphicsDevice.Clear(Color.CornflowerBlue);
03. base.Draw(gameTime);
04.}
作用：重写了绘制游戏的部分。

说明：使用GameDevice对象Clear方法，把画面清成淡蓝色，同时也调用父类型进行运作。

八、注意Update与Draw方法：

1.Update跟Draw会连续进行每秒钟60HZ的更新速度来跑动游戏。

2.其他几个方法，分别为游戏启动时或关闭时进行调用。

3.如果我们想控制游戏的速度，可以通过Update中的GameTime定义

通过以上介绍，大概对XNA框架中，一些基本类及方法的作用及说明有了简单的了解。在以后的内容中，我们再详细介绍每个方法中如何编写代码，实现游戏的运行。

一、XNA简介

XNA是基于DirectX的游戏开发环境。

以C# 为开发语言

以 .NET Framework 为基础、并加入游戏应用所需之函式库所构成的 XNA Framework
可开发XNA for Windows Phone游戏，Xbox游戏，PC游戏等。

二、XNA Versions

XNA Game Studio Express
XNA Game Studio 2.0（VS2005）
XNA Game Studio 3.0（VS2008）
XNA Game Studio 3.1（VS2008）
XNA Game Studio 4.0（VS2010）
官方介绍 ：http://msdn.microsoft.com/zh-cn/windowsphone/gg315893
相关工具包：
Windows Phone Developer Tools工具包
以上SDK安装包可以在微软网站

三、创建项目
安装好SDK工具包后，可以打开VS来进行项目的创建，我这里使用的版本是VS2010,安装的是XNA Game Studio 4.0。

四、解决方案

创建好项目后，可以在解决方案管理器中看到以下内容。其中Program类中，放着整个游戏程序的入口点。

五、游戏的主函数

01.static void Main(string[] args) { 02. using (Game1 game = new Game1()) { 03. game.Run(); 04.} 05.}
通常每一个桌面应用程序都有一个Main方法，做为整个应用程序的入口点，其中的参数“args”的作用是在执行.exe文件的时候，可以将命令行参数传进方法中，从而进行对应的操作。 在方法体中，用using创建了Game1类型的对象game，并执行了Run()方法来启动整个游戏。

六、注意Program中的预编译指令
01.#if WINDOWS || XBOX 02. //游戏在 Windows 平台和 XBOX 游戏是否会执行代码 03.#else 04. //游戏在WP7上时执行代码 05.#endif

七、关于Game1类

01.public class Game1 : Microsoft.Xna.Framework.Game { ...... }
可以看到Game1类型，是继承Microsoft.Xna.Framework.Game类型的。另外再看下Game1类中的方法都使用了override关建字。

从以上图可以看出来微软的XNA框架为我们提供的Game类，本身是可以完成游戏的执行的，我们所需要做的就是重写其在游戏执行过程中的一些方法，就可以完成自己游戏的开发。

下篇介绍Game1类中，这些方法及两个字段的作用。

游戏服务器的设计是一项颇有挑战性的工作，游戏服务器的发展也由以前的单服结构转变为多服机构，甚至出现了bigworld引擎的分布式解决方案，最近了解到Unreal的服务器解决方案atlas也是基于集群的方式。

负载均衡是一个很复杂的课题，这里暂不谈bigworld和atlas的这类服务器的设计，更多的是基于功能和场景划分服务器结构。

首先说一下思路，服务器划分基于以下原则：
1：分离游戏中占用系统资源（cpu，内存，IO等）较多的功能，独立成服务器
2：在同一服务器架构下的不同游戏，应尽可能的复用某些服务器（进程级别的复用）
3：以多线程并发的编程方式适应多核处理器。
4：宁可在服务器之间多复制数据，也要保持清晰的数据流向
5：主要按照场景划分进程，若需按功能划分，必须保持整个逻辑足够的简单，并满足以上1，2点

服务器结构图：

各个服务器的简要说明：

Gateway：应用网关，主要用于保持和client的连接，该服务器需要2种IO，对client采用高并发连接，低吞吐量的网络模型，如IOCP等，对服务器采用高吞吐量连接，如阻塞或异步IO。

网关主要有以下用途：
1：分担了网络IO资源
2：同时，也分担了网络消息包的加解密，压缩解压等cpu密集的操作。
3：隔离了client和内部服务器组，对client来说，它只需要知道网关的相关信息即可（ip和port）。
4：client由于一直和网关保持常连接，所以切换场景服务器等操作对client来说是透明的。
5：维护玩家登录状态

World Server 是一个控制中心，它负责把各种计算资源分布到各个服务器
它具有以下职责：
1：管理和维护多个Scene Server
2：管理和维护多个功能服务器，主要是同步数据到功能服务器
3：复杂转发其他服务器和Gateway之间的数据
4：实现其他需要跨场景的功能，如组队，聊天，帮派等

Phys Server 主要用于玩家移动，碰撞等检测
所有玩家的移动类操作都在该服务器上做检查，所以该服务器本身具备所有地图的地形等相关信息。具体检查过程是这样的：首先，Worldserver收到一个移动信息，WorldServer收到后向Phys Server请求检查，Phys Server检查成功后再返回给world Server，然后world server传递给相应的Scene Server.

Scene Server 场景服务器，按场景划分，每个服务器负责的场景应该是可以配置的。理想情况下是可以动态调节的。

ItemMgr Server 物品管理服务器，负责所有物品的生产过程。在该服务器上存储一个物品掉落数据库，服务器初始化的时候载入到内存。任何需要产生物品的服务器均与该服务器直接通信

AIServer 又一个功能服务器，负责管理所有NPC的AI。AI服务器通常有2个输入，一个是Scene Server发送过来的玩家相关操作信息，另一个时钟Timer驱动，在这个设计中，对其他服务器来说，AIServer就是一个拥有很多个NPC的客户端。AIserver需要同步所有与AI相关的数据，包括很多玩家数据。由于AIServer的Timer驱动特性，可在很大程度上使用TBB程序库来发挥多核的性能。

工程总共有三个类，SpaceBlasterActivity、ArcadeGame和SpaceBlasterGame。第一个类是Android的Activity类；第二类继承了LinearLayout类，主要实现了onLayout函数（当View要为所有子对象分配大小和位置时，调用此方法），也就是说可以将游戏的初始化方法和产生周期性线程（模拟周期性的帧）放在这里。第三个SpaceBlasterGame类继承了ArcadeGame类，游戏的所有逻辑都在这里实现，例如各个Sprite之间的碰撞和显示。类的结构图如下：

接下来上一下这三个类之间的UML图吧，已经画了，不用怪可惜（⊙﹏⊙b汗）：

这里不会说明所有的函数，我的代码在这里，《Pro Android Games》一书网上也有它的示例的代码。这里主要说明几点个人觉得比较重要的地方：

1、 构造方法必须有两个参数的那个，否则main.xml无法解析；

2、 Bullets和Meteors都是用数组记录信息的，一开始用ArrayList容器，游戏玩玩就会崩溃；

然后就是细节问题，这个游戏很简单，没有算法，不够建议还是自己去实现一下，在这个过程中会发现很多细节点的！

游戏音效就是我们在玩游戏时出现的音乐，这个也是每个游戏必备的一部分，但有是你做游戏的背景音乐有间断的感觉的话，我们可以用getCurrentPosition()这个方法来判断一下声音播放的偏移。其实这个也是非常简单的。只要我们在代码当中设置好(初始化声音)和(加载音效资源)就可以了，别的就和音乐播放器的代码差不多，像开始，停止。不多说了，我们还是先来看看代码当中是怎么实现音效的吧：
//音效的音量
　　intstreamVolume;
　　
　　//定义SoundPool对象
　　privateSoundPoolsoundPool;
　　
　　//定义HASH表
　　privateHashMapsoundPoolMap;
　　
　　/***************************************************************
　　*Function:initSounds();
　　*Parameters:null
　　*Returns:None.
　　*Description:初始化声音系统
　　*Notes:none.
　　***************************************************************/
　　publicvoidinitSounds(){
　　//初始化soundPool对象,第一个参数是允许有多少个声音流同时播放,第2个参数是声音类型,第三个参数是声音的品质
　　soundPool=newSoundPool(100,AudioManager.STREAM_MUSIC,100);
　　
　　//初始化HASH表
　　soundPoolMap=newHashMap();
　　
　　//获得声音设备和设备音量
　　AudioManagermgr=(AudioManager)context.getSystemService(Context.AUDIO_SERVICE);
　　streamVolume=mgr.getStreamVolume(AudioManager.STREAM_MUSIC);
　　}
　　
　　/***************************************************************
　　*Function:loadSfx();
　　*Parameters:null
　　*Returns:None.
　　*Description:加载音效资源
　　*Notes:none.
　　***************************************************************/
　　publicvoidloadSfx(intraw,intID){
　　//把资源中的音效加载到指定的ID(播放的时候就对应到这个ID播放就行了)
　　soundPoolMap.put(ID,soundPool.load(context,raw,ID));
　　}
　　
　　/***************************************************************
　　*Function:play();
　　*Parameters:sound:要播放的音效的ID,loop:循环次数
　　*Returns:None.
　　*Description:播放声音
　　*Notes:none.
　　***************************************************************/
　　publicvoidplay(intsound,intuLoop){
　　soundPool.play(soundPoolMap.get(sound),streamVolume,streamVolume,1,uLoop,1f);
　　}