InfoQ

InfoQ

InfoQ

En | 中文 | 日本語 | Br

592,113 Apr unique visitors

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Joel Webber on Porting Angry Birds to HTML5

Posted by Abel Avram on Jan 10, 2012

Sections
Development
Topics
HTML5 ,
HTML ,
Rich Internet Apps ,
Web Development ,
Markup Languages ,
Java ,
GarbageCollection ,
Languages ,
Programming ,
Porting ,
Chrome ,
Game

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.

  • This article is part of a featured topic series on Java

Related Sponsor

VMware vFabric SQLFire - Test drive the data management system with memory speed, horizontal scalability and a familiar SQL interface

1 comment

Watch Thread Reply

HTML5 Audio... by Clinton Begin Posted

  1. Back to top

    HTML5 Audio...

    by Clinton Begin

    The misinformation and absolute shocking blindness to the inadequacy of HTML5 is incredible. I won't even go into my whole rant... but I'll focus on this one sad and inaccurate claim:

    "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.
    </audio>

    Reply