Flash, Java, HTML5, WebGL, Mono, Unity… for the game developers out there not programming in C/C++, it seems there are ever increasingly powerful ways to write-once and deploy-everywhere. I’ve been playing Project Zomboid recently – a charming 2D zombie survival RPG, written in Java and thus playable in a web browser on any reasonably capable platform. It’s an approach used to great effect by the wonderfully popular Minecraft, offering players a near zero-wait-time, no-installation path to playing. This kind of low barrier to engagement is increasingly more essential as users’ expectations rise and attention-spans fall; plus, as an indie developer, you get your game infront of as many players as possible without having to worry about porting to a handful of different OSes yourself.

So what do us suckers still using lower-level languages get to play with? Google offer Native Client (NaCl), a project that aims to offer secure execution of ‘universal’ executables atop a browser process. The browser becomes the “OS” (quite literally, in the case of ChromeOS), providing key system services, abstracting away platform-specifics yet allowing near-native runtime performance. Compile once, run on many, you don’t have to learn JavaScript. That’s the theory, at least. Does it work?

Well, yes it does. In fact it’s pretty damn slick.

Above is Freesynd, the open-source rebuild of cult-classic isometric shooter Syndicate, ported to NaCl last weekend and running inside Chrome 15. CPU usage is pretty minimal, even when running the map rendering at 1024 x 800. The game code can easily communicate with the browser (all that green file loading debug spew) and vice-versa (mouse movement, buttons that send cheat codes to the update thread).

I’m certainly not the first to tread this path – someone has already worked DOSBox into NaClBox, offering a way of running classic DOS games with zero hassle or setup. Even the NaCl SDK ships with a patch for getting Quake I running, including an impressive stress-test of having 9 separate instances of the game running in a single browser frame.

This is all really quite marvellous, something of a revelation for someone more used to having to port engine code to each new platform by hand. I can pull the above page up on Windows 7, or on my Mac, or in Ubuntu and it will execute, identically, on each, in 32 or 64bit as appropriate. Targeting for ARM architectures is on the roadmap, as well as the even more ambitious PNaCl (P for Portable) extension, moving the technology to use LLVM IR as its transmission medium.

We could end up with games and applications, written in high-performance languages, optimised into native machine code on-demand and delivered securely into the browser, free to also take advantage of all the functionality offered therein, like SVG and HTML5 UIs. dreamy.

So, the downsides? Well, this is only in Chrome so far – infact, the stabilized ABI that arrived in the latest SDK is only available in 14.0 and beyond, so the 18% or so of internet users rocking Chrome won’t be using it just yet. Compiling takes longer than usual, as one is producing multiple NEXE files for each supported configuration, plus I’m seeing file sizes that are about twice the size of their Win32 counterparts – nothing that can’t be solved with some compression, however .. a lot of that bulk appears to be padding or alignment.

There are a few programming considerations to watch for too – older code won’t necessarily ‘just work’ – specifically in the realm of file handling, because, of course, one does not have access to any host-local file system, not that the required files would be on there in the first place anyway. Asynchronous streaming and HTML5 FS Storage are the order of the day. A future post will cover what I ran up against when porting Freesynd, for anyone also toying with the latest SDK.

Really promising results, loads of possibilities – I’m hooked. To ubiquity, and beyond!