Saving Data

Sooner or later a game must save data, and the developer must decide where to store it: remotely or locally.

Remotely

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.
• Leaderboards
  • Games can have multiple leaderboards and scores are submitted to the server for storage and ranking.
• Badges
  • Games can award badges to users depending on specific game events, and these badges are sent to the server for storage.

Locally

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.
• FileSystem
  • 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.

Security

Vulnerabilities in your site can expose private information to third parties. Attackers do not even need to break into your systems to compromise somebody else's confidential information. For example, if you present unfiltered user generated content on your page (like comments for example) attackers can insert their own JavaScript code as part of that content to be executed locally by whoever looks at it. This can potentially expose private information or even generate credit card payments without user intervention. The list of known vulnerabilities grows every year and we recommend the developers stay aware of at least the most critical ones.

In order to avoid some of the most common vulnerabilities modern browsers will enforce some limits in what JavaScript can do. For example JavaScript code on one window does not have access to data on another window unless it actually opened it, in which case a reference to the new window is available at creation time.

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.

Cheating

Another kind of security issue relates to protecting your game from cheating. Browsers have embedded debuggers that allow anyone to stop the execution of JavaScript code at any time and analyze and modify both data and code. All browsers also provide extensive logging functionality for every request your code generates, and they record everything sent or received. Similar issues exist for traditional PC games, but the browser makes it much easier for the user to understand what the game code is doing.

Tools like the extension Greasemonkey for Firefox make it trivial for users to customize and modify the functionality or visual properties of a given page. JavaScript obfuscation will only help marginally. Essentially, information provided to your servers by browser requests cannot be trusted because it can be tracked and edited at source by the users. Server side checks are required for everything claimed by code executing on the browser, to try to detect cheating behaviour. Crowdsourcing methods to detect or report cheating may prove useful for your game.

We've implemented the following solutions:

• Inaccessible JavaScript code.
  • The plugin can run the JavaScript game code on an internal JavaScript engine, inaccessible to the rest of the browser. The game can still communicate with the browser and web page if required, but code in the browser is unable to inspect or request data from code running in the plugin.
• 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.

Mobile Devices

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.

To compensate for some of the shortcomings of mobile browsers, Turbulenz is developing a system to allow packaging of games developed with the Turbulenz SDK into native apps for mobile platforms. The system uses an embedded JavaScript engine and native implementations for all the required browser APIs that may be missing in the stock browser. In this way, developers can write game code that runs in the browser on desktops and laptops, and as a packaged app on mobile devices. As support for HTML5 in mobile browsers improves, no code changes will be required to run that same game directly from the web, as is possible today with traditional PCs.

Conclusion

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