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.

• Must run on Windows and Linux, with the potential to port to other platforms (*cough* Android).
• Must be able to run full-screen in a sensible way.
• Must use a control scheme appropriate to the device.
• Must not have monetary cost associated with prototyping or experimentation.
• Must not require large volumes of platform-specific code.
• Must not overly restrict the software choices of myself or my eventual customers.

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.

• Must run on Windows and Linux, with the potential to port to other platforms.
  • This rules out reliance on DirectX, since that is not natively supported on any other platform. As nice as WINE is, it's a crutch, not a solution I would rely on in a professional setting.
    • No going the full-Microsoft-stack route.
• Must be able to run full-screen in a sensible way.
  • This means using each target platform's native windowing system in some way, since there is no standardised way to create a full-screen canvas in a web browser.
    • No HTML5/WebGL.
• Must use a control scheme appropriate to the device.
  • This means keyboard & mouse (with optional gamepad support) for desktops, and multi-touch for phones/tablets. This rules out being browser-based, as there is no standardised way for JavaScript in a browser to do things like capture the pointer, use multi-touch input, query gamepads/joysticks etc.
    • Again, no HTML5/WebGL.
• Must not have monetary cost associated with prototyping or experimentation.
  • Essentially, this rules out any development tools or middleware which requires a paid-for license to run on real hardware (as opposed to emulators), or to release small projects as an independent developer.
    • This rules out the otherwise-excellent-looking stuff from Xamarin, namely Mono for Android/iOS (with bog-standard .NET for the desktop side). The evaluation version doesn't support running on real hardware, and the Android emulator doesn't support hardware acceleration particularly well, which would make development painful.
• Must not require large volumes of platform-specific code.
  • Any approach which would require re-writing low-level things like file handling, audio output or significant chunks of rendering code is a non-starter, because that would essentially lead to me maintaining my own middleware, which is not what I want to spend my time on.
    • I have a feeling this may also further rule out the Xamarin stuff, since resource management on Android is handled quite differently from a "general purpose" OS such as Windows or Linux. They may have abstracted it, but given that they don't advertise portability to desktop Windows or Linux as a feature, maybe not.
• Must not overly restrict the software choices of myself or my eventual customers.
  • If something is going to have a target market in the real world, it must run on stuff which exists and works now, not experimental bleeding-edge things. For example, requiring OpenGL 4 for something like a simple 2.5D platformer would be a bad idea, unless it's really very, very pretty. Also, it would be preferable if, on Linux, the finished game runs with open-source graphics card drivers - partly because I think they represent a future ideal, but also simply because I run them myself and don't want to switch back to proprietary. My reasons for this are more mundane than idealistic, such as not being forced to hold back on (otherwise-stable) kernel, X server and desktop environment updates whilst the likes of AMD and nVidia catch up. Most people want to run games on their existing computers, not overhaul their environment in order to run games.
    • I would love to use something like the Unity game engine, but it has no support for Linux, other than by taking the somewhat round-about route of using the NaCl back-end. However, Chrome's hardware acceleration is still disabled on most open-source drivers.

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

¹ 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.