Cut the Rope now in HTML5

Cut the rope was a game originally built for iPhone and Android by ZeptoLab and it’s gone on to sell 70 million copies, the good news is that it has been ported to HTML5 by PixelLabs, ZentoLab and the Internet Explorer team. It works in Chrome, Safari, Internet Explorer 9 and Opera.

Play Cut the rope Read the developers guide

The game was ported from Objective-C to JavaScript, which must have been a huge challenge given the fact Objective-C and JavaScript are very different beasts.

Objective-C is an object-oriented programming language and as such has inheritance and classes where as JavaScript is a dynamic scripting language. You can create ‘class like’ objects in JavaScript using prototypes but, It’s harder to get native like performance out of JavaScript. The game is proof, however, that with a little bit of creative thinking, modern JavaScript engines can deliver the goods.

In the article that accompanies the game, the developers talk about the mind-set switch required to move from Objective-C to JavaScript and pointed out two areas where a different approach had to be taken to get the game running smoothly.


In the Objective-C application there were numerous instances where a procedure would call itself again and again passing a new object into each successively deeper call. This didn’t work well for JavaScript and so they changed the code to be iterative, for those not familiar with the differences, I’ve written a little example of a recursive and an iterative function that performs the same task. Notice that the top function calls itself repeatedly until it has the answer.

document.write('<p>Recurvive:' + recursive(5) + '</p>');
document.write('<p>Iterative:' + iterative(5) + '</p>')

function recursive(x) {
    if (x >= 10) return x;
    return recursive(x + 1);

function iterative(y)
    if (y >=10) return y;
    while (y < 10)
    return y;

Using the IE9 Developer tools you can see that the recursive function (on the left) is called 6 times where as the iterative version (on the right) is called just once. The the case of cut the rope the iterative approach performed better.



Memory Allocation

As JavaScript doesn’t have structs or classes it’s common to use prototypes as an alternative. The game developers soon realised that taking this approach used more memory as creating an object in JavaScript is much more expensive. Rather than creating copies of objects  whenever possible the developers tried to copy individual properties and avoided creating entirely new object instances.

The Tools

As well as giving some insight into the development process the team also talk about the tools they used to build the application. I’ve listed them all below, I’m particularly interested in giving the sound manager a spin:

Comments (2)

  1. Rob Ashton says:

    "The game is proof, however, that with a little bit of creative thinking, modern JavaScript engines can deliver the goods"

    No it's not – getting a game like this working on a desktop PC or really high end mobile device with any sort of hardware acceleration for the expensive task of drawing onto the canvas is not rocket science – employing a few of basic tricks to make sure JS doesn't choke on basic performance aside.

    Reproducing something that should for all intents and purposes run quite effectively on a decade old desktop PC onto a platform that requires the latest of modern mobile hardware (or a reasonable desktop PC) and then talking about how amazingly it performs misses the point of why working in this environment can be a positive thing.

    This kind of promotion is harmful to the debate on whether we use HTML5/etc for our apps, as it hides the valid reasons for choosing the technology in a kool-aid-smothered 'look at the shinies we have' party rather than a "We've got the ability to easily deploy applications across a number of devices with not-too-much-extra-effort" discussion, and makes it harder for proponents of the technology to sensibly discuss the pros and cons without meeting vehement "You're just using it because it's cool" arguments.

    I actually *do* like this technology stack for development, as it is a wonderful way to deploy games to a large number of uses across nearly all devices in a standard manner – a large reach is good – especially when not under the control of a rigidly enforced app-store policy. In order to do these a LOT of compromises will have to be made (or at least a very sensible progressive enhancement model).

    Performance is NOT something to be bragged about, it is STILL something that has to be carefully worked around (far more so than if you were working in a native environment), and saying otherwise is a lie.

  2. thebeebs says:

    In the article I talk about the compromises that the development team had to make to port from native to JavaScript.

    The game works and is playable even with hardware acceleration switched off and in browsers that don't support H/A but support HTML5. I'm talking more about modern JavaCript engines, which can run on older devices… not hardware acceleration per se.

    I think the game is a good example of how you can squeeze performance out of JavaScript and make it run across various different devices, including older devices.