AirplaySDK for Cross Mobile OS Game Development

I am totally astonished as to how well AirplaySDK works. The guys at Ideaworks Labs have done it right.

They have made all the right choices when developing an SDK for cross mobile OS game development.

The issue with mobile game development is dealing with all the different Mobile OS plus dealing with different hardware using same OS. Game developers are somewhat lucky if there is OpenGLES implementation available as then they don’t have to worry too much about the rendering part. The sound and file IO and network features still mostly remain as an issue. OpenAL is not supported on most phones for sound. EdgeLib appeared a few years back to solve the problem of IO, Sound and Network features plus to allow software renderer in case OpenGLES is not available. More on EdgeLib in another post.

I tested the kartz sample from AirplaySDK on N82, N80, HTC Diamond, Samsung Omnia.

It is much easier to just list the feature pros and cons of AirplaySDK that I figured out so far by reading and trying out.

PROS

• Native binary without any VM.
• Good packaging tools for all OS.
• Fixed point computation as well as floating point available.
• Speedy Software rendering engine
• Auto fallback to software rendering when no hardware accelerator present.
• Sticking to opensource libraries.
• One Dynamic Engine (ODE) for rigid body physics.
• Support for multiple Mobile OS including Symbian, iPhone, Windows Mobile, Android,BREW and Linux). Edgelib doesn’t support Anrdoid and BREW.
• Highly optimised compression of assets for games. Not just simple zip compression but usage of Derbh which uses shared buffer across files. Claims on site say that Metal Gear Solid came down to 1.5MB.
• Arm debugger/emulator available that runs on Windows. Debugging is much easier this way.
• Windows emulator allows testing of software in various different scenerios (tilt/compass/keypad/touch/resolution)
• VS Studio programmers would love it as they can use VS with this SDK. Very tight integration.
• UI development possible for softwares other than games. This is interesting feature but as the Core System API is not extensive, it won’t be possible for creating full applications. Only simple apps can be built. There is possibilty of extensions that can do OS dependent API calls but this system is not exposed to developers to create their own extensions. There seems to be discussion of this opening up on AirplaySDK Forum.
• Extensions available (only for iPhone) for some of iPhone specific API
• Phone Orientation awareness and auto rotation of GUI.
• Human Interface limitations/possiblities awareness. Can detect touch screen and keypad and control based on that.
• Handling of phone events (incoming call/notifications) without extra code.
• UI code for input is intelligent enough to display touch keypad on touch UI systems without any extra work. MoSync can’t do that. EdgeLib has no support for UI controls/widgets.

CONS

• No support for OSX/XCode for development yet. It is planned though.
• Integrates best with visual studio which can be costly. Although express edition is free and should be enough
• Not very extensive API for core OS like System API.

My Test Results

Omnia Kartz Running in Portrait at 20 fps. Left/Right sides of screen can be used to steer.

OMNIA Kartz Running in Landscape at 18.65 fps. Left/Right sides of screen can be used to steer.

N82 running Kartz sample at 20 fps and steering with keypads. N82 has vfp

HTC Diamond running Kartz sample with 11.4 fps. HTC Diamond has no vfp/hardware acceleration

N80 running Kartz sample at 9.7 fps and steering is with keypad. N80 has no hardware accelration/vfp.

OS Independent Mobile Software Development with MoSync

Introduction

MoSync is truely amazing platform for cross platform development for Mobile Phone Softwares. It comes as a full IDE based on Eclipse. It supports currently Windows Mobile, Symbian, Blackberry (Java),Moblin and J2ME. Support for iPhone,Maemo and Android is planned. MoSync was made opensource a while ago and seems to have very active developers. The best thing is that it creates a binary instead of creating some sort of virtual machine code and thus slowing down the whole application.

In my experience as much as 80% of code needs be ported between platforms. Symbian’s disregard of providing standard C API initially and later requirement to install OpenC on phones with your software, overall confusing the install process for user, made it sub-optimum to use OpenC. The userinterface coding takes a long time on most phones even if there is standard API for core system like IO/Network.

Now MoSync promises that you can make one UI code and use it on other phones, as well as MoSync API translates to Core OS API which means no need to spend time in porting at all.

Test Results on a few phones

This sounded too good to be true so I had to try and spend a night playing with it. The IDE is based on Eclipse. I tried their UI samples on HTC Diamond, Samsung Omnia and N82.

Here are my findings

• There was no need to install each SDK for Symbian, Windows Mobile or Black berry.
• The binaries are made per Mobile phone and not per OS.This is a little inconvenience as they are not always compatible on different phones running same OS as I found out with Samsung Omnia.
  

  HTC Diamond with MAUIEx sample displaying a grid of images

  

  HTC Diamond MoSync Main interface (Diamond has higher resolution than Omnia)

• HTC Diamond binary was a native exe and when installed ran fine. Although the selection of items had to be done with keypad.
• The same HTC Diamond Windows Mobile binary when installed on Samsung didn’t run and crashed. The cab was created by MoSync. This is strange as it is same OS.
• The simple example which outputs keycodes when keys are pressed was not able to recognise back button on HTC Diamond.
  

  Omnia MoSync landscape didn't show properly

  

  Omnia MoSync Main Screen MAUIEx sample (jar file)

• When I compiled same code for Samsung Omnia, to my surprise, I got Java (jad/jar) files instead of native binaries. The UI ran fine but as it was not touch UI, I had to reboot phone.
• The HTC Diamond exe took over whole of screen on Samsung Omnia before crashing and had the taskbar on top hidden. Icouldn’t get that taskbar back and had to reboot phone. This is very scaryif all UI apps built with MoSync do it. This would mean that Windows Mobile Certification test will fail as they require ability to go to “Today Screen”(main screen of phone) using Start menu. More on that later.
  

  N82 Symbian Native BInary MoSync MAUIEx Clock sample

  

  N82 Symbian Native binary running MAUIEx created using MoSync

• The N82 was also a native binary that functioned pretty well as it is not a touch screen and soft-keys (keypad) was mapped perfectly fine.
• The UI development with MoSync has same limitation where support for both touch UI and keypad UI has to be coded by developer making it less automatic porting.

Final Thoughts

All in all MoSync would reduce development time by reducing the code portability needed but the need to test on each phone is highly increased due to uncertain behavior of same app on different phones. Again stressing here on HTC Diamond Windows Mobile app not able to run on Omnia which almost never happens with traditional development. I will play more with MoSync and create more entries on blog if I find something interesting or contradicting to my these initial findings.