OK, I admit it. I was kinda mean to Seattle game developers Pixel Lab about their HTML5 Cut the Rope game. And in my teasing for their slightly obsequious Microsoft sales pitch in the video, I neglected to mention that it’s actually a very very slick production, incredibly well executed.
But they also got some extra teasing from other sites because the game needed Flash to run in browsers other than IE. On the surface this looks a little like cheating, but Pixel Lab developer Robby Ingebretsen explained his reasons.
…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.
…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 must admit, I’ve had similar problems, and Dominic Szablewski (who made game engine Impact.js) posts regularly on his blog about HTML5 audio issues.
In fact on the iPhone, HTML5 audio won’t even load unless in response to a touch event. You can really see how broken this is when you try to run Cut the Rope in Mobile Safari (although the rest of the game runs really well on my iPhone4!).
I don’t see anything wrong with falling back to Flash, especially when it enables you to use new in-browser capabilities before they’re widely implemented. My friends at Unwrong made an HTML5 game that worked in IE6, because they used FlashCanvas – a library that falls back to Flash if no native canvas support is detected. (Ironically FlashCanvas can perform better than some browsers’ native canvas implementation, but let’s not open that can of worms 
)
Here’s Robby’s full explanation : Why is there Flash in the HTML5 version of Cut the Rope [via .net]