Joel Webber, co-creator of the Google Web Toolkit, held the session Angry Birds on HTML5 at GOTO Aarhus 2011, recorded and published by InfoQ. We interviewed Webber to find out more details on porting the popular game Angry Birds to Google Chrome and HTML 5.
InfoQ: Please provide some technical details on porting Angry Birds to HTML5.
JW: Most of the broad technical aspects are covered in the GOTO presentation. In a nutshell, the game is written in Java, then cross-compiled to Javascript using the Google Web Toolkit. During the porting process, we wrote a little library called PlayN that allowed the game developers to work entirely in Java (debugging directly on the JVM, which is significantly more powerful than having to debug in the browser). The PlayN library also allows the same code to be cross-compiled to run under Flash and Android, though Rovio is not currently using this functionality.
InfoQ: What HTML5 features did you use?
JW: Just to be pedantic, this list includes things from a number of specs that aren't technically "HTML5", but are often referred to as such. The short list is: WebGL, Canvas, CSS3 (especially affine transforms), LocalStorage, <audio> / WebAudio. For rendering, there are two modes: WebGL and DOM. In WebGL mode, there is simply one large <canvas> element on the page. In DOM mode, we use a separate DOM element for each object (birds, pigs, blocks, background elements, and so forth), then we use CSS3 transforms to position them efficiently. The reason for this dichotomy is that there are plenty of browsers out there that don't support WebGL yet, and we wanted to make sure the game worked on all possible browsers, not just Chrome.
For audio, we initially had to use a Flash-based fallback, because <audio> support was weak on several browsers (including Chrome). That has since been fixed, and Flash is only there as a seldom-used fallback. Ultimately, we believe WebAudio (https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html) is the right API for games.
InfoQ: How much effort did it take to port the game?
JW: It's hard to say precisely. There were three of us at Google supporting Rovio, but it was mostly 20% time (and occasional evenings and weekends). One Rovio engineer did the majority of the actual work porting the game. Others came in later to help with things like in-app payments and production issues.
InfoQ: What was the most difficult part?
JW: The game logic was pretty straightforward. We already had a working port of Box2D (the physics engine used by Angry Birds and most other 2D physics games), and writing the game in Java made it easy to manage the (somewhat large) code base. There were a few things that required extra work, though:
- Loading resources: Unlike most native apps, web apps typically load their resources on-demand so that they can start quickly. This is generally a Good Thing, but it makes app logic more complex because it's preferable to display each game screen as soon as the resources it needs are downloaded. This also means you need to be careful about how you order resource requests, so that you don't spend bandwidth on resources you don't yet need.
- Rendering across browsers: As I mention above, there is no one "best" way to render game graphics across all browsers. It took significant effort to abstract rendering and implement two very different approaches.
- Having the game run at a smooth 60 frames-per-second was a very important goal. Garbage-collection pauses made this difficult, though we were able to eliminate them in the end.
Webber offers more information on garbage collection difficulties encountered and the PlayN library and its role in debugging on the JVM in the Angry Birds on HTML5 presentation hosted by InfoQ.