作者：Charilaos Kalogirou

你是否想过将iOS游戏移植到黑莓的Playbook上？以下我将分享我对于这种移植的看法。

基本原则

很多人和我一样都认为Playbook与黑莓手机所使用的技术是密切相关的。而正是这种误解导致我们很难将其当成一个可行的移植对象。

但是事实是，Playbook所面对的是一个全新的平台，即黑莓基于QNX操作系统所创造的平台（并且这种平台同样也能够应用于BB10手机上）。

blackberry-playbook（from uncrate）

明确了这些内容我们便拥有了一个较为开阔的移植前景，但是我同样也担心黑莓与谷歌一样，规定所有内容都必须基于Java系统，并只支持原生应用。

不过结果证明事实并不像我想的那样糟糕。黑莓不只允许开发者去编写原生应用，同时它的原生开发套件（NDK）也将作为开发者在这一平台上开发游戏的最佳助手。这不像Android，其NDK只包含了原生Android建造系统（支持最低限度的功能并要求大多数内容都必须基于Java系统）。

在Playbook平台上，开发者可以编写一个完整的原生应用，而无需考虑Java。并且其NDK也将提供给开发者他们所需要的C级API——从屏幕处理到输入再到应用内部购买等内容。

黑莓所提供的开发环境是基于Eclipse的QNX Momentics，而开发者却也能够在此轻松地使用任意命令行工具。

尽管我知道Eclipse的操作较为缓慢，但却仍选择了Momentics，因为这是原生C/C++开发（带有调制器，剖析工具等）的最佳设置，而我也希望看看它到底能够帮助我走多远（直至我开始遗漏命令行）。而真正让我惊讶的是，它却一直陪我走到了最后，即至始至终都未出现让我放弃它的问题。

你同样也能获得一个基于VMWare的模拟器去执行你的代码。对我来说这却不一定是件好事，因为我将不得不购买VMWare才能运行它。当然了，也有免费的VMWare Player版本，但是却只能用于Windows和Linux操作系统上。所以和我一样的Mac用户只能使用30天的VMWare试用版或购买完整版。

接下来让我们开始具体阐述游戏移植。

输入

黑莓QNX的输入操作非常直接，与iOS的操作方法非常接近，所以这不会是问题所在。

与系统上的其它事件一样，碰触事件也是基于bps_event_t结构，即只要触发bps_get_event()便可。这一事件属于“屏幕领域，”所以我们可以通过使用screen_get_event_property_*()函数集去查询相关数据。

int touch_state;

int id;

int position[2];

screen_get_event_property_iv(screen_event, SCREEN_PROPERTY_TYPE,

&touch_state);

screen_get_event_property_iv(screen_event,

SCREEN_PROPERTY_TOUCH_ID, &id);

screen_get_event_property_i(screen_event,

SCREEN_PROPERTY_SOURCE_POSITION, position);

上述内容是你需要获得的基本碰触信息。碰触状态可以是

SCREEN_EVENT_MTOUCH_TOUCH，SCREEN_EVENT_MTOUCH_MOVE或者

SCREEN_EVENT_MTOUCH_RELEASE。

你可以以此映射在iOS的碰触初始，移动和结束事件上。与iOS一样，这里也不存在取消事件。并且因为你可以自己选择事件，所以在此便不会遇到我在Android上所遇到的麻烦。

这里不存在可操纵的硬件按钮。

声音

与iOS一样，OpenAL也适用于Playbook上。如果你在OpenAL中已经拥有了声音代码，你便可以略过这一步骤。这个平台上甚至包含了ALUT（自适应查找表）。

openal（from musicalgeometry）

图像

正如你料想的那样，Playbook也支持OpenGL ES（不管是1.1版本还是2.0版本）。NDK中包含了一个OpenGL应用样本能够用于处理屏幕上的所有设置细节，并且因为API设计的简单化与有效性，我们总是很清楚自己到底需要做些什么。

opengl（from wordpress）

该设备所支持的是1024×600像素的屏幕分辨率（也就是16:9大小），也就是窄于iPhone和iPad。所以你就必须重新调整游戏的UI或添加黑条才能适应新的屏幕分辨率。

《爆米花可尼》所支持的是1.33至1.50相位的UI，而为了能够更好地呈现在Playbook上，我选择添加一些条框而将1.7相位降为1.50。而因为每个屏幕的像素都非常接近于iPhone 4和iPad 2，所以如果你拥有合适的作品，你便无需做出任何改变而直接用于Playbook上。但是如果你的游戏使用的是基于iPad 3分辨率的作品，你就需要按比例去压缩游戏的规格，否则你将不可能呈现出最佳效果。

资产

资产加载就如想象中的一样简单。不需要涉及zip文件，文件压缩不会受限于某种特定的扩展规则，或者也无需使用过度设计的资产管理（我说的就是Android）。

应用被划分为.bar文件（本质上也就是zip文件）。在安装过程中，.bar文件内容是经过萃取的，并且应用可以基于任何与POSIX兼容的方式而访问文件系统。

如果你想要加载附加了应用.bar文件（包括纹理，声音等）的文件，你将在如下代码中找到它们：

./app/native/

如果你想要为你的应用创造文件并保存数据，你需要在以下代码中执行：

./data/

看吧，多么简单。

排行榜/成就

OpenFeint（也就是现在Gree旗下平台）并不提供这些服务，Game Center也是（因为它只是苹果旗下的一个网站）。而黑莓则提供了自己的网站，即“Scoreloop”，能够支持排行榜，成就和挑战等功能。

结束语

对于我来说，这是我所面对的最容易移植的平台。很长一段时间以来，我都很喜欢那些带有完整的软件设计决策的平台。所以我真心佩服黑莓的优秀工程师们，感谢他们创造出所有游戏开发者所喜欢的，即能够支持开放性框架的POSIX兼容平台。

不管是面对哪一个平台，你都必须将自己执行过的所有文库整合在一起。就像在Playbook的系统中便包含了libpng，lipjpeg，freetype等软件库，并且你可以获得相关链接。这里并不存在编译问题，让你能够通过文库链接直接进入执行内容。

但是该平台在第三方支方面却不如其它平台。例如在iOS平台，我使用了大量的flurry.com服务，但是他们却未提供能够支持Playbook的原生服务。他们是通过Java系统而支持黑莓的设备，但是我现在却不想面对Java。

当你完成移植后，你在App World上发行游戏便无需支付任何费用了，这一点与OS和Android的要求不同。只要你完成了游戏移植，你便能够在此进行注册，获得自己的签名密钥而直接进入这一平台。但是与苹果一样，这个平台上也有自己的审核过程。

作为结束语，我想说的是整个移植工作真的是非常轻松。我们只需要花两三天的时间，并且可能也只有一天是真正需要“废寝忘食”。所以我真心希望所有独立开发者能够正视这个平台。

因为iOS和Android应用商店已经接近饱和状态，所以Playbook也许将作为提高更多游戏曝光率的新平台。当我在写这篇文章的时候，我们的《爆米花可尼》已经在App World上发行数天时间了，现在它仍然稳居“新品”版块列表。

如果你是一名独立游戏开发者，你便清楚这种曝光率到底有多重要！

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

Porting your iOS game to Blackberry Playbook (and future BB10 phones)

By Charilaos Kalogirou

Continuing after my latest post about porting existing iOS games written in C/C++ to the Android platform, here I am again writing about my latest porting endeavor that brings Pop Corny to the third platform!

Ever thought of porting your iOS game to the Blackberry Playbook? Well, here I will share some insight of what to expect.

The basics

If you are like me, you will probably think that the Playbook has something to do with the tech that used to run Blackberry’s phones. This misconception was so strong in me that I didn’t even consider a port to it.

The truth is, however, that the Playbook is based on the new platform that Blackberry is creating based on the QNX operating system, and will also be used on the BB10 phones.

Things started to look better on the porting front with this info, but there is always a fear that Blackberry could be Google and force everything to Java and only support native after a long time has passed. It turns out that things are much better than I expected.

Blackberry not only allows you to write native apps, but its Native Development Kit (NDK) is a complete solution for developing on the platform. Not like Android for example, where the NDK is just a crude exposure of the native Android’s build system that supports minimal functionality and requires Java calls for most stuff.

On Playbook, you can write a full native app and never look at Java again. The NDK will provide C level APIs for all that you are going to need. From screen handling and input, to in-app purchases.

Blackberry’s provided development environment is QNX Momentics, which is based on Eclipse, but also you can easily do everything with command line tools if you prefer

I chose to go with Momentics even though I find Eclipse slow and sluggish, because it is very nicely setup for native C/C++ development (with debuggers, profilers, etc) and I wanted to see how far it would get me until I started missing the command line. Surprisingly, it did all the way. I had no problem with it, which is a first for me and Eclipse.

You also get an emulator for trying out your code, which is based on VMWare. This didn’t strike me a good thing because you have to buy VMWare to run it. Sure, there is the VMWare Player version that is free, but you can use that only on Windows and Linux. Mac users, like me, will have to use the 30-day trial of VMWare Fusion, or buy it.

Next I will go through the major porting areas to keep this consistent with my corresponding article for Android.

Input

Handling input on Blackberry QNX is very straightforward and correspondent with the way iOS does it, so you shouldn’t encounter any problem.

Like every other event on the system, touch events are represented by the bps_event_t structure that you pull with bps_get_event(). The event belongs to the “screen domain,” and you query its data using the screen_get_event_property_*() set of functions.

int touch_state;

int id;

int position[2];

screen_get_event_property_iv(screen_event, SCREEN_PROPERTY_TYPE, &touch_state);

screen_get_event_property_iv(screen_event, SCREEN_PROPERTY_TOUCH_ID, &id);

screen_get_event_property_i(screen_event, SCREEN_PROPERTY_SOURCE_POSITION, position);

The above snippet is all you need to get the basic touch info. The touch_state can be one of SCREEN_EVENT_MTOUCH_TOUCH, SCREEN_EVENT_MTOUCH_MOVE and SCREEN_EVENT_MTOUCH_RELEASE.

You can map to the touches began, moved, ended events of iOS. There is no canceled event here like iOS. Also, since you poll for the event, you get it on the thread you like and you will not have any issues like I had on Android.

There are no hardware buttons to handle.

Sound

Like on iOS, OpenAL is also supported on Playbook. If you have sound coded in OpenAL (which you probably do),you will have nothing to do here. Even ALUT is included in with the platform in case you rely on it.

Graphics

As you might expect, Playbook supports OpenGL ES with no problems. Both 1.1 and 2.0 versions are supported. There is a sample OpenGL application included with the NDK that handles all the details of setting up your screen, and because of the simple yet effective way the API is designed, it’s self explanatory what needs to be done.

The device sports a 1024×600 pixels screen resolution, which is almost 16:9 and hence much narrower than what the iPhone and of course the iPad have. Depending on your game, you will have to either rearrange the UI to fit the resolution or add black bars.

For Pop Corny I support aspects from 1,33 to 1,50 with the UI adjusting automatically for this. So for the Playbook, it adds some bars to bring the 1,7 aspect down to 1,50.

The number of pixels per screen are equivalent to that of iPhone 4 and iPad 2, so if you have artwork for these, it will be okay for Playbook without changes. If your game uses iPad 3 resolution artwork, you will probably have to scale down, or you will be wasting space.

Assets

Loading assets is also as simple as it should be. No poking in zip files, disabling compression on specific extensions, or using unnecessarily over-engineered asset managers (Android I am looking at you).

Applications are distributed as .bar files that are just zip files in essence. During the installation, the .bar file contents are extracted and the application can access the file system in any POSIX compliant way you know and love.

If you want to load files that were shipped with the application’s .bar file (textures, sounds, etc), you will find them in:

./app/native/

If you want to create files and save data for your application, you do it in:

./data/

As simple as it should be.

Leaderboards / Achievements

OpenFeint (now Gree) is not available ,and Game Center of course is not too as it’s an Apple only network. Blackberry offers it own network called “Scoreloop” that supports leaderboards, achievements, and challenges.

Closing words

For me, this was the easiest platform I ever ported to. After a long time, I really enjoyed working on a platform with “sane” software design decisions. Hats off to the engineers at Blackberry that pushed for a POSIX compliant platform that supports all the open frameworks we as game developers have come to love.

For most platforms, you must bundle all the libraries you use with your executable. On Playbook, libpng, libjpeg, freetype, and more are all included in the system, and you can link to that. No compiling hassles and making your executable fat with static linking of libraries that are already there anyway.

Support from third parties is still not that good as on other platforms. For example, for analytics on iOS, I use the awesome service of flurry.com, but they don’t have native support for Playbook yet. They support Blackberry through Java that might work with Playbook, but I didn’t want to mess with Java at all this time.

You will not require a fee to publish your game on App World after you have ported it, like there is on iOS and Android. As long as you have a game ported, you can register, get your signing keys, and put it out there. However, there is a review process similar to that of Apple.

In closing, I must admit that the overall feeling was that of things working effortlessly. The whole porting effort took two to three days, with one of the days working with a fever! I would suggest that all indie developers take a look at this platform.

Also given the fact that the iOS and Android app stores are so saturated with apps, this might be a good opportunity to get more exposure for your game. At the time of writing this, it’s been for days since Pop Corny released on App World, and it is still visible on the “New Arrivals” section.

If you are indie, you know that this exposure is gold for you. And this just gave me the idea for my next post about my experiences in AppStore, Google Play, Amazon Store, and AppWorld! Until then, happy porting!!!(source:gamasutra)