lercanidipine hydrochloride side effects

Fish Eat Fish: 5 Lessons Learnt in Building a HTML5 Online Game


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.

'Fish Eat Fish' screenshot from Firefox

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.

Don’t rely on having a Javascript debugger

While all major desktop browsers support Javascript debuggers, the same cannot be said for mobile platforms – namely the  iPhone, iPad, and the Android. For those cases, be prepared to fall back to the primitive debug method of… outputting debug text to console. Better yet, change the HTML body’s background color to signal the program state – an homage to the old PS2 debugging technique of changing the screen color by setting a PS2 GPU register. The more things change, the more they stay the same…

HTML for content organization, CSS for skinning and layout, Javascript for everything else

HTML5 is unique in that it is a combination of 3 different languages – HTML, CSS, and Javascript. Furthermore, there are multiple approaches to achieve a desired visual result. With that said, there are a limited number of ways to organize the implementation so as to minimize coupling/interdependencies. In the end, we settled on the following code organization:

  • CSS for:
    • Declaring UI elements skins
    • Declaring screen dimensions and layout
  • HTML for breaking down the screen content into organized sections/divisions
  • Javascript for everything else
The CSS for each screen is broken down into 3 CSS files:
  • 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

Use Javascript strict mode

Javascript relaxed scoping rules in combination with its ‘you can override anything’ rule makes it very easy to commit grievous coding bloopers. For example, it’s all too easy to reference an undefined variable because any variable references create a new variable reference in the global scope. Javascript 1.8 (ECMAScript 5) addresses this issue by introducing the optional strict modeStrict mode tightens the language context and improves the process of detecting common coding bloopers. Strict mode is scoped so that it can be applied only to a file or a function, for example. This allows applications to mix older Javascript code which is not compatible with strict mode with newer strict mode friendly code. Best of all, strict mode is backwards compatible with earlier Javascript versions. Browsers which support earlier versions just ignore the strict mode directive.  Be forewarned, it also disables language functionality that is poorly defined.

To enable strict mode, insert the following line at the appropriate scope:

"use strict";

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.

Conclusion

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.

, ,

About ChrisK

Chris Khoo cut his teeth on programming writing BASIC programs on a ZX Spectrum back in 1985. Since then, he's graduated to programming on the web and on nearly all the game consoles released since the mid-90's. Chris remains an active member of the software industry and is currently operating as indie developer and founder of Wappworks Studio.
Comments are closed.