Why is there Flash in the HTML5 version of Cut the Rope?

Monday was a big day Pixel Lab. We had the incredible opportunity of developing the HTML5 version of Cut the Rope for ZeptoLab (the brainiac creators of the game) and Monday was the launch. Overall, the feedback has been incredibly positive. It’s been cool to see people get excited about what you can do with standards-based code in a modern browser.

A handful of people (CNET, here) have noticed that the game appears to require Flash. That’s partially true. The more accurate statement would be: the game will fallback to Flash for audio in some browsers. We’re a little more aggressive about this than we meant to be (more below). More importantly, the Flash decision came about because we were trying to make the game more fun for as many people as possible. Here’s the “behind the scenes” on how we ended up with Flash in an HTML5 game (and a little about HTML5 audio along the way).

HTML5 Audio

First a little bit about sound in HTML5. Right now, there is only one way standards-based way of getting sound into the browser: the <audio tag. It’s the sound-only equivalent of the video tag. It is, of course, a great addition to the spec, and for most audio—like podcasts and music—it works great in just about every browser.

Sound effects, on the other hand, are a little different. As you can imagine, short, repetitive, time-critical sounds like you find in a game can tax your soundcard in a different way and, frankly, not every browser does a good job in that situation. In fact, the requirements are different enough that there are new standards being proposed to handle this more complex kind of audio. Those standards are still emerging. So, while the future is promising, the present leaves us with a single option: we’re stuck with the <audio tag for any kind of HTML5 audio be it podcasts or sound effects.

HTML5 Standards in Cut the Rope

Our development goal for the Cut the Rope was to be 100% HTML5 and everyone (us, Microsoft, ZeptoLab) was really committed to this from day one. So, naturally, we built an sound library for the game based on the single HTML5 solution we had available to us: that audio tag.

Unfortunately, the sound was quirky from the beginning. We had great luck in IE (that’s true, not a plug), but as we cycled through different implementation strategies we found quirks in just about every other browser. We tried: recycling audio elements, instantiating audio elements on each play, using audio “sprites” (where we combine sounds into fewer audio files and use offsets to play the sound effects) and using different encoding strategies but nothing reliably fixed the issues.

I don’t think this is news. If you look around, you’ll find numerous discussions about HTML5 games and audio issues (here’s one, here’s another). We’ve had similar issues with other HTML5 apps and my impression is that a lot of people are looking to these forthcoming APIs for a long term solution.

The Conflict

Here’s where the story gets interesting. As we got closer to launch, we realized that the overall experience was really impaired by the unreliable audio. The common solution would be to rely on something else (Flash, Silverlight, etc.) as an audio fallback. Just about every sound library on the web does this, but that conflicted with our goal for a purely standards-based game.

To make matters worse, our fallback criteria were complex. We were up against browser quirks and bugs, not just feature support. In other words, even if a browser supported HTML5 audio we weren’t guaranteed that it would reliably handle the complex sound requirements of the game.

The easy thing would have been to do nothing. The most common side effect would be that audio stops working right around the beginning of the second level. Frankly, Internet Explorer (only coincidentally the sponsor for the project) was the only reliable browser so doing nothing could have been seen as a win for them. To their credit, they didn’t want to do that.

Everyone agreed that we wanted the game to be great in every browser. Microsoft and ZeptoLab were resolute on this point. We were too. Here’s where I think we made the right decision: after days of attempting to get our library working in all browsers, we decided to enable Flash audio for browsers where we had seen audio issues. The only browser where we had seen consistent and low-latency audio in every case was IE. That meant making Flash a fallback option for every other browser.

This may seem a little aggressive, but it had three desirable implications: First, it meant everybody would get audio (the thing that mattered most). Second, it let us stay 100% HTML5 in IE which was, understandably, an important goal for Microsoft. Third, it drastically reduced our testing surface for audio (which we knew to be flaky and quirky and so require a lot of testing).

With that decision, we also took a dependency on the very capable SoundManager2 for our sound effects, relying on their more thoroughly tested Flash implementation. (Not sure if they know that…thanks guys!!)

Loading Issues

We wanted the logic to work like this: if you’re in IE use HTML5 audio, otherwise use Flash… unless Flash isn’t available and then go back to HTML5. This seemed like it would give the most people the best experience. We almost got that right, but after launching we realized that SoundManager2 has a convenient feature that will aggressively force it to use Flash in browsers that don’t have <audio support for .mp3. It’s a cool feature and perfect for podcasters or musicians who rely on .mp3 (and probably aren’t aware that it’s not always supported). It’s not great for us where want to fallback to HTML5 if Flash isn’t available. We didn’t intend to use that feature, but it’s enabled by default. We accidentally left it on.

The result: if a user comes to the site in an HTML5 browser that doesn’t support .mp3 (mostly Firefox which only supports .ogg) then the library will force Flash audio. So, in Firefox we inadvertently ended up with a hard dependency on Flash. This, understandably, was frustrating to Firefox users. The good news is that we’ve fixed that check and will deploy a build with the fix in (hopefully) the next 48 hours.

Try it Yourself

If you’re curious about the audio bugs, you can force the game to use HTML5 audio (no flash) with this link: http://www.cuttherope.ie/?html5audio=true

The bugs are quirky and not everyone will experience them. In fact, at multiple points during development we thought we had solved the audio bugs only to be greeted by another failure hours or days later. You might need to play a couple of levels before the issues show up… or they may not show up at all.

To the credit of SoundManager2, some of the audio issues seemed to get better after we moved to their library (even in HTML5), but we had a beta team of 200-300 people testing the game and the failures were common enough that we still felt it was important to use the fallback. In fact, we would have had to explicitly disable Flash in SoundManager2 and we thought that seemed purely ideological or could even appear nefarious. The truth is that the Flash decision just the opposite: we wanted the game to be great for as many people as possible, regardless of which browser they were using.


Published

Discussion

Previous