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
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.
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?
, 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.
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.