Is there an straightforward way to solve the issue with crazy load times on big WebGL games? If I remember correctly, I played one a while ago and it had to download assets for ten minutes before I could play it and it was a huge downer. If this becomes the norm I'm sure it wouldn't be too hard to get used to, but I was coming at this game from the mindset of playing instant gratification flash games.
It would be cool if the engine could figure out what assets to download on-the-fly, but I have a feeling that's not the case so game makers would still have to do a bit of work before making the games web-ready (instead of ideally just hitting an "export to webgl" button).
In Unitys case they already had a concept called AssetBundles that allowed you to launch an initial small loader scene and show something while downloading other Bundles in the background. If they port that concept to HTML5 it should be pretty easy to implement on demand loading..
I think Unity can distribute their runtime library via CDN (just like three.min.js or something). It will able to cut down the initial some megabytes.
Progressive downloading technique (like AssetBundle) is a must for both loading time and server costs. Every developer should use it because if many games have massive long loading time (like Epic Citadel or BananaBread or Monster Madness. Whatever Mozilla says, these demos are not commercial ready), end-users will hesitate to click game links. I feel many gamers already stopped considering the web as a game platform these days. Kids know how to download games from App Store, but they don't know how to use Mobile Safari. All App Store, Google Play and Steam are growing. Many users will continue to prefer download apps for a long time.
Ultimately, time may solve the problem. The internet bandwidth is growing 50% per year. Many PC browser games will start instantly 5 or 10 years later, Mobile will have more trouble.
You could display a much smaller web game while the main game loads. The trick is finding that proper balance where people are entertained long enough for the real game to load, but not so much that they'll want to keep playing the loading game afterwards. I, for one, can't wait to be waiting for a loading bar for a loading game to play while the main game loads.
Or how about this: Game Loading Lobby MMO, where you can hang out and chat with everyone waiting for their real game to load - IN 3D!. Maybe you can break out the character builder and have people do that, then get dumped into the MMO lobby while they wait for game assets to load.
Or you can just put a reddit iframe above the loading bar and call it a wrap.
Html5 appcache will download and cache resources indefinitely, and supports differential updates, but it's somewhat of a pain to work with and there are some browser-specific constraints on how big it can get. Using gz compression the size of the assets shouldn't be that much bigger than downloading a desktop game (which also takes a while).
People forget that modern 3D games take up huge amounts of storage space. Meshes, textures, maps, and sound recordings aren't cheap.
You could mitigate this by asynchronously loading certain files, or outright designing a game to be quickly downloadable (for example, by using an art style that uses only shading and mesh coloration instead of textures, or by going all demoscene and procedurally generating everything), but for anything resembling a modern "AAA" game, a long download time is probably unavoidable.
You can read/write local files from within a webpage. So I guess its possible. It would require looking into how WebGL loads assets and overriding this with diskIO operations not difficult.
The next problem would be asset management, but this isn't an important issue. A lot of game data is already stored locally with little to no protection.
I'd have to look at how javascript handles file I/O it might not be 'that' difficult.
It depends. I was talking about storing files in user-land not browser-land, like c:\program files (x86)\company\our cool game\art\texture.png
That can handled currently in HTML5. Even written too if you give it permission on load. This would side step warnings of IndexDB going over 50MB would be easier with large textures/models. Also side steps that webworkers can't really do asynch indexDB stuff.
I'm not a web developer at all. I'm just researching this as I type it.
Oh, for local apps? Sure, you can do that. file:// doesn't work well though (you can't load textures from it, for example), but you could use a local server.
The problem is that most people don't have a local server. Even if you have local (geographical nodes) your still limited to the clients bandwidth.
Also how can you load say models but not textures? All files are just binary data.
I guess your only option is to play around with indexDB. Also it that per file 50MB, or overall 50MB. I guess with more aggressive compression could could achieve decently small disk usage.
dont worry CORS or same origin policity have nothing to do with the way the server should load assets.Not sure why the other guy talked about that. The issue you raised still stands.
That's why webapps are built in a modular way: it's similar to 3D games in the sense that you don't need to have everything immediately to start using it: load what you need to display first, and get the rest when needed: e.g. you don't need the last level of a game when you're just starting it.
Actually, I was toying lately with the idea of making my own modules loader * insert mandatory xkcd strip about competing standards * because I wanted an hybrid loader that can pack multiple modules per file, but that doesn't have to have all modules in a single file either (e.g. 3d models could be packed with their textures, or levels packed with the models they need) as I haven't come up with a satisfactory setup to do so in r.js or browserify yet, however Unity already solved that issue in its Web Player, so making a JS version of it should be trivial.
Update: I'm actually having high hopes for webpack as it seems to combine the strengths of both Browserify and RequireJS, and seems tweakable to package modules into a couple of files. I'm not sure why it's way less popular on Github though.
If it becomes popular I'm absolutely certain those types of techniques will be developed. Just as with the XBox One and it's ability to let you start a game that it's still downloading
It would be cool if the engine could figure out what assets to download on-the-fly, but I have a feeling that's not the case so game makers would still have to do a bit of work before making the games web-ready (instead of ideally just hitting an "export to webgl" button).