Last year, Adobe’s decision to drop Flex and Flash mobile player support in favor of HTML5 took me by surprise. It forced the entire company to reconsider our game client development platform. As a startup, it was important that the technology we built today is still relevant 3-5 years from now and Flash was not looking good as a medium term platform candidate (you can read my reaction to Adobe’s announcement in my previous blog entry here). So, we collectively opted to halt production on our first title and take the time to take a deep dive into HTML5
The results of the investigation is ‘Fish Eat Fish‘, an online turn-based strategy game prototype, and 5 important lessons about developing a HTML5 game application.
Building UIs is hard
Let me be specific: building pretty UIs for all major web browsers with proper visual degradation is hard. A large part of the difficulty stem from supporting Internet Explorer, but there are enough quirks between the different web browsers to warrant test (and retesting) GUI changes on all the supported platforms. However, once we had successfully defined approaches for handling the differences, the pain becomes negligible… pending further browser version updates.
- CSS for:
- Declaring UI elements skins
- Declaring screen dimensions and layout
- HTML for breaking down the screen content into organized sections/divisions
- A common CSS file containing general CSS hacks/tricks (e.g. float clear fix)
- A common CSS file declaring application-specific UI element skins
- A screen-specific CSS file declaring the page elements layouts and dimensions
To enable strict mode, insert the following line at the appropriate scope:
For more information on strict mode, please refer to John Resig’s article on ECMAScript 5.
The game client cannot be secured – harden your server
Outside of technical know-how, there is nothing preventing the average user from debugging our HTML5 application. That, in itself, is not the problem. The issue is that those debuggers are powerful enough as to allow anyone to tweak variable values within the application. It’s one thing to tweak a value which results in the client crashing in the hacker’s browser. It’s another thing altogether when said tweak is transmitted to the server and potentially corrupt the game backend.
The best approach is to treat all potential game clients communications as originating from an alien/hostile client and harden the server accordingly.
Our experience building the prototype has really increased our confidence in building a commercial online game using HTML5. As a result, we have opted to discard our development of a Flash game client in favor of an HTML5 game client.
Click here to see the ‘Fish Eat Fish’ HTML5 game prototype. The game rules hyperlink can be found under the game’s header.