Another game framework for the iPhone? - Part 2

Daniel Sperl on January 22, 2010

Last time, I described our first iPhone game, Find it!. As I said, that’s a game that was relatively straight forward to implement, as there’s not too much movement involved. For that reason, we created the game directly with Cocoa (and learned Cocoa by doing so).

But some things are really cumbersome to do in Cocoa; that’s understandable, as it was developed with user interfaces in mind, not games. So we had to look for specialized game engines.

Or should we develop the game directly using OpenGL? I am against that, because having OpenGL calls (a C-API, after all) all over the source code would make the code confusing and difficult to read. To program a game, you need a framework that was designed with games in mind.

As I wrote in the last post, I am employee at funworld. My job at funworld is - yep, you guessed right - to create games. A few years ago, the games that are running on our PHOTO PLAY touch screen terminals were developed in C++, later we switched to C# with an in-house engine. And since about 2 years, we have been using ActionScript 3 (Flash) for game development, as this allows our games to be played over the internet, as well (just visit funwin.com). Contrary to common believe, the Flash API is really elegant and powerful, and you can program games just like you would in C# or Java: by writing well structured code. There’s no need to even open the Flash authoring application if you don’t want to.

You can read between the lines of the last paragraph that I really love the API that Adobe created for ActionScript 3. It’s clean, simple and very concise. I really longed to have something like that when developing for the iPhone. And I wanted to program in Objective C.

Not that I was a particular big fan of that language (at that time), but one thing that I have learned in my programming career is that it’s always best to stick with the fewest possible number of technologies in a project. Mixing different languages is a guarantee for nasty, hard to find bugs that are created by tiny incompatibilities. Furthermore, you are often forced you to violate the DRY principle, since you have to code some things twice.

Granted, sometimes there is no other choice. But if I have the choice, and I felt I had in this project, I’d rather avoid that and stick with one technology only. That technology had to be Objective C, as that’s the native language of the iPhone API.

To be continued in the final chapter!