With the growth and popularity of iPhone app development, many of these developers are considering how to expand their market to other platforms. Some of them have found success in porting to AppUp and have discovered some interesting challenges & opportunities between the platforms.

The following is my Q&A with developer Mike Kasprzak, CEO of Syhkronics , on his experience in porting his award winning game "Smiles" from iPhone to AppUp.

Tools & Methods Used in Port Dealing with Hardware Differences Accelerometer Keyboard Multi-touch Porting Surprises Features Lost or Enhanced in Port Game Play Differences Intel Support Tips & Lessons Learned

Q. What tools & method did you did you use to port your app to Netbook, and why did you go that route?

Mike Kasprzak:

First of all, I used OpenGL for graphics. Virtually every platform worth its weight has a version of OpenGL for it (or an API just like it). On Mac, Linux, and most mobiles, it's their sole 3D graphics API. On Windows it's an accessory, but it's always there. OpenGL is actually a much older API than DirectX, but it's a robust and solid design that continues to be relevant almost 20 years later.

I wrote my game in C++, which is also quite good at being "old". I'd hide the iPhone specific features requiring Objective C code behind C style functions and variables, so to port to PC, I simply had to rewrite these functions.

I structure my project manually so I can mix and match Xcode projects, Visual Studio projects, and makefiles together in one common layout. It takes some planning and homework to do this right, but it's far better than copying files around manually. My makefile setup is custom, and automatically detects all files in my project. But for both Xcode and Visual Studio, I manually build a project by dragging all my source file in (directories at a time).

I keep my files synchronized using Subversion (SVN), which is also great for backups. Specifically I use TortoiseSVN on Windows and SCPlugin on the Mac. Both integrate right in to Explorer/Finder, which makes them very easy to use.

And for the PC side, I used SDL as my host API instead of writing native Windows API code. On iPhone I wrote native code, but the PCs are all SDL. That has the added benefit of working on Windows, Linux and the Mac, in addition to some Linux based mobile devices too (Nokia, Palm).

But even though I used several standard libraries, I still wrote my own wrapper library on top of OpenGL and SDL. This will let me eventually port the game beyond those supported above, to DirectX on Windows, Khronos' OpenKode platform (the OpenGL group's alternative to SDL), or to the native APIs of game consoles like a PlayStation.

Finally, the game code itself is like a module that sits on top of platform specific code. It has an Initialization function, a Step function, and a Draw function. The game code doesn't care what shape or size the screen is, it just draws on what it's given. Every frame of the game is a call to "Step" then "Draw", but if the game is is ever running too slow, "Step" can be called a few times to catch up.

Q. How did you deal with hardware differences such as screen resolution, multi-touch vs mouse & keyboard and accelerometer in the iPhone?

Mike Kasprzak:

On screen resolutions, there's a few things I did.

The first was that I designed my game and UI to be scalable. That means not relying on pixel co-ordinates to place things on screen. That probably sounds a little complicated, but the trick to it is picking a reference resolution, and you scale that up to the actual resolution. So for example, if your reference resolution is 480x270, you could scale that up 4x to 1920x1080 (i.e. 1080p HD).

What might not be clear, this scaling thing is all done with 3D graphics hardware and texturing. My game Smiles is a 2D game, but it utilizes the 3D graphics hardware in whatever device its on. The simple "how" is by not using the "Z" co-ordinate, and ignoring features like depth testing. There is a bit more math involved in working with 3D hardware, but everything is 3D accelerated these days. If you're not using it, it's just performance going to waste.

Next, I was sure to create all my game art at a very high resolution. Even though I was originally targeting the tiny iPhone screen (480x320), my original art was high enough resolution for HD 1080p (1920x1080). Actually a nice thing about this is the math. You can do smartphone sized art (iPhone 480x320 and others), then double that for 720p HD (Netbooks, tablets/slates, larger pixel pitch phones), and double that again for full 1080p HD (your PS3s, Xbox 360s, and high end gaming PCs). In practice that means starting from the top with your 1080p ready art, then you can half the size for your "720p" targets, then half it again for your low resolution smartphone size targets. The this whole "half'ing" thing can be easily automated too.

So with art and UI designed to scale, the concern then becomes the aspect ratio. The reference resolution stuff above handles fitting to aspect ratios. All you do is pick or calculate a scalar that actually makes it fit on the screen. That however can leave some dead space on the sides or below. Rather than use black bars in Smiles, I solved this 2 different ways. The first was to create tile-able background, and the second was to create a really large background.

Tile-able effects are easy and scale well. You simply add another row or two of tiles to fill in extra space.

For large backgrounds, the idea is you create something larger than the screen. Twice the width and twice the height of your reference screen is usually enough. The background itself should be something that doesn't contain anything visually important, but if they can see it, it doesn't look out of place.

As for multi-touch, it actually wasn't a problem for me at all. Generally speaking, multitouch is used mostly for gestures. Pinch zooming, two finger twisting, and so on. Despite all that fancy stuff, the most common thing you do with a touch screen is touch it.

What did require some design thought were the differences between a mouse and a touch screen. Comparing the two, both give you positions, but only a mouse can hover. What I mean by that, a touch screen can only tell you where you're touching, not where your hand is. Where as a mouse cursor hovers above what you want to press, waiting for the click to take action. Design wise, if you game can work with single-touch touch screens, it can also work on a mouse.

Actually there's a 3rd type of input to consider. Pen tablets and Tablet PCs. You usually only ever see these in the hands of graphic artists, but a pen tablet is like the best of both worlds. Physical positioning (where the pen tip goes, the pointer goes), and hovering.

And if you really want to get nuts, you can consider camera based pointing devices like Nintendo's Wiimote, Sony's PlayStation Move, Eyetoy, and Microsoft's Natal. The former two are like a mouse, and the later two are a sort of multi-touch.

Still, all of these are pointing systems. They each have a way of specifying a position, with varying degrees of accuracy and ease. The simplest is still the touch screen; Positions without hovering. If you start your design there, you can usually find a way to make it work on any other pointer.

The lack of keyboard on mobiles convinced me to design the game so that it works entirely with a pointer (touch screen, mouse). It's also easier for casual users this way. No need to take your hand off the mouse, just click click and go.

Like how multi-touch is normally used for gestures, an accelerometer is normally used for detecting the orientation (portrait, landscape). Locking the game to a single orientation on PC is the usual solution. Although on iPhone, I did end up using physical rotation as a mechanic in the game, so I had to come up with some way to make that work on platforms without accelerometers. That lead to me adding rotation buttons to the interface.

And now the game is ready for anything. :)

Mike Kasprzak:

There wasn't so much surprise in the effort, but once I really got serious about graphics programming, that the Intel GMA 950 was a much better graphics chipset than I had been led to believe. Compared to the PowerVR MBX in the original iPhone, the GMA laughs at it and can render twice the resolution easily with performance to spare. I'm even using a Netbook instead of a Laptop since it keeps up just fine. If I'm doing serious crunch-time work, then I'm at my quad core workstation PC. I don't always need that though. I can roam the house or sit outside, without the need to lug around my old "desktop replacement" beast of a laptop.

So the surprise: I can actually do the porting ON the system itself.

Q: Did you lose or enhance features?

Mike Kasprzak:

The game is nearly identical, but to meet the deadline, I did briefly cut some features (game modes). They will be back plus many many more in the next update. It was purely scheduling, not something a Netbook couldn't do, just my own time to do it.

Also the Netbook version was like a "clean slate" for me, meaning I could safely make corrections and changes to the design, since there was no risk of breaking save games or high scores in the established iPhone version. So while yes, a few game modes were cut initially, many other things had already changed. That's one of the luxuries of creating your own designs and porting them. If you decide you want to change something, or try something different, you can on a new platform. Obviously you don't want to do something that would ruin a game, but bringing a game to a new platform is an interesting freedom.

Q: How do you compare the game play between the two devices?

Mike Kasprzak:

It's very close! The game mechanic behind Smiles is at its best on a touch screen, but works reeeeally really well on a mouse too. That's the other part about AppUp that excites me. Right now we're talking Netbooks, but OEMs are creating MID and Slate PCs too with the same hardware (Intel Atom). Ordinarily there would be no way to get in front of customers in this market, but AppUp is in the unique position serve them.

Mike Kasprzak:

Submission was very straight forward. I didn't really run in to any problems, but any questions I had, Intel has been really good about getting back to me. Every platform has submission nuances, that's why it's a submission and not just putting a download online. But AppUp is definitely one of the easiest.

Mike Kasprzak:

My advice, definitely think about portability from the beginning. Admittedly, I have a lot to say on the subject, but at its core it's not to difficult to understand. Write your game code in C/C++, consider using OpenGL ES, make your original art at high resolutions. That way your game code and assets can be taken anywhere. Plug it in to something like SDL, and in a day or so you can be up and running on a PC.