[转] The Light Racer 3D Development Journal
Posted on 2012-08-23 17:20 Chrisfang6 阅读(278) 评论(0) 编辑 收藏 举报原文：The Light Racer 3D Development Journal
As of the start of this journal in April, 2009, my first Android game, Light Racer, had over 250,000 downloads and was on version 1.0.1. That game was developed in about 3 weeks time in my spare time and was released right when the G1 was made available. I had over a quarter of a million downloads of that first game, so why did I feel like spending months rewriting it and developing a 3D version of it? Well, I wasn't totally happy with the old version. It had really bad AI. I wrote that quickly just so I could have a computer to play against when testing but never implemented a better version. It was a little slow and choppy on some phones. It lacked depth and the way it was designed makes it hard to continue to add new parts to the game. It didn't have multiplayer support. It didn't look very nice. Basically, it wasn't a game that I could personally be proud of developing and I felt that there was so much potential for a great multiplayer 3D game, but I wanted to bring the 2D game up-to-date in the process, so I ended up doing both. Because of the months of development effort documented in this journal, Light Racer v2 and Light Racer 3D are both complete and are worlds better and more advanced than the first title. In the following pages, I give away many tricks and code samples of how to do almost you need to develop a good Android game.
This journal was written from day one of development. The course of development took about 5 months in total. All of the entries from this point on are written from the perspective of the day that the development was happening. If you want to learn how to develop games, I recommend reading every article in the journal. Many have code examples and there are lots of lessons to learn from them. I started the project not knowing as much about game development as I know now. I hope that this journal helps you on your way and that you are able to learn something useful from it. If you are a Light Racer fan and not a developer, I hope that you have fun seeing what happened to make the game completely come together.
Today Light Racer 3D is on the Android market and is one of the most advanced games available on this platform. This journal documents how many of the game's features were developed.
And here it begins... Day 0 (pre-planning)
The next article will contain more on this, but for now I'll say that the reason I care about Light Racer with regards to LR3D is because I plan to use much of the code from that game in the next. Through clever design, Light Racer 3D will mostly be the same code as Light Racer but with an OpenGL front-end and if I do things right, I'll have a game engine that will make it really fast for me to develop brand new games in the future.
Android is none too easy to develop OpenGL apps for. The API is just OpenGL ES, but the performance isn't very good and there aren't any tools for Maya or 3DS import/export.
What I intend to have is an identical feature set between LightRacer and LightRacer3D. Some people will prefer the old-school 2D LR, but I believe most will prefer the much flashier and first-person-perspective LR3D.
Here are my current problems:
1) The game is poorly designed. One activity and one 1,400 line class handles nearly everything.
2) There is no networking code, so no multiplayer.
3) The AI is too easy.
4) The game lacks depth.
5) The game looks cheap.
Here's what I plan to do about that:
1) Redesign everything.
First I will start by refactoring all of the existing code. I believe that by simply moving much of the specific game component code from the main class, I will be able to achieve an architecture that will let me plug in new components, such as input from the network or a new type of AI character. The individual blocks of code are good, but it's really an organizational problem right now. Some things will need to be totally redone, and MUCH responsibility will need to be delegated to GameObject classes. More on that later.
2) Write networked multiplayer code.
This can impact the app in several ways. For the most part, I can assume that if you're playing a TCP/IP game, that it's local and WiFi. This means that there won't be any problems with network congestion, latency or packet loss. This does not take into account how people potentially could be connecting their devices in the future. I shouldn't assume that it will always be WiFi. If I wanted to be really safe, I would need to account for packet loss, which means that the physics would need to use interpolation, which they currently don't. Beyond that, the design needs to allow for a network player to be assigned as the entity controlling a player, which it currently does not support.
3) Develop easy, medium and hard Artificial Intelligence.
The current AI can stay as "Easy." For medium and hard, I intent to test with an A* algorithm and then an evaluation function that will determine the AIs path by predicting what you, the player will do and plan on that. Curbing CPU usage will be difficult with that because that approach is a bit like chess AI. If it works out well, it will be certainly be hard, if not unbeatable. Medium AI will just be the A* algorithm with a simple heuristic and no prediction. There is yet another design problem with the AI, though. Currently the main class of the game simply has "updateAI" which runs for all players that aren't the one human. It should be fairly simple to do, but a new design will be needed which will allow for assigning a specific implementation of AI to a player.
4) Add more interesting game elements
One of the most common suggestions I get for LR is that it could use a little more depth. What exactly does that mean? How do I make it more fun? I don't want to pollute the game with objects that will take away from it's core gameplay, but I agree that it could use something that makes it a bit more riveting. Perhaps a non-player character (NPC) that flies around on occasion, smashing the walls down? Maybe a beam down the center which only allows for occasional pass? Perhaps a boost feature which allows a player to speed up? All of these things could be fun. I am considering all of them and once I get the new design down, I'll be able to play with a few of these things to see which are the most fun and which ones make you want to play the game more.
5) Tweak the graphics, add more animation capability and hire a professional designer
When I wrote the game, I never intended for it to be anything more than a test application. All I wanted to do was learn the Android API. Now I want to have a really great game, which will be Light Racer 3D. I can do certain tweaks to the 2D version that will make it look a little better but ultimately I'm going to need the help of a professional graphic designer. Thank you but no portfolios, please. I already have someone that I trust and have a good relationship with. The other thing that is limited in the current design is the ability to add more animations without using up too many more CPU cycles. This will be covered in the Game Architecture article.
如果你有兴趣为Android平台开发游戏，有很多你需要了解的东西。我是Light Racer，Light Racer 3D以及Wixel的开发者，这些游戏目前在Android Market上有售。我以前也开发过游戏，但Light Racer是我的第一个Android应用程序，我从中学到了很多Android游戏开发知识，也愿意与诸位分享。我甚至写了一本在线的书详细介绍了Light Racer3D的开发，内容全是教你怎样做以及有用的代码片段。如果你有过游戏开发经验，那么转移到移动平台上来将不是特别困难。你主要只需学习其架构以及API就行了。如果你是一名游戏开发新手，我总结了一张列表，上面有你必需知道的东西，供你起步用。这些知识适用于很多类型的游戏，包括动作类、策略类、模拟类和益智类。 Android是一个基于Java的环境。这对初学者来说是个好消息，因为相对于C++，Java被广泛认为是一门更容易上手的语言，它是移动开发的规范。Google也做了一件出色的工作，它将API文档化并提供示例代码供使用。其中有个叫做API Demos的示例几乎展示了所有API的功能。如果你熟悉Java并且用过Eclipse，要让你的第一个应用跑起来那是相当简单。如果你以前从没写过代码，在你前进路上还要学习很多，但别气馁。
获取SDK
新手上路的第一步便是获取Android SDK（软件开发工具包）。SDK里有一个核心类库，一个模拟器，一些工具和示例代码。我强烈建议使用Eclipse和Android Eclipse插件。如果你玩Android的话，Eclipse IDE对Java开发者来说很好用。如果这是你第一次开发Java项目，你可能会需要下载全套JDK，它里面包括签名和部署你的应用程序的一些工具。
学习应用程序架构
别急着一头扎进开发的海洋里，理解Android应用程序架构是很重要的。如果你不学一下，你设计出来的游戏在线下将很难调试。你将需要理解Applications、Activities、Intents以及它们怎样相互联系。Google提供了很多有用的架构信息。真正重要的是要理解为什么你的游戏需要多于一个的Activity，以及什么才是设计一个有良好用户体验的游戏。要理解这些，首先要了解什么是Activity生命周期。
学习Activity生命周期
Activity生命周期由Android操作系统来管理。你的activity创建、恢复、暂停、销毁都受操作系统的支配。正确处理这些事件是很重要的，这样应用程序才能表现良好，做用户认为正确的事。在你设计你的游戏之前了解所有这些是如何工作的是件好事，因为以后你可以为自己节省调试时间和昂贵的重新设计时间。对大多数应用来说，默认的设置将工作正常，但对于游戏，你可能需要考虑将SingleInstance标志打开。当设置为默认时，Android在它认为合适时会创建activity的新实例。对于游戏来说，你可能只需要一个游戏activity的实例。这对于你要怎样管理事务的状态有些影响，但对于我来说，这解决了一些资源管理的问题，应予以考虑。
主循环
根据你写的游戏的类型，你可能需要也可能不需要一个主循环。如果你的游戏不依赖于时间或者它仅仅对用户所做的加以回应，并且不做任何视觉上的改变，永远等待着用户的输入，那么你就不需要主循环。如果你写的是动作类游戏或者带有动画、定时器或任何自动操作的游戏，你应该认真考虑下使用主循环。
游戏的主循环以一个特定的顺序通常尽可能多的在每秒钟内“滴答”提醒子系统运行。你的主循环需要在它自己的线程里运行，原因是Android有一个主用户界面线程，如果你不运行自己的线程，用户界面线程将会被你的游戏所阻塞，这会导致Android操作系统无法正常的更新任务。执行的顺序通常如下：状态，输入，人工智能，物理，动画，声音，录像。
更新状态意思是管理状态转换，例如游戏的结束、人物的选择或下一个级别。很多时候你需要在某个状态上等上几秒钟，而状态管理应该处理这种延迟，并且在时间过了之后设置成下一个状态。
输入是指用户按下的任何键、对于滚动条的移动或者用户的触摸。在处理物理之前处理这些是很重要的，因为很多时候输入会影响到物理层，因而首先处理输入将会使游戏的反应更加良好。在Android里，输入事件从主用户界面线程而来，因此你必须写代码将输入放入缓冲区，这样你的主循环可以在需要的时刻就从缓冲区里取到它。这并非难事。首先为下一个用户输入定义一个域，然后将onKeyPressed或onTouchEvent函数设为接到一个用户动作就放到那个域里，有这两步就够了。如果对于给定游戏的状态，这是一个合法的输入操作，那么所有输入需要在那一刻做的更新操作都已经定下来了，剩下来就让物理去关心怎样响应输入吧。
人工智能所做的类似于用户在决定下一个要“按”哪个按钮。学习怎样写人工智能程序超出了这篇文章的范围，但大体的意思是人工智能会按照用户的意图来按按钮。这些也有待物理去处理和响应吧。
物理可能是也可能不是真正的物理。对于动作类游戏来说，关键点是要考虑到上一次更新的时间、正在更新的当前时间、用户输入以及人工智能，并且决定它们朝着什么方向发展和是否会发生冲突。对于一个你可视化地抓取一些部件并滑动它们的游戏来说，物理就是这个游戏中滑动部件或者使之放入合适的位置的部分。对于一个小游戏来说，物理即使这个游戏中决定答案是错还是对的部分。你可能将其命名为其他东西，但每个游戏都有一个作为游戏引擎的红肉部分（译者注：可能是主体部分的意思），在这篇文章里，我把这部分称为物理。
动画并非像在游戏里放入会动的gif图片那样简单。你需要使得游戏能在恰当的时间画出每一帧。这并没有听起来那么困难。保留一些像isDancing、danceFrame和lastDanceFrameTime那样的状态域，那样动画更新便能决定是否可以切换到下一帧去了。动画更新真正做的事就那么多。真正来显示动画的变化是由录像更新来处理的。
声音更新要处理触发声音、停止声音、音量变化以及音调变化。正常情况下当写游戏的时候，声音更新会产生一些传往声音缓冲区的字节流，但是Android能够管理自己的声音，因而你的选择将是使用SoundPool或者MediaPlayer。它们都需要小心处理以免出错，但你要知道，因为一些底层实现细节，小型、低比特率的声音文件将带来最佳的性能和稳定性。
录像更新要考虑游戏的状态、角色的位置、分数、状态等等，并将一切画到屏幕上。如果使用主循环，你可能需要使用SurfaceView，并做一个“推”绘制。对于其他视图，视图本身能够调用绘制操作，主循环不必处理。SurfaceView每秒产生的帧数最多，最适合于一些有动画或屏幕上有运动部件的游戏。录像更新所要做的工作是获取游戏的状态，并及时地为这个状态绘制图像。其他的自动化操作最好由不同的更新任务来处理。
代码看起来是什么样的？这儿有个例子。
1: public void run() {
2: while (isRunning) {
3: while (isPaused && isRunning) {
4: sleep(100);
5: }
6: update();
7: }
8: }
9:
10: private void update() {
11: updateState();
12: updateInput();
13: updateAI();
14: updatePhysics();
15: updateAnimations();
16: updateSound();
17: updateVideo();
18: }
3D还是2D？
在开始写游戏之前，你要决定是做3D的还是2D的。2D游戏有一个低得多的学习曲线，一般更容易获得良好的性能。3D游戏需要更深入的数学技能，并且如果你不在意的话会有性能问题产生。如果你打算画比方框和圆圈更复杂的图形，还需要会使用3D Studio和Maya那样的建模工具。Android支持OpenGL用来3D编程，并且在OpenGL方面有很多很好的教程可供学习。
建立简单、高质量的方法
上手时，要确保你整个游戏不要就用一个庞大而冗长的方法。如果你遵循我上面描述的主循环模式，这将相当简单。每个你写的方法应当完成一个非常特定的任务，并且它就应该无差错地那样做。举例来说，如果你需要洗一副纸牌，你应该写一个“shuffleCards”的方法，并且该方法就应该只做这一件事。
这是一个适用于任何软件开发的编码实践，但对于游戏开发来说这尤为重要。在一个有状态的、实时的系统里，调试将变得非常困难。使你的方法尽量的小，一般的经验法则是每个方法有且仅有一个目的（译者注：完成且仅完成一个功能）。如果你要为一个场景用编程方式画一个背景，你可能需要一个叫做“drawBackground”的方法。诸如此类的任务能够很快完成，因而你可以按照搭积木的方法来开发你的游戏，而你能够继续添加你要的功能，并且不会使得这一切难以理解。
最重要的是效率！
性能是任何游戏的主要问题。我们的目标是使得游戏的反应越快越好，看起来越流畅越好。某些方法如Canvas.drawLine比较慢。并且要将屏幕大小的位图画到主画布上，每一帧都是代价昂贵的。如何权衡对于达到最佳性能很有必要。确保管理好你的资源，使用技巧来以最少量的CPU资源完成你的任务。如果性能不好的话，即使是最好的游戏玩起来也没劲。人们一般对于游戏卡或者响应慢几乎难以容忍。
提示和技巧
看一下SDK中的示例LunarLander。它使用SurfaceView，这对于一个每秒需要处理最多帧的游戏来说是合适的。如果你要做3D，示例中有GLView可以处理3D显示的很多初始化工作。对LightRacer来说，我不得不优化把所有东西都画出来这种方法，否则帧率将会大大地降低。我只在视图初始化的时候把背景画进一个位图里一次。路径放在它们自己的位图里，随着车手的前进而更新。这两个位图在每一帧里都被画进主画布中去，车手画在顶端，到最后会有一个爆炸。这种技术使得游戏运行在一个可以玩的程度。
如果适用的话，使得你的位图的大小精确等于你打算画到屏幕上的大小，这也是个好的实践。这么做了以后就需要缩放，可以节省CPU资源。
在游戏中始终一致的位图配置（如RGBA8888）。这将会通过减少不同格式之间转换的时间来节省图形库的CPU时间。
如果你决定开发3D游戏但没有3D方面的知识，你需要挑选一两本3D游戏编程方面的书并学习线性代数。你最少要理解点积、叉积、向量、单元向量、法线、矩阵和变换。这方面我遇到的最好的书是叫《3D游戏编程和计算机图形学数学》。
声音文件要小而且低比特率。需要加载的越少，加载速度越快，游戏所需内存越少。
声音使用OGG文件，图片使用PNG文件。
确保释放所有媒体播放器，当Activity销毁时空出所有的资源。这能保证垃圾收集器清除了所有东西，也能保证在两次游戏开始之间没有内存泄露。
加入Android谷歌小组，寻求社区支持。这里有人可以在开发过程中给你帮助。
最重要的是，花时间测试再测试，确保每一小部分都如你所愿地工作。改善游戏是整个开发中最耗时最困难的部分。如果你匆匆将其推向市场，你很可能会使用户们失望，你会感到你的努力都白费了。你不可能使所有人都喜欢你写的东西，但你至少要尽量发布你最高质量的作品。
Google在这里有帮助你上手的绝佳的文档。
在Light Racer 3D开发日志可以找到可工作的示例代码和指导。
