Interview: Epic goes all-in on HTML5 with UE4 support

As part of a string of announcements centered around its upcoming Unreal Engine 4, Epic Games has revealed that its popular game engine will (eventually) support web-standard HTML5, allowing the deployment of graphically-rich games that, in theory, can run on any device that can display a web page. The way it was described to us, Unreal Engine 4 games running in browsers will be able to achieve near-native performance to the hardware it's running on, thanks to the elimination of UnrealScript's bottleneck. The company doesn't have much to show yet -- in fact, the only proof-of-concept demo it has right now is running in Unreal Engine 3, which will not support HTML5 -- but it's clearly laying the groundwork now for what could be the first serious act of faith by a major tools provider toward what has so far been a struggling new web standard. We sat down with Epic's Tim Sweeney and Mark Rein following a demonstration to find out what this could all mean, where HTML5 is going, and whether developers have any reason to make specific game SKUs if they can just ship one browser version that runs on anything. We'll have more from Sweeney and Rein on today's other announcements in a future article. We haven't seen a lot of heavy hitters like Epic come out and properly support HTML 5 before now. What does this mean? Tim Sweeney: This upgrades the web to a platform. Just like Sony and Microsoft have platforms, the web is now a platform, and if you can build and ship a game, you can have it run in several (and in the future, any) standards-compliant browser and have a great experience. It marks the end of drivers, installation, all the other weird quirks of legacy game development. Mark Rein: Operating systems. TS: Yeah, it's instantly deployable. Now you can have world-class graphics in any web browser -- for games, tools, whatever. And it's not done through any quirky language like Javascript, either. We're doing pure C++ code, the same code we run on all other platforms, and it's just being cross-compiled into HTML5 and Javascript for the web environment. It's a real change for the games industry, and once everyone's fully thought through the ramifications of it, I don't see any reason why if you're shipping a game in PC you wouldn't also ship it as a Web application. You could go even further than that, in theory -- why ship a console-specific version of a game if that console has a web browser? Is this a threat to the traditional publishing model? TS: It's a big area of future tension. There's great competition between all the browser makers to make them all as standards-compliant as possible, but when you combine that with the platform-holder who wants to tax app sales on their platform, there's an economic motive to resist fully-standardized, high-performance HTML5 and Javascript. MR: And with consoles, since they're the same configuration, for the most part, you work really hard to make those games push into every crevice of performance for the platform, and the compiled Javascript will never get you that kind of performance you get from optimizing native to the hardware. But on PC, where you have virtually unlimited ranges of power -- and most people have more PC than you need to play what you consider "web games" -- you'll have lots of capabilities. But on the console, you see the big blockbuster games like Gears of War, people expect every last pixel to be lit up. But there's the temptation to just ship one SKU that works on absolutely everything, even if it means you're not taking advantage of a platform. TS: Yeah, if your game is not primarily about beautiful graphics, that's an interesting option. MR: There's two vectors you want to go for. One, you want to go for the widest possible audience. Two, you want to deliver the best experience you can. And the question is, can you do both? Or does the second vector mean you ship native versions here, here, and here? Or is it really more about delivering it to everybody with HTML5. It's like the Brits say, "horses for courses," you just make the call based on what you're building. TS: HTML5 changes things. It's hard to see why anyone would ever need a plugin in the future. You have all that power at your fingertips, with Javascript. As far as the HTML5 deployment plans go, is there an easy way to do it through you or is that up to the developer? TS: That's coming. With UE3 dev kit we had very easy deployment to several platforms, and now we're working closely with Mozilla to define this process with UE4, but in the future there will be very easy deployment. Ease-of-use is a critical issue, we want one person to be able to pick up the engine and make a little game and get it out on the same day. That's our ultimate goal. Does that involve hosting partnerships, or is that an area you don't want to touch? MR: Actually, it should really just be "plop these files in this directory," and where you want to host, you figure it out. Back in the UE1 days, you didn't have to install the game, you could just X-Copy the game. The HTML5 stuff, you just copy from machine to machine, run the browser version that has the ASM.js code, boom, you're up and running. TS: There's no server, it's entirely client-based. It's just a web page. MR: It'll actually run even without the ASM.js helper code, it's just slower. But it'll run just like that -- boom, boom, boom.