In Firefox, a build that fixes flash-related loading problems has gone live. There were also loading issues with the game on IOS devices but the build has fixed that. It has added basic support for touch events.
You can play it at www.cuttherope.ie. At the Pixel Lab, Monday was a big day because we had a wonderful opportunity to develop the HTML5 version of Cut the Rope for ZeptoLab. Monday also happened to be the launch. Feedback has also been very positive and it’s especially amazing to see people getting so excited about what can be done with standards-based code.
Needing Flash only Partially True
Some people have noticed that the game seems to need Flash, but that is only partially true. Quite frankly it will be more accurate to say that for some browsers, the game will fall back to flash.
Certainly, the game has received quite a bit of criticism for overusing Flash in an HTML5 game. We didn’t mean to be quite so aggressive about this but we are. We’re trying to make the game as super fun for people as possible and this is how the flash decision came about.
We’re going to tell you how we ended up with a flash in the HTML5 game. We’re also going to tell you a little about HTML5 audio. First, we’ll start off with a little bit about sound in HTML5.
There is only one standards-based way of getting sound into the browser – that is the <audiotag. It’s a good addition to the spec, and for most audio, it works well in virtually all browsers.
The sound effects are a bit different. Do you know how short, time-critical sounds can tax your soundcard? Not every browser does a good job in that situation, and in fact, new standards are being proposed so as to tackle the more complicated kind of audio. So while the future looks good, the present sees us with the <audiotag for all HTML5 audio.
For Cut the Rope, our development goal was to be 100% HTML5 and everyone was committed to this right from the start. For the game, we built a sound library according to the single HTML5 solution we had – the audio tag.
The sound wasn’t too good from the start but we had luck in IE. As we went through different implementation strategies we found these oddities in virtually every other browser. We tried all sorts of things such as making use of different encoding strategies, but nothing seemed to fix the issues.
You’ll find lots of discussions on HTML5 games and audio issues. We’ve had these issues with other HTML5 apps and I think that lots of people are looking at these APIs for a long-term solution. The common solution would be to rely on something such as Flash or Silverlight as an audio fallback.
When all is said and done, we just wanted the game to be excellent for as many people as possible, regardless of the browser they use.
