Unreal Engine 3 in Firefox with asm.js

As Brendan said, it's UE3, all of it. See the video at [VIDEO] (second half of video) for the Sanctuary UT3 map, complete with bots, shooting, etc. Once the engine was ported, we threw random UE maps at it, and it worked fine. It works in any browser that has solid JavaScript and WebGL support. Audio will work with Web Audio, but it'll gracefully not have audio effects if it doesn't. There's no Firefox specific magic here. If you're on Aurora/Nightly, then you get asm.js/Odinmonkey optimizations and it runs even faster; that's it. Edit: UE3 was chosen because it's known stable and optimized tech. This isn't the pinnacle of what can be done, far from it. But neither us (Mozilla) nor Epic wanted to be working with code that was still under active development for a next generation engine while simultaneously trying to port it to a new experimental platform. One step at a time! :p

As mentioned in other comments, we also ran other UE3 games, like Sanctuary. We demoed that in a booth at GDC last month where people could play it. That's a full UE3 desktop game with bots, AI, normal FPS mouse control (not tablet-like), etc. etc. You can see it in action in the 2nd half of this video [VIDEO] And it's using the exact same code as this demo. You literally use the same compiled JS, and just swap in a different set of game assets.

Surely there's a trade off, as we add more and more features to browsers, w3C specifications, add ons, JavaScript updates etc, a browser will inevitably get slower. Yes older browsers were fast, but they did little in comparison to today's virtual machines. The fact that you can do this [VIDEO] in a browser should tell you we've come a long way from them just being Document readers.

[VIDEO] Unreal Engine 3 (may 2nd release vid) very cool! Can I use WebASM to do amazing music visualizations?

I'm not sure if I agree with all of this. People forget flash kinda sucked. One of the most significant ways in which flash sucked was the performance. Imo, the most famous flash game of all time is Binding of Isaac, which basically couldn't achieve a respectable, consistent frame rate even on the most powerful rigs. It's native rewrite, Rebirth, never had performance issues. >You can't do pixel-perfect rendering Sure you can, with canvas, and if you want to have absolutely perfect control, there's WebGL (and nice stuff like PixiJS) >No nice pipeline for integrating vector animations/art into games You can render SVG sprites into bitmaps, and use them in WebGL or canvas, as you mentioned, you needed to do this too in flash as well if you wanted decent performance. >easy to make fancy + good-looking interactive UIs If I remember correctly, most fancy game UIs were built with some framework, like flixel, which used low-level drawing primitives and built-up the UI from scratch. Alternatively you could use the full power of HTML+Js frameworks to build arbitrarily complex UIs and overlay them on your game scene. >many of the html runtimes for new engines (Unity for instance) feel waay heavier/more sluggish in the browser True, but they are meant to be, and meant for bigger games than flash/html5+js is. But for modern engines, HTML5 export sucks, there's no doubt about that. But that's a failure of execution, not technology. I remember Epic citadel a decade ago, which ran by compil