Mozilla wants the Web to be a platform that’s fit for any purpose. That’s why the company is investing in Firefox OS—to fight back against the proliferation of platform-specific smartphone apps—and it’s why the company has been working on WebGL, in order to bring 3D graphics to the browser, Emscripten, a tool for compiling C++ applications into JavaScript, and asm.js, a high performance subset of JavaScript.

The organization doesn’t just want simple games and apps in the browser, however. It wants the browser to be capable of delivering high-end gaming experiences. At GDC today, the company announced that it has been working with Epic Games to port the Unreal 3 engine to the Web.

With this, Mozilla believes that the Web can rival native performance, making it a viable platform not just for casual games, but AAA titles.

However, there’s more to a game than JavaScript and WebGL. One problem with current WebGL applications (most tending to be proofs of concept rather than fully developed games) is that of load times. Even though traditional games have high-speed access to textures and models stored locally, on a hard disk or optical medium, their load times are significant.

Streaming a gigabyte of map data and texture from a Web server just to play a game is obviously a non-starter; you wouldn’t be waiting 30 seconds for a level to load, you’d be waiting 30 minutes. As an example, BioShock Infinite, an Unreal 3-powered high-end title, takes about 17 GB on disk, the vast majority of which is game data. That’s not something that you want to have to wait for mid-game.

The organization that’s responsible for the development of OpenGL, WebGL, and other related specifications, the Khronos Group, has set its sights on this problem. It’s early yet, but the group is planning to develop a common set of data formats for 3D models, textures, and other resources that 3D applications need, as well as a system for negotiating these resources.

With this in place, an online game could tell a remote asset server information such as how much bandwidth it had, what its screen resolution was, and so on, and be sent a set of resources that were appropriate. So, for example, a system with a slow Internet connection could be sent simpler models and lower resolution textures, in order to load quickly.