Game Development Reference
In-Depth Information
Bandwidth/network constraints
To combat bandwidth constraints, the first thing you should do is apply traditional
optimizations which web developers have been using for years: compress the content
your server sends with gzip , combine and minify JavaScript to minimize the number
of requests the browser has to make to the server, optimize your images, enable the
Keep-Alive header, serve assets from a limited number of domains, and use headers
to leverage browser caching, among other techniques.
Optimizing websites in general is a particularly detailed topic, but
this section mostly sticks to explaining optimizations specifically for
games. If you are interested in learning more about Web Performance
Optimization ( WPO ), start with these rules from Google and Yahoo!:
https://developers.google.com/speed/docs/best-
practices/rules_intro
http://developer.yahoo.com/performance/rules.html
However, complex games won't be able to rely on browser caching for user return
visits because browsers have limits on the maximum amount of memory cached
resources can consume across all websites. Your game's resources will be pushed out
of the cache as the user navigates other websites, and the cache size may be too small
for all your resources anyway. As a result, the next place to look for optimizations is
caching inside of your game in order to minimize the number of server requests that
need to be made. This can be done in three ways. First, you can store resources in
other caches. The IndexedDB API ( https://developer.mozilla.org/en-US/docs/
IndexedDB ) supports storing files, and the Web Storage API ( https://developer.
mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage#localStorage ) supports
storing strings (including JSON, so you can store exported Three.js objects). Chrome
also supports the FileSystem API ( http://www.html5rocks.com/en/tutorials/
file/filesystem/ ) which can manage a sandboxed local filesystem. Second, you
can reduce the total number of resources you need by generating some of them
on the client. For example, if you need similar textures in different colors, it might
make sense to modify those textures dynamically on the client rather than ask the
server for multiple images. Or, if you can describe the way a mesh should animate
with a system of equations, you might consider manually animating it on the client
instead of sending animation data. Third, you can make sure your code is structured
in a way that allows reusing resources instead of requesting them repeatedly. For
example, if two meshes use the same texture, you should try to load the texture once
instead of twice.
 
Search WWH ::




Custom Search