Indie-Resource.com

In the last era of MMO games, all the media and resources (ie. Models, Textures, etc.) were installed to the user's hard drive.
What is a good technique for 3d, webgl-based MMOs, so that the models don't have to be transferred every game startup (possibly introducing load times beyond belief)?

I know that once a resource is sent the first time it is cached and a "Not Modified" response is sent to each request for the same model.

Maybe the filesystem API is ready for such a task?
Or maybe I am overthinking it... just load the data for sub-areas inside of larger areas?

Any ideas would be greatly appreciated!

Thanks!
Luke

You are right there are some considerable load times for very asset-heavy games in the browser. I am not sure if the File API is going to be of a ton of help. Like you mentioned, there are a lot of benefits to having them cached in the browser, but the problem is that speeds up the later connections, when players are more involved in the game and more likely to wait, whereas the first connection is the slowest, which also happens to be the most critical to get up and running fast.

One thing that speeds up art asset transmission is the well-known CSS sprite method, where you put everything on the same sheet, similar to a game sprite sheet, and simply use CSS to only display what you need where you need it. The benefit is it drastically reduces HTTP requests, which is really what slows down the requests.

Also, keep in mind that bandwidth has exploded in the last 10 years. Obviously transferring all the art assets for a game like World of Warcraft would be problematic for an HTML5 MMO, but so far no one has produced a game of that scale in HTML5. Most of the HTML5 MMOs I have seen have around 5mb of graphical assets to transmit. On even American modern connections, that is maybe 2 - 3 seconds to download. Loading the engine seems to take much longer.

If it really became a problem, you could smartly use a combination of asset preloading, and dynamic loading of CSS sprites to basically make a low tech "streaming" work. For example, you know that people start in Beginner Zone, so that needs to be preloaded. You know that players could possibly see any character wearing any gear, so that all needs preloading. But no one starts in Next Zone, so as the player moves through the Beginner Zone, you could trigger the loading of the assets for Next Zone by making tiny, easily missed graphics for Beginner Zone be on the same CSS sprite sheets as the graphics needed for Next Zone. People are unlikely to notice the tiny, easily missed graphic in Beginner Zone popping into view a second or two late, but they will be carrying the sprites needed for Next Zone.

I guess the real, and unhelpful, answer to all this is "We are all still figuring it out". I think we are a ways out from anyone trying a AAA MMORPG in HTML5 like World of Warcraft or even a 2D version, but I think it is inevitable that we will, so I say to anyone heading that direction, just dive in and experiment. You may just discover useful new techniques in what is basically the unknown frontier of online game development

Thank you for the help!

The reason I ask is I am looking to continue development of my engine which I stopped after seeing this become a problem. Here's why: The engine is 3D, so other 3D-specific assets like models are needed. These can take ages to download.

My initial solution came down to using node-webkit to run the games produced by the engine. It would still have all the webgl stuff, although it would all have to be downloaded (think of a patcher)...'

So here's my solution for the moment:
Have a in-browser version for those who have an incredible bandwidth,
AND
have a download version for those who have a slower connection.
Note that the server will run both options as if they were the same, because they both act like they are the same.
Maybe I could have it so the in-browser version has scaled down textures or something like that..

It depends on type of game and your servers. WebGL assets are not that big. Especially if you have a way to compress them like most modern engines. You load every level as needed. You could easily compress a level to 10 megs which on a good server and a descent connection would take 5 seconds.

I have seen unity compress quite a few models and levels into less than 10 megs.