Porting a game to the iPhone

Soon, a port of Tumiki Fighters, a game from Kenta Cho originally for Windows, will on the App Store. It’s a horizontal scrolling shoot’em-up game where you destroy enemy ships made of small colorful blocks with your own craft made of the same. Why do I talk about it? I made the port. (Update: now on the App Store.)

I was contacted in May by someone called Jeremy who wanted to take Tumiki Fighters to the iPhone and sell it on the App Store. He though I was the right guy for this since I’ve been working a lot with D (the game is written in the D programming language) and Mac OS X a lot. There was also things for which I was not very familiar with but which I was pretty interested in learning (or at least experimenting with), such as:

Game development

iPhone development

OpenGL

For me, this was a very interesting project because I had never worked on a game before (not counting those small old games attempts on a 486 a long time ago), nor did I used OpenGL.

The first problem was getting it compile to the iPhone: there’s no working ARM port of the D compiler and runtime at the moment, and while I could have helped bringing that to life, I decided I already had enough unknowns in the projects and that it’d be safer simply porting the whole game to C++, which turned out to be not so hard (the biggest difficulty was tracking object ownerships to work around the absence of the garbage collector in D).

Then, after converting the game from D to C++, I had to port the thing to the iPhone platform. Tumiki Fighters relied on SLD for accessing the screen and controls (keyboard, joystick), SDL_mixer for sound output, and OpenGL for graphics. The iPhone only has the stripped-down version of OpenGL called OpenGL ES. OpenGL ES works only with triangle coordinates (had to convert a lot of “quad”-based shapes to triangles) and does not support precompiled shapes (known as display lists). So I had to reimplement the graphics within these constrains.

Ditching SDL wasn’t so hard: I based the OpenGL context on the EAGLView sample code, and since I had to redo the inputs anyway (using the accelerometer and screen buttons) it was easier to completely replace SDL for that.

As for sounds, after various attempts at getting everything right, I finally settled at creating my own audio engine around OpenAL (for sound effects) and AVAudioPlayer (for the music). It turns out that working with audio is one of those really nasty parts of making an iPhone game: you need to be careful about the iPod’s background music (which the user can start at any time by double-clocking the home button), and AVAudioPlayer has the nasty habit of blocking the calling thread for half a second when you want to start a new music. So I’ve built my own audio engine to “fix” all this (and a little more), and I’ll make it available to other developers in a short while.

I’m pretty satisfied with the final result — my client, Jeremy, seems overjoyed to see it finally happen! I hope you’ll like it too; Tumiki Fighters will soonnow be on the App Store if you want to give it a try.

Comments

I’ve never played Tumiki fighters myself, but when I was working in England at a video game company around 2004 one of the coworkers (hi Damyan!) did download it and tried it on his windows machine.

I don’t remember the reason for trying it, but it was my first contact with the D language. While Damyan was playing most of the code and art team gathered around (typical look at that! behavior) and admired the cool and interesting feature of the game about attaching dead enemies’ hulls to your ship as a sort of expanding shield IIRC (or maybe it also gave you firepower?).

Anyway, there was only a binary and Damyan emailed the author asking for the code. He soon got it (maybe only a part) and after reviewing it we saw how it looked liked. The initial feeling was that it was a hybrid of C++ and Java.

Some time later I would start playing with D1 myself and did write some small programs to learn it. You will see me credited on the documentation of std.path.expandTilde which I needed to process the typical unix ~/.blah path for configuration files for some stupid program I was writing at the time.

I think it is a shame that D1 or D2 aren’t as well known as many other languages, and I would love to write D2 code for the iPhone, though it seems like the Mono project will be a much realistic choice when it comes out of beta.

PD: You are right on the sound part of the iPhone. Crappy OpenAL examples for the SDK. So much pain… OTOH they are good in that they force you to parse OpenAL’s spec and write your own wrapper. Much saner choice.