mangobrain

Different platform is different :(   2012-05-03 20:58:18

For a while now, I have been looking into various ways and means of developing cross-platform games, and have come to the conclusion that they all suck. With the current state of the art, it would appear that the best one can do is pick the best of a bad bunch.

I have been working with a set of ground rules, as follows.

To me, those sound like fairly sensible requirements, and I didn't think I was asking too much in this day and age. Let's have a look at what those requirements do to limit my options, though.

So that leaves me with... what? I thought about using Java, but it turns out the bindings for OpenGL ES 2 on Android are specific to Android, so that would leave me re-writing the lowest level of the renderer for a different OpenGL binding on the desktop. That is not an attractive prospect because all the usable desktop OpenGL bindings for Java are also provided by third parties, rather than being a standardised part of Java itself, and they don't always work especially well (issues with Minecraft on Linux and OS X spring to mind). I've been playing with the Android NDK on and off for the past few months, attempting to port some existing OpenGL utility classes I'd written for Linux in plain-old C++, but the JNI is so difficult to use robustly that it's not really worth the effort; couple this with the aforementioned differences in resource handling on Android, and I've finally admitted to myself that developing so much platform-specific code before I even get to the game itself is just not a good use of my time.

At the moment, I have decided that there is no option which meets all my requirements, so I have spent a little bit of time thinking about which ones I am willing to be flexible on, and unfortunately the least pain is to be had from sacrificing Linux and Android. Technically, the most attractive options are using Unity, or developing directly for NaCl. Both have the advantage of supporting Windows, OS X and Linux, accepting that Unity's Linux support is NaCl-based rather than native, and that NaCl's own Linux support is itself dependent upon the slightly-shaky hardware acceleration in Chrome. Unity also has the advantage of simple portability to Android.

So I should just swallow my pride and use Unity, right? Well... almost. I still don't like the idea of using closed-source middleware, even if it is free in a monetary sense; plus I am still not convinced enough of NaCl & Chrome's own robustness and suitability to warrant the pain of using Windows for development whilst praying the Linux support works out in the end. To test the waters, I have decided I will experiment with developing directly for NaCl, from the relative comfort of Chrome on Linux. I have also decided I am a glutton for punishment.

Vender lock-in is still a bad idea when that vendor is Google, but at least other people have the option of implementing NaCl, even if they never do. Plus, the potential for ARM support in future when PNaCl goes stable may bring back some of the (hardware) platform support lost by using a restrictive toolchain. Who knows - maybe NaCl will even end up on Android one day.

Comments

1 Stu   2012-05-20 10:52:44

Game engines sound like nothing but pain and suffering.

The game I keep talking about making is going to be GApps/HTML/Javascript. Simply because I have no experience with game engines, and no willingness to add additional distractions to an already ballooning project.

You must be logged in to post comments.