Optimal Asset Loading - HTML5 Game Development Insights - page 21

For a live server, the urlPrefix will be something like " http://asset.hostserver.com/game/staticmax/ " . This
example shows how it may work for a text-based shader, but this technique could be applied to other types of assets. It
is also worth noting that this example doesn't handle the many different response codes that are possible during asset
loading, such as 404s, 500s, etc. It is assumed that this code will be part of a much more complex asset handling and
automatic retry system. Figure 2-3 shows an example of how the process may play out: loading and running the game,
loading the latest mapping table, requesting a shader that is sent from the server, and finally, requesting a shader
that ends up being resolved by the browser cache. For a more complete example of this, see the Request Handler and
Shader Manager classes in the open source Turbulenz Engine ( https://github.com/turbulenz/turbulenz_engine ) .
Figure 2-3. An example of the communication process between a server and the client when using a mapping table.
Game code and mapping table data served with short cache times provide the ability to request static assets served with
long cache times that take advantage of HTTP caching behaviours