实战Flash游戏开发第二版增添章-第15章（未编辑）.docVIP

第15章 Marble Runner：我们的第一款手机游戏 迄今为止，我所讲过的范例几乎都是在教你如何创建在台式机浏览器中运行的Flash游戏。而就在本书第一版发布后不久，Adobe即宣布Flash CS5将可以导出标准的iOS程序，并且以后的Android程序也能用上即将发布的AIR（Adobe开发的专用于桌面部署的运行时环境）了。尽管从声明到发布的这段时间内，Flash的移动设备应用历程富有戏剧性，但Adobe总算最终实现了那些计划。通过Flash CS5（以及CS5.5），你现在可以为iOS设备（iPhone、iPod Touch与iPad）及Android设备部署移动程序。在接下来的两章中，我将介绍如何为这两种移动平台开发游戏，其中包括最佳实践、资源管理以及部署方法。如果想大致了解一下这些平台的SDK以及如何建立必需的开发者账号，你可以先看看本书网站上的参考性章节“Introduction to Mobile Development”。 本章内容一分为二。首先将创建一个简单的范例程序，并介绍一些与iOS移动开发相关的最佳实践，随后将开发一款用到了加速器技术的iPhone游戏，这可是本书的第一款手机游戏。下一章将介绍Android开发，你会看到它与iOS开发的差异所在。相比之下，它更为自由。 15.1 第一部分：开发iOS游戏的最佳实践 移动开发素来都不同于桌面开发，恐怕未来也即如此。而且，相对较小的移动设备屏幕也会使得其计算资源只会更为有限。对于iPhone和iPod Touch来说，它们的处理能力应该只有一般台式电脑的1/10左右。（随笔：与assume、suppose相比，expect to的“期望”以及那种表“假设”的程度要更强烈一些，几乎等同于“必然会发生”那种意思。所以这里的you can expect to就可以翻译成“你可以认为”。）另外，容量有限也使得内存的利用必须谨慎。但切莫惊慌，本章所授方法完全可以使开发者在这些局限中游刃有余，而且当他们重新开发桌面应用时，其中一些方法自会使其编程更具规序性。（对于disciplined的用法，我提议业界统译为“规序式”。——译者注）我们先来介绍一些在开发iOS游戏时你应该谨慎或完全避免使用的Flash特性，以及该平台根本不存在的API。注意我这里说的是游戏，有些特性可能对于性能表现要求不高的生产力应用还是适用的，但本书不会介绍那些内容。另外要记住的是，这些规则很少是固定不变的，它们只是决策游戏设计时所应考虑并权衡的一些因素而已。在枯燥的功能介绍之后，我们还会讲到编码时应遵循的一些原则与技巧，它们将有助于使游戏在iOS设备上获得最佳性能。虽然Adobe出色的工作使得由Flash CS5开发的iOS程序能利用Flash Player的几乎全部特性，但还是有些特性原封未动，特别是那些游戏开发相关特性。这主要是因为Flash的许多API都十分消耗内存及CPU处理能力，至少就移动标准而言。那么我们应避免什么呢？本节即将揭晓。 15.1.1 滤镜（包括PixelBender所创建的滤镜） 自从Flash 8引入了多种实时滤镜效果后，设计师和开发者就可不必通过外部软件（如Photoshop）来仿造或预制诸如模糊、发光及投影这样的图像效果了，这就极大地节省了时间。而且较为少见的是，有些特性（比如像置换图与卷积滤镜）还能实现完全由代码控制的变形效果。尽管滤镜是Flash中的一个很优秀且极易实现的特性，但它们同时也非常消耗系统资源。在桌面程序中，特别是当电脑显卡较为高端时，这种消耗与所有其他运行进程的庞大开支相比简直是小菜一碟。但在iOS设备上则就是另一回事了。处理这些滤镜并保持它们实时更新会使渲染变得很吃力，只要有几个滤镜同时运行，程序性能很快就会被拖垮。Adobe甚至建议不要在任何高性能要求的应用程序上使用滤镜。 然而若是经过悉心安排，有经验的开发者还是可以用上一两个滤镜效果的。最重要的是你要考虑何时应用滤镜。有一种滤镜使用方法是在Bitmap对象上使用滤镜，或者更具体地而言就是在其中的BitmapData对象上使用。如果游戏对象用的是Bitmap对象，而你又需要让所用滤镜能一直保持到该对象被移除之后（如投影滤镜），那么你可以在BitmapData对象上调用applyFilter方法，这样就可以在图片自身上渲染出该滤镜效果（并且也会消除因反复渲染效果而引起的资源重复消耗）。这可能会节省所用图片的尺寸，并且会使运行时有一定的灵活性，以便能够先于应用滤镜前更改其参数值。再次着重强调的是，这种进程在iOS设备上耗费资源良多，所以如果打算应用滤镜的话，你就应在关卡或游戏会话开始时使用这种方法，这样就会避免游戏出现明显延迟。 另有消息称，为iOS设备导出的Flash程序将