What's the current preferred method for serving/storing game data on html5 games

Question

Given all the recent improvements on web platform (webgl, websockets, etc.), it should be now possible to see great games on web. However my biggest concern so far has been around serving and storing the game assets. AFAIK the webstorage only supports a few megabytes and it is not enough for the majority of the games. Even if I work around that limit by providing a ton of different origins, is it possible to claim that it's a safe method? For desktop games we have a lot of anti-cheat mechanisms (steam has one, most A+ have them builtin) If I store my game assets using the webstorage can I claim that they won't be modified by the user?

My game has assets around 800 mbs and I would love to get some feedback on how to serve them and store them properly. I'm trying to satisfy the following:

• People shouldn't be forced to download all of the assets every time they want to play the game [unless there's a patch, etc.]
• It shouldn't be trivial to make client side hacks and change configs to get all the good stuff without playing/paying for them [greasemonkey!]
• Ideally, the solution should work on all the browsers [latest version of IE, Chrome, FF and Safari][no mobile is OK]

Answer 1

No browser supports an unlimited amount of storage space (or anywhere close to your 800MB) for arbitrary web apps out of the box, and most are limited to 5MB to 10MB.

The easiest way to explicitly cache data is to use the Application Cache (manifest). You can also use LocalStorage if you want to programmatically download levels in advance rather than precaching the entire app. These both have size limits in every actual browser, however, though the specs don't explicitly mention a size.

You can request a size increase when your page loads, though you need to deal with the case where a user or the browser rejects the request. Note that simply failing to load is not ideal as it is not particularly easy in some browsers to get the request to reappear, so if you refuse to run without the increase in storage your game will just never run and the user is stuck. Use this as an optional way to speed up your game, not as a mandatory feature.

Exceptions to the rules can be found in some browsers under special circumstances, such as the ability to use more space if your app is registered in the user's Chrome App list, which requires them to "install" it via the Chrome Store (the app itself still lives on your server; the store just adds a record of the URL and some permissions to the Chrome app list).

Note that browsers naturally cache files. So long as your server respects the If-Modified-Since and If-None-Match headers and properly sends the Expires, ETag, and Last-Modified headers, the browser might cache your files. You hence might be able to get away without explicit storage so long as your game doesn't download more than ~50MB of content at a time, though the caching is purely opional for the browser and it might not cache or evict the cache items as it chooses (unlike the app manifest or local storage).

Answer 2

You've confused the assets with client-side data storage.

You can load assets using normal HTTP requests that the browser makes. These are subject to normal HTTP rules about caching, expiring and conditional requests. If you have 800M of asset data, you definitely need to do this.

There is no limit to how many assets you can load in the "normal" way (these are typically loaded by either - img elements, audio elements etc or XmlHttpRequest, which can nowadays be used to load non-XML and even binary data)

There is also no real limit to how much data you can store server side in your own system. If you decide to store player's replays, screenshots etc, you won't be limited by LocalStorage limitations if you post the data using XHR to your server. (Obviously there is a practical limit to this as most users have fairly limited upstream bandwidth)

---

As far as anti-cheating, etc, is concerned, you can't stop people cheating. They can trivially substitute your assets with their own versions, and there's nothing you can do about it.

You can probably make it difficult enough for them to get the premium content without paying to convince them to pay though. Pirating a game served online is fairly tricky and won't work any more once you update it.