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 these 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. Not only Blackberry 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, 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.
The Blackberry 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 will get me until I started missing the command line. Surprisingly, it did all the way. 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. The 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 in correspondence 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 bpseventt structure that you pull with bpsgetevent(). The event belongs to the “screen domain�? and you query its data using the screengeteventproperty*() 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_iv(screen_event, SCREEN_PROPERTY_SOURCE_POSITION, position);
The above snippet is all you need to get the basic touch info. The touchstate can be one of SCREENEVENTMTOUCHTOUCH, SCREENEVENTMTOUCHMOVE and SCREENEVENTMTOUCHRELEASE. Which 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 the 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 is self explanatory of 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 ok for the 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 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. Hat off to the engineers at Blackberry that pushed for a POSIX compliant platform that supports all the open frameworks we as game developers came 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.
Closing, I must admit that the overall feeling was that of things working effortlessly. The whole porting effort took 2-3 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 its been 4 days since Pop Corny got 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!!!
