HTML and CSS Reference
In-Depth Information
Client-Side Storage
At this point it is worth mentioning a little bit about client-side storage. The techniques described for HTTP caching
are about using a cache to avoid a full HTTP request. There is another option for storing data that sits between server
requests and memory that could potentially achieve this if used correctly. Client-side storage usually refers to a number
of different APIs that allow web sites to store data on a local machine; these are Web Storage (sometimes referred to
as Local Storage), IndexedDB, Web SQL Database, and FileSystem. They ultimately promise one thing: persistent
storage between accesses to a web site. Before you get excited and start preparing to save all your game data here, it is
important to understand what each API provides, the limitations, the pros and cons, and the availability. Two very good
articles that explain all of this very well are at and .
What is important is how these APIs are potentially useful for games. Web Storage allows the setting of key/value
pairs on a wide range of devices, but has limited storage capacity and requires data to be stored as strings. At the other
end of scale, file access via the Filesystem API allows applications to request persistent storage much larger than
the limitations of Web Storage with the ability to save and load binary content, but is less widely supported across
browsers. If you have asset data that makes sense to be cached by one of these APIs, then it may potentially save you
loading time.
Ideally a game would be able use client-side storage to save all static asset data so that it can be accessed quickly
without server requests, even while offline, but the ability to do this across all browsers is not consistent and at the
time of writing it is difficult to write a generic storage library that would be able to utilize one of the APIs depending
on what is available. For example, if you wanted to store binary data for quick access, then it would be possible
via “Blobs” for IndexedDB, Web SQL Database, and FileSystem API, but would require data to be base64-encoded
as plain text for Web Storage. The amount of storage available and the cost of processing this data would differ
depending on which API was used; for example, Web Storage is synchronous and will block during loading, unlike the
others, which are asynchronous. If you are happy to acknowledge that only users of browsers that support a given API
would have the performance improvements, then client-side storage may still be useful for your game.
One thing client-side storage is potentially useful for across all available APIs is the storing and loading of small
bits of non-critical data, such as player preferences or storing temporary data such as save game information if the
game gets temporarily disconnected from the cloud. If storing this data locally means that HTTP requests are made less
frequently or at not all, then this can certainly speed up loading and saving for your game. In the long term, client-side
storage is essential in being able to provide offline solutions to HTML5 games. If your game only partially depends
on being able to connect to online services, then players should be able to play it without having a persistent Internet
connection. Client-side storage solutions will be able to provide locally cached game assets and temporary storage
mechanisms for player data that can be synchronized with the cloud when the player is able to get back online.
Memory Caching
Having loaded an asset from an HTTP request, cache, or client-side storage, the game then has the opportunity to
process the asset appropriately. If the asset is in JSON form, then at this point you might typically parse the data and
convert it to the object format. Once parsed, the JSON is no longer needed and can be de-referenced for the garbage
collector to clean up. This technique helps the application minimize its memory footprint by avoiding duplicating the
data representation of an object in memory. If, however, the game frequently requests common assets in this way, the
cost of reprocessing assets, even from local cache, can accumulate. By holding a reference to commonly requested
assets, the game can avoid making a request entirely at the cost of caching the data in memory. The trade-off between
loading speed and memory usage should be measured per asset to find out which common assets would benefit from
this approach.
An example of such an asset might be the contents of a menu screen. During typical gameplay, the game may
choose to unload the processed data to save memory for game data, but to have a responsive menu, it may choose
to process the compressed representation because it is faster than requesting the asset again. Another case where
this is convenient is when two different assets request a shared dependency independently of each other, such as
a texture used by two different models. If assets are referred to in a key (in this example, the path to an asset, such
Search WWH ::

Custom Search