Joel Webber on Porting Angry Birds to HTML5
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.
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.
"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 (dvcs.w3.org/hg/audio/raw-file/tip/webaudio/spec...) is the right API for games."
A seldom used Fallback? Is that claim made on the basis that IE is the most dominant browser? I ask because in both the latest version of Firefox and Chrome, the Flash player is still used for audio... IE9 seems to run using HTML5 audio, but I couldn't test it as easily as the others. It could be using Flash too, but I'll give it (and this post) the benefit of the doubt.
So this is at best, proof that even the world's most talented, experienced and well equipped HTML5 developers can't get it to work right -- and can't even tell when it does.
For even more fun, try the HD version on Chrome on a Mac ... enjoy the 5 frames per second goodness of it all.
Good lord. HTML5 is an absolute mess. I hate to knock it... I want to like it as much as the next zealot. But it really, truly sucks really, really bad.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015