作者：Svyatoslav Cherkasov

在这篇文章中，我要分享的是用Flash和Adobe Air针对iPhone平台开发游戏的经验。

简单地说，Air是个支持Flash应用在不同设备（包括iOS、Android、黑莓甚至电视）上运行的平台，在开始以Air为平台开发之前，我对此丝毫不了解。但这不是问题，因为95%的Air应用与普通的Flash应用并无明显区别。

所以，我和团队决定用此为iPhone制作游戏。我们的目标不是赚钱，而是通过实验来证实是否能够在Air上针对iOS制作出流畅的动态游戏。

游戏想法

我们想要尽快做成游戏，所以我们希望游戏玩法满足以下条件：

1、简单，这样我们才能快速地制作出游戏。

2、无需过多的动画和移动物体，因为我们不确定它能否在iOS上流畅运行。

3、采用普通的游戏玩法。

4、无需制作上百个不同的解谜关卡，因为我们不想在这个游戏上花过多的时间。

而且，我们也不想自行发明游戏玩法，也没有足够的时间这么做，所以我们决定克隆其他的游戏。

经过数天的搜索后，我们找到了克隆的目标——《Axe in Face》。

游戏开发

于是，我们开始了游戏开发工作。

在Air上开发游戏很简单。与普通的Flash游戏开发类似，只有些许不同之处（游戏邦注：多数是些设备独有的功能，比如多点触摸和加速计等）。

接下来，让我们先搁置Flash开发，专注于iOS系统特有的问题。

运行表现

当你针对手机开发应用时，运行表现是最重要的层面。我们希望自己游戏能够表现得像款iOS原生应用。游戏能够像其他iPhone游戏那样流畅地呈现效果。所以，我们尝试了不同的技术，尽量实现这个目标。

但是，需要指出的是，并非所有愿望都能实现。

所以，我们在制作精灵时尝试了多种不同的图像引擎。

1、Flash引擎，位图帧。

首先，当然是不能使用矢量图！矢量图运行非常缓慢，你需要的是只用位图。

我们尝试的首个做法是，简单的Flash电影剪辑，以位图呈现画面帧。

令人惊异的是，它的表现并不糟糕，但还是有一些提升空间。

2、位图传输

接下来，我们尝试的是位图传输。这是开发电脑Flash游戏的常用方法。其想法是，制作1个位图数据，将所有的精灵挨个复制到其中。随后，将其呈现在屏幕上。

这种方法在电脑Flash游戏上很有效，但是在iOS上却失败了。如果采用这种方法，内存运转速度似乎很慢。

3、高级Flash引擎。

经过研究后，我知道了如何提升图像表现以及标准Flash引擎无法良好运转的原因。如果你想要快速播放精灵动画，那么你需要将所有的图像存储在内存中。

当使用标准Flash引擎时，每个新的帧都需要运用内存。在每帧中，Flash引擎都需要处理老图像并为新帧创建新图像。

但是，所有的图像都可以重复使用，所以在使用后无需将其处理。

首先，我们将所有图像数据加载到位图数据矢量中，每帧都有自己的位图数据。然后，我们以每帧为基础制作位图对象，将所有对象都放置在精灵MovieClip中。这样，精灵在呈现单帧的同时也含有所有帧。接下来，我们需要做的是为它们转换可视资产，每次只呈现单个帧。

我们的想法是，所有的图像都能够立即可用，用过的帧在呈现后不会被删除。这样，就无需创建新图像和处理用过的图像。

这种方法确实有效，但是还存在改进的空间。

下个改善的阶段是，我们制作单个位图对象，然后为其加上位图数据，比如main_bmp.bitmapData = bd_frame[i]。

这种做法也很有效，在iPhone 4上可以实现以40帧每秒的速度呈现20到30个动画精灵。

这足以满足我们的需求。

以下是某些运行表现的设计建议：

1、尽量少用动态创建对象。

2、尽量少用鼠标互动对象。使用mouseEnabled和mouseChildren来关闭互动选项。

3、避免移动大型对象。

4、针对所有无动画和无旋转的物体使用cacheAsBitmap。

5、针对其他无动画但需要旋转或改变的物体使用cacheAsBitmapMatrix。

6、不要制作大量ENTER_FRAME监听器。只需制作1个即可。

7、在ENTER_FRAME监听器中计算时间。如果你正以每帧X像素的速度移动一个对象，从上次监听器调用的时间开始计算。

平台特有的问题

Retina vs 低分辨率

应用在屏幕分辨率不同的情况下会有何表现呢？很简单，图像会缩放，当然你需要修改场景缩放代码。

对于同时兼顾iPhone 3/3GS和4/4S的开发者来说，这是件好事。你只需要制作Retina应用，在iPhone 3上运行时应用会自动缩放。

当然，你也可以根据屏幕来呈现不同的图像，但是这看起来似乎很麻烦，所以我们以默认的方式来处理这个问题。

iPhone vs iPad

这个问题与Retina问题相同，也关系到应用的缩放。但是在这种情况中，缩放因素并不是那么出众，所以你需要为iPad游戏制作某些自定义代码和自定义图像。

这正是我们将应用设计为只支持iPhone的原因。或许，以后我们会针对iPad制作游戏的HD版本。

CPU vs GPU

对于图像而言，你可以使用CPU或GPU来编译Air应用。如果使用我们的图像引擎，这两者之间的差别并不大（游戏邦注：差别在10%左右）。

但是我们选择了CPU，因为在GPU下编译会面临某些限制条件。比如，无法呈现效果。这意味着，所有的文字轮廓和阴影都无法呈现。解决方案是，制作空白的位图数据对象，在那里绘制电影剪辑，然后将其放入应用中。因为当你使用“绘制”方法时，它使用的是软件引擎并支持所有的效果呈现。

但是这似乎也相当棘手，且毫无好处可言，所以我们选择使用CPU模式。

其他问题

Adobe Air是国际通用平台。这意味着，如果你需要接入GameCenter等某些iOS设备特有的功能，你需要安装额外的“本地扩展”。这个构建过程令人烦扰，但是一旦弄清来龙去脉，所有的事情就都变得非常简单。

而且，新版Air忽略了手机上的静音开关。所以，我们需要使用额外的本地扩展来实现。

我们整个开发过程都是在PC上完成的。但是到最后阶段，我们发现需要一台Mac电脑。原因在于，将应用上传至App Store只能使用Application Loader软件，而该软件只支持Mac OS 10.6.8及更新版本。

总结

能不能使用Flash Air来编写应用呢？我觉得答案是肯定的。

当然，在表现上会面临许多问题和瓶颈。但是，Adobe正在解决这些问题，承诺在不久将来会获得良好的改善。对于动态游戏而言，现在要制作出能够在带有Retina功能的iPhone 4上完全流畅运行的游戏并不容易。但如果以iPad 2和iPhone 4S为平台，应用运行表现更好。

所以，我们希望Adobe能够将Air打造成真正适合开发游戏的平台。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Developing a game on Adobe Air for iOS

Svyatoslav Cherkasov

In this article I want to share my experience in developing a dynamic game for iPhone using Flash and Adobe Air platform. But first of all, please sorry me for my English. That’s not my native language.

So, what is Air? Saying in a pair of words it is a platform that makes available to run flash applications on different devices – iOS, Android, Blackberry, even TVs. Beginning developing in Air I didn’t know anything about it. But that’s not a problem because in 95% Air application is similar to an ordinary Flash application.

So, my team and I decided to take our chance in making a game for iPhone. There was no objective to earn money. The first and main objective was to make an experiment and to find out if it is possible to make smooth dynamic games on Air for iOS.

Game idea.

We wanted to make our game as soon as possible, so we wanted some gameplay that:

Would be simple, so we can make our game fast.

Wouldn’t need many animated and moving objects because we was not sure it can be done smooth on iOS.

Would use not common and cloned for 10 times gameplay.

Wouldn’t need to make 100 different puzzle levels because we didn’t want to spend our time on that.

Also, we didn’t want to invent our own gameplay (and also didn’t have time for that), so we decided to clone some game.

After a few days of search we found our victim – game “Axe in Face”.

Let the develop begin!

So, we started to work…

Developing on Air was easy. It is a regular Flash development with some minor modifications (in most cases in some device-specific functionality such as multi-touch, accelerometer, etc.)

So, let’s put flash develop apart and focus on iOS-specific troubles and hints.

Performance.

That’s the main theme. All is about the performance when you’re developing something for a mobile phone. We wanted our game to look like native ones. To make smooth effects similar to other iPhone games. So, we’ve tried different technics and made our best to achieve it.

But, I need to say, that was not possible for everything.

So, we tried different graphics engines to put our sprites…

1. Flash engine, bitmap frames.

First of all, of course, no vector! Vector is very slow. You need to work with bitmaps only.

The first thing we tried was a simple flash movieclip with bitmap in frames.

Surprisingly it worked not so bad, but we wanted more…

2. Bitmap blitting.

Next thing we tried was bitmap blitting. This is a common method for desktop flash games. The idea is to make one bitmapData and to copy all your sprites into it, one by one. And after all show it on the screen.

This method works great on desktops but failed on iOS. It seems that memory operations are quite slow for now.

3. Advanced flash engine.

After some research I found out how to improve graphics performance and why standard flash engine didn’t work well. The idea is that if you want to animate your sprites fast, you need to store all graphics in memory.

When using standard flash engine it takes every new frame to memory every time it needs. So, every frame flash engine disposes old graphics and creates new, for new frame.

But all graphics is re-usable, so there’s no need to dispose it after usage.

First what we did is we loaded all our graphics data in a vector of bitmapData – each frame in its own bitmapData. Then we made Bitmap objects from each of frames and put all of them in our sprite MovieClip. So, sprite contained all its frames in the same time in one single frame. The next we needed to do is to switch visible property for them and to show only one frame a time.

The idea was that all graphics was available at once, and used frames were not killed after showing. So, no creating new graphics and no disposing used.

That worked well but could be improved.

The next improvement stage was that we made a single Bitmap object and just swapped bitmapData field for it. Something like: main_bmp.bitmapData = bd_frame[i].

That worked fine. It made possible to show 20-30 animated sprites on iPhone 4 (retina) at 40 fps.

That was enough for our needs.

Some performance hints:

Use as less dynamically-created objects as possible.

Use as less mouse-interacted objects as possible. Use mouseEnabled and mouseChildren to turn interaction off.

Avoid moving large objects. Especially with alpha.

Use cacheAsBitmap for everything is not animated and not rotated.

Use cacheAsBitmapMatrix for everything else that is not animated, but need to be rotated or changed alpha.

Don’t make plenty of ENTER_FRAME listeners. Make just one.

Always count time in your ENTER_FRAME listener. So, if you’re moving an object by X pixels every frame, make a calculations on the elapsed time from the last listener call.

Platform-specific troubles.

Retina vs lo-res.

How our application behave on different screen resolutions? It’s simple. It scales (but you make to change scene scale mode, of course).

That’s good for developing for iPhone 3/3GS and 4/4S. You just make a retina application and it automatically scales down on iPhone 3.

Of course, you can “read” the scene scale and show different graphics depending on what scale is it, but that seems to be quite tricky, so we left everything by default.

iPhone vs iPad.

Here is the same thing as with retina. Application scales. But in this case the scale factor will not be nice, so you need to make some custom code and custom graphics for iPad games.

That’s why we left our application iPhone-only. Maybe, we’ll make HD version for iPads some time later.

CPU vs GPU.

You can compile your Air application to use CPU or GPU for graphics. Using our graphic engine there was not great difference (it was about 10%).

But we’ve chosen CPU because when you compile under GPU you get some limitations. For example, effects don’t work. That mean that all text outlines and shadows wouldn’t be shown. The solution was to make an empty bitmap data object, draw a movie clip there and then put it on the stage. That works because when you use “draw” method, it uses software engine anyway and support of all effects presents.

But that also seemed very tricky and gave no advantage, so we left us at CPU mode.

Some other problems.

Adobe Air is a universal platform. That means that if you need to access some device-specific functionality like GameCenter, you need to install additional “native extensions”. That needs some tweaking building process, but after you find out what is what – everything is quite easy.

Also, the new versions of Air ignore the mute switch on the phone. So, we needed to use an extra native extension for that.

Also, we’ve developed all our game on PC. But on the last step we found out that we need a Mac anyway. The reason is that uploading an application to app store is only possible with an Application Loader software which is only available for Mac OS 10.6.8 and later.

The conclusion.

To write on Flash Air or not to write? I think “yes”. To write.

Of course, there are some troubles and bottlenecks in performance. But Adobe is working on it and promises lots of improvements in near future. Speaking of dynamic games – that’s hard to make one that runs completely smooth on iPhone 4 with retina for now. But iPad 2 and iPhone 4S are much better.

So, we’re looking forward on Adobe and hope that Air will be a real platform for game development.(Source: Gamasutra)