In this reprinted #altdevblogaday in-depth piece, Nlogn Information's Charilaos Kalogirou walks you through bringing your iOS game to Blackberry Playbook, the easiest platform he's ever ported to. 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. 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: If you want to create files and save data for your application, you do it in: 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 chalenges.

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!!! [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]