Game Development Reference
In-Depth Information
web games today would, at worst, simply stop working as soon as an internet connection failed, and, at
best, they would stop sending data to your server and saving player data. When your player refreshes the
page that the game is on, they'll just see a blank page and all their hard work achieved while offline will
have been lost. That probably won't make your players very happy, and unhappy players are not ideal.
There are a few solutions available today that can help solve these issues. The first is the application
cache, which allows you to use a cache manifest to declare particular assets (like HTML, CSS, images,
and JavaScript) that you would like the browser to cache for offline use. Not only that, the browser uses
the cached versions of the files when online to speed up the loading process.
Another technique that you can use is to store a player's game data locally and periodically sync it with the
game server. Normally you wouldn't be able to store enough data in the browser to achieve this (like with
cookies), but with Local Storage and IndexedDB you can now store many megabytes of data in a
structured way.
You can also add functionality to your game so that it is alerted when a player's internet connection goes
offline. The
navigator.onLine
property allows you to use JavaScript to see if your player is currently online
or not. You can also use the offline and online events to trigger automatic behavior in your game when a
change in connection occurs, like stopping all WebSockets communication and caching player data locally
until the connection is back.
Immersive gameplay with the FullScreen API
Something that prevents current games on the web from feeling immersive is that they look like they're just
tiny boxes embedded into another web site. Why do they feel like that? Well, because they
are
just tiny
boxes embedded into other web sites. The odd five-minute puzzle game during your lunch hour might feel
OK in a tiny box surrounded by browser UI and other distractions, but a first-person shooter or driving
game certainly wouldn't.
Fortunately, the FullScreen API has arrived to solve this problem. It allows you to make any DOM element
fill the player's entire screen, something normally only considered for videos. Using this in a game can
make the difference between five minutes of relative fun and hours of immersive delight.
Tame the mouse with the Mouse Lock API
An issue related to input in games is that of misbehaving cursors, where the mouse is used to rotate a
player around a fixed point (like moving the viewpoint in a 3D first-person shooter) or rotating the player in
a top-down 2D game.
In both of these situations, the mouse cursor is visible at all times, which is generally annoying and ruins
the experience. However, the most debilitating problem is that all movement stops when the mouse cursor
leaves the browser window. This same behavior occurs in full-screen mode when the mouse cursor hits
the edge of the screen. It's a horribly simple problem for a player that completely ruins the experience.
The good news is that the Mouse Lock API has been created to solve this problem, and it just landed in
experimental builds of Firefox Nightly and will soon land in Chrome (it is likely that the support will be in
public builds of these browsers by the time you read this). Its sole purpose is to tame the mouse by hiding
