Isn’t Unity awesome! For 3D games developers it’s probably one of the best choices out there and seems to run on just about any hardware platform you can throw at it. Now with Unity 5, things are getting even more awesome as it now targets WebGL, removing the need for the Unity browser plugin.
So how does all this work? Well basically the Unity runtime code needed to be cross-compiled to JavaScript allowing it to run in your browser. This was done using emscripten to convert the runtime’s C and C++ codebase into asm.js JavaScript. I’ve mentioned asm.js a couple of times before. It’s an optimised subset of JavaScript that can be AOT-compiled by supporting browsers into native code. The beauty of asm.js is that being a subset of JavaScript, it will still run on browsers that don’t directly support it ensuring a level of cross-browser compatibility.
Of course, Unity game code itself is written in C# (and UnityScript) and compiled into .NET bytecode. That bytecode also needs to be converted to JavaScript before your game will run in a WebGL enabled browser. To achieve that, the Unity guys developed a new technology called IL2CPP, which takes your game’s bytecode and converts it all to C++. Emscripten is then once again employed to convert all that to JavaScript.
Phew! Sounds pretty technical but it results in your Unity games being able to target WebGL compatible browsers and that’s a very exciting prospect for many. Theoretically your games will run on browsers and platforms that don’t have support for the Unity browser plugin. For example, this could open up Unity games to Android phone and tablet owners wishing to play games within their browser rather than downloading apps. And if Apple ever bothers to support WebGL on mobile Safari then we could also see Unity games running in the browser on iOS.
It’s early days yet and Unity’s WebGL support is still in Early-Access. However I was able to run and test a few demo games on my Macbook using Safari. I must say, I was very impressed. If you fancy taking a look then try out both Dead Trigger 2 and AngryBots, which show off the technology’s potential. Great stuff!
Now I wonder if Adobe will go down the same route with Flash and break away from its dependency on the browser plugin. It could breathe new life into the much-maligned runtime and give Flash a wider reach on mobile phones and tablets.
Just think how much further along Unity’s support would be if they hadn’t wasted time on that silly Flash exporter 🙂 I recall they explicitly chose Flash over WebGL, which confused quite a few developers at the time.
Unreal Engine has WebGL support today if you want to play around with it now. It’ll be interesting to see what pricing Unity adopts for Unity 5. At the moment the enormous upfront costs of Unity make it a really hard to choose over UE, unless you know that your game will be a decent success.
Interesting times for 3D engines! As I’ve said before, apart from no one buying them, this is a brilliant time for Indie game development. So many middleware companies are throwing their tech at indies.
Oh, Adobe have broken away their crusty old runtime from the browser engine – that’s what AIR is basically. Or do you mean compile the Flash VM with emscripten? Wouldn’t that just make the VM even slower and more memory hungry wrapping another few layers of abstraction around it?
>> Or do you mean compile the Flash VM with emscripten?
Yeah that’s what I meant. And yeah you’re most probably right regarding performance and memory usage.
maybe i am a bit late but the flash was good, i am annoyed it went, but WebGL has had such support now from the browsers