HTML and CSS Reference
In-Depth Information
HTTP Caching Example
Since the caching works per URL, you will need to serve your asset files in a way that can take advantage of these headers.
One approach is to uniquely name each file and set the expires header/max-age to be as long as possible. This will give
you a unique URL for each version of the asset file, allowing you to control the headers individually. The unique name
could be a hash based on the file contents, which can be done automatically as part of an offline build process. If this
hash is deterministic, the same asset used by different versions of your games can be given the same unique URL. If the
source asset changes, a new hash is generated, which can also be used to manage versioning of assets.
This approach exhibits the following behaviors:
You can host assets for different versions of your game (or different games entirely) in the
same location. This can save storage space on the server and make the process of deploying
your game more efficient as certain hashed assets may have previously been uploaded.
When a player loads a new version of your game for the first time, if the files shared between
versions are already in the local cache, no downloading is required. This speeds up the loading
time for game builds with few asset changes, reducing the impact of updating the game for
users. Updates are therefore less expensive and this encourages more frequent improvements.
Since the file requested is versioned via the unique name, changing the request URL can
update the file. This has the benefit that the file is not replaced and hence if the game needs
to roll back to using an older version of the file, only the request URL needs to change. No
additional requests are made and no files need to be re-downloaded, having rolled back
(provided the original file is still in local cache).
Offline processing tools for generating the asset files can use the unique filename to decide if
they need to rebuild a file from source. This can improve the iterative development process
and help with asset management.
Loading HTTP Cached Assets
Once a game is able to cache static assets in this way, it will need a process to be able to manage which URLs to
request. This is a case of matching the name of an asset with a given version of that asset. In this example, you can
assume that the source path for an asset can be mapped directly to the latest required version of that asset. The asset
contents can be changed, but the source path remains the same, so no code changes are required to update assets.
If the game requires a shader called shaders/debug.cgfx , it will need to know the unique hash so it can construct
the URL to request. At Turbulenz, this is done by creating a logical mapping between source path and asset filename,
and storing the information in a mapping table. A mapping table is effectively a lookup table, loaded by the game and
stored as a JavaScript object literal; see Listing 2-1.
Listing 2-1. An Example of a Mapping Table
var urlMapping = {
"shaders/debug.cgfx" : "2Hohp_autOW0WbutP_NSUw.json",
"shaders/defaultrendering.cgfx" : "4HdTZBhuheSPYHe1vmygYA.json",
"shaders/standard.cgfx" : "5Yhd75LjDeV3WEvRsKnGSQ.json"
};
Each source path represents an asset the game can refer to. Using the source path and not the source filename
avoids naming conflicts and allows you to structure your assets like a file system. If two source assets generate
identical output, the resulting hash will be the same, avoiding the duplication of asset data. This gives you some
flexibility when importing asset names from external tools such as 3D editors.
 
Search WWH ::




Custom Search