Sooner or later a game must save data, and the developer must decide where to store it: remotely or locally.
Remote storage allows data to be retrieved later from another machine or another user.
Storing data on your servers requires either an HTTP POST request or, if using WebSockets, a message to the server. In both cases the actual storage will potentially take a long time to happen depending on the amount of data. We have found upload bandwidth a tenth or less of the download bandwidth so saved data will take 10 times longer to upload than to download. Games will have to cope with that latency.
Turbulenz provides services for remote storing and retrieving of different kinds of data:
- Game state
- Games can store data associated with the current user for later retrieval. Usually for things like current level, progress within the level, visited places, etc.
- Games can have multiple leaderboards and scores are submitted to the server for storage and ranking.
- Games can award badges to users depending on specific game events, and these badges are sent to the server for storage.
Depending on the APIs available, the total amount of data that a game can store locally can vary from kilobytes to megabytes. These local storage APIs do not guarantee better performance than loading HTTP resources that are already in the cache.
Traditional methods for storing data locally were severely limited. Cookies, for example, only allowed a handful of kilobytes, and some other methods were not persistent between browsing sessions. Thankfully new APIs have appeared that support data in the order of a megabyte:
- Web Storage
- Provides a key-value store. Some implementations only support storing strings, so other data types will require serialization to JSON for example.
- Web SQL Database
- Provides an SQL relational database on the browser. Deprecated in favor of Indexed Database.
- Indexed Database
- Somewhere in between Web Storage and Web SQL Database. It provides support for storing structured data by key but with additional indices like those of relational databases.
- Provides limited access to the local file system with support for creating your own files.
To support older browsers you can use libraries like jStorage that provide a consistent storage API, implemented for different back-ends depending on browser support.
Other limitations are related to what resources can be requested from domains other than the one hosting the current page. For example, if a page from domain-a.com makes a request for resources on domain-b.com, the request will fail unless the servers answering the latter request support Cross-Origin Resource Sharing (CORS). If the browser itself does not support CORS, then JSONP can be used, but it also requires support on the server side. This limitation regarding resources in separate domains will have an effect when using a third party CDN to distribute data across the world.
We've implemented the following solutions:
- Encrypted communications between the game and the server.
- Secure HTTP connections only avoid eavesdropping by external parties, but it does not avoid monitoring by someone controlling the browser. The game can request an additional encryption layer between the game and the server.
The content of these articles applies to tablets and mobile phones as much as desktops. The main differences between mobile and desktop platforms relate mostly to the lack of the more advanced APIs on smaller devices and obviously the reduction in hardware resources the browser can make available. Namely, less memory and lower CPU and GPU power. Internet connections using 3G also have a much higher latency and lower bandwidth than those on a desktop or laptop.
These limitations often mean that smaller and / or simpler resources are required for a game running on mobile devices compared to the same game running on a desktop or laptop.
Input methods on mobile devices also require special support, touch control does not offer the same response as a mouse and a keyboard. The touch events API provides support for multi-touch events in a similar way to the mouse events but, instead of a single mouse cursor moving around, multiple points are tracked as they move across the screen. You could interpret movement on different regions of the screen as different controls: left side of the screen for translation, right side of the screen for rotation, for example.
The differences listed here represent problems for all games on mobile devices, whether or not they target HTML5 or more platform-specific APIs. However, it is often the case that browsers on mobile systems do not progress as fast as on their desktop counterparts. For example, desktop browsers supported WebGL much earlier than mobile browsers.
Hopefully this short series of articles has given readers new to HTML5 some insight into its potential. As with any platform there are some issues that must be worked around and some tradeoffs to be made, but through the development of the engine and infrastructure for the turbulenz.com game network we have demonstrated that this technology can already deliver a high quality gaming experience direct to a huge audience, with no download or install required by the end user.
With some appropriate fallback strategies, games can already target a large range of browsers, OSs and devices, from desktop to mobile. As more and more OS and application vendors adopt the standards, games written using HTML5 technology will enable high performance and a better user experience without these intermediate solutions.
In this sense, of all modern cross-platform technologies that are viable for games HTML5 is perhaps the most promising. Combined with the connectivity of the web and the appropriate server infrastructure it opens up all kinds of possibilities for creating, promoting and sharing high-quality content in ways that are not possible with traditional platforms.
Don't miss: Making the Move to HTML5 Part 1, Part 2