Cut the Rope, as ported to the web by Pixel Lab.

Om Nom is a lovable little monster, a character who can keep people playing “Cut the Rope” for hours under the simple premise of trying to satisfy his sweet tooth.

But behind the scenes, the game by ZeptoLab is anything but basic. Swinging ropes, floating bubbles, a subtle realism and other complexities require an underlying physics engine different from any other in the world of video games.

That was one of the challenges for the team at Pixel Lab, the Seattle-area development shop tapped to port the original iOS version of Cut the Rope to the web in partnership with Microsoft’s Internet Explorer team. At one point in the process, in fact, it looked like they might be forced to actually cut the rope on the whole project.

Ultimately they produced a browser-based version of the game that lives up to the original. Cut the Rope is available for free here, working in a variety of browsers, thanks to its use of HTML5. It offers exclusive levels to IE9 users, and special features including the ability to pin Om Nom to the Windows 7 taskbar.

Apart from becoming masters at playing Cut the Rope, the Pixel Lab team learned a lot about the potential and limitations of HTML5 and JavaScript. Challenges included making the game run quickly enough on older hardware, and inconsistencies in the way some browsers deal with audio — which led to a difficult decision to use Flash audio in some browsers other than Internet Explorer.

Their experience will become even more relevant as Microsoft gears up for the release of Windows 8, starting with a consumer preview later this month — include a new Windows Store and a focus on PC apps that use those fundamental technologies of the web.

Their biggest takeaway: “Nobody should have any concerns about making a bet on HTML5,” says Robby Ingebretsen, Pixel Lab founder and creative director. “In general, for 95 percent of the cases, it’s definitely up to the task.”

Apart from the technical challenges, they had to keep the project under wraps leading up to its unveiling at the Consumer Electronics Show in January, where Microsoft showcased the game in an arcade-style cabinet on the show floor.

“It’s actually kind of hard to hide it from your kids, at least with mine,” says Joel Fillmore, a Pixel Lab senior software engineer. “They were as excited as anyone for the game to be done so they could play it.”

Robby Ingebretsen and Joel Fillmore of Pixel Lab

So how did Pixel Lab get it done, and what did they learn? Here are excerpts from our recent conversation with Ingebretsen and Fillmore, including some deep technical details from the project.

How did you end up creating an HTML5 version of Cut the Rope?

Ingebretsen: About a year ago, we did a pool game called Agent 008 Ball. We wanted to get our feet wet in HTML5. We were really excited about the possibilities. We had some friends at Microsoft, and they were launching IE9 at the time, and we convinced them to let us try to write a game.

We ended up writing this pool game and had a ton of fun with it. That game ended up getting a lot of attention. It surprised people that you could do that with HTML5. It bent the browser in a way that people didn’t expect. …

Microsoft had the relationship with ZeptoLab. They pitched us on Cut the Rope. We were booked. I was saying no to every project at the time, and we just made it happen, because we knew that it was going to be a blast.

We were a little nervous going into it. It’s a different physics engine than in any other game. I was nervous that we wouldn’t be able to pull it off. We wrote the contract so that we had a milestone that was literally just about rendering the ropes and breaking the candy and getting the sprites to render.

We hit this moment in that milestone where we were about ready to call it a day. We were hitting 60 frames per second, but we’d get on older hardware, and it would just plummet immediately. We traced it back (using a profiling tool in IE9) and we got some help from the Microsoft guys, and after that it just lit up.

What was the challenge you ran into? 

Fillmore: There are two phases every time you draw a frame for the game. There’s the update phase, which is where you do all the physics calculations to determine the state of the ropes. The ropes are really complicated in that each rope is composed of multiple segments. For each one you have to run the physics engine across it to calculate how it moves. Gravity is a factor there, and the interaction between other game elements. So there’s quite a bit of computation that goes into the physics calculations.

First you do the update, and then you do the draw. Those are the two phases that go into each frame that gets rendered. This particular problem was during the update phase. That’s where it’s primarily JavaScript executing to run the physics engine and calculate all the different positions.

The JavaScript compilers and interpreters (in web browsers) are getting really good. Pretty fast. But they don’t have quite as much time as a traditional compiler to optimize the code. Traditionally compilers can do what they call “inline,” where it can take a function and rather than calling into itself multiple times, they can take that logic and put it right where it needs to be so it runs really fast.

One of the exclusive levels in the IE9 version of the game.

It’s hard for a JavaScript just-in-time compiler to do that because it just doesn’t have the time to optimize the same way a static compiler does. We took some of that work that a compiler with more time to optimize might do and we did that work for the compiler. We took pieces of logic and moved them into the right place so it would run really fast. And then we unwound that recursion — this idea of a function calling into itself — into an iterative method where it runs sequentially. That’s how we really got the speed.

Ingebretsen: The sound bite version of that is that you have to write JavaScript like you’re writing JavaScript. Most languages that are compiled, you write with an eye toward a certain set of principles, like not rewriting the same code more than once. JavaScript, because of its nature, you have to bend your understanding of how you write code just a little bit. You have to write JavaScript for JavaScript.

You’ve also created a version for Windows 8. What do you think about the use of HTML5 and JavaScript for PC apps, and what did you learn?

Fillmore: I think if anything we learned that it’s possible. One of the biggest compliments that I appreciated about the game is that it felt like the native version of the game. I think that has been challenging in the past, and we’re starting to see the point where HTML5 apps can feel like native apps.

If you’re asking what’s going to be different about JavaScript apps in Windows 8, hopefully they don’t feel different than native apps. Hopefully you get the same sort of smoothness, the same sort of feel that you would with a native app.

But why would you want to make a PC app in HTML5 and JavaScript, as opposed to a native app?

Ingebretsen: JavaScript and HTML5 are inherently collaborative. It’s easy to pull in scripts from other places. Even the language itself is inherently collaborative. Beyond that, there’s just massive community support for this language. It’s just everywhere. Also, it’s a skill set that a lot of people have, and it’s a good learning language in that you can do a lot early as you’re learning it, compared to Objective-C. The barrier to entry with something like the iPhone is huge.

Fillmore: There’s this feeling that you can reuse what you learn as a web developer to develop for platforms like Win8. I’ve developed in a lot of different languages over my career. C++ and other languages as well. The fact that you can now author apps for Win8 in JavaScript feels like you’ve leveraged all that learning and work you’ve done for the web. You get to take advantage of all these libraries that people have created, and you can really focus on one environment, and that works on the web and works on Win8.

Ingebretsen: There’s a big appetite for this, clearly. There’s PhoneGap. There’s other platforms that are trying to let people do this. Hugely popular, people love them. And it’s for that same reason. People have this skill set and they want to figure out how to use it in other places.

What were your biggest takeaways from this whole process?

Ingebretsen: Nobody should have any concerns about making a bet on HTML5. That’s my biggest takeaway. (In the past) there was this huge UI surge, whether it was Flash or Objective C or Silverlight, and I think there was the potential to be concerned that now we’re settling or something. It’s not settling. … There might be times when, for whatever reason, you might need to be closer to the metal. Maybe closer to drivers or devices, or whatever. But in general, for 95 percent of the cases, it’s definitely up to the task.

Fillmore: There’s a lot of debate right now in the community about whether Javascript can go forward as a viable language for the web. I think originally a lot of people had the same doubts. But when you get an order or two orders of magnitude faster, that removes a lot of concerns for people. When they get this type of performance out of a game … I think it makes people reevaluate what’s possible.

Where is this headed from here?

Ingebretsen: There’s this huge potential with HTML5. Right now we’re still working with the raw pieces. Canvas is a relatively low-level API compared with something you might have in Flash or Silverlight. But because we’ve as a community created these low-level pieces, I think there’s a big opportunity for people to build the bigger pieces on top of that.

I think a year out, two years out, you’re going to have these incredibly rich UI platforms built on top of canvas and html where you’re getting both the ease of development as well as the speed and the quality of experience that you have in silverlight or flash. It’s ripe for people to come in there and start building those frameworks.

Related Links

Comments

  • http://twitter.com/ggoodale Grant Goodale

    Great article!  Joel’s point on the collaborative nature of game development in HTML5 is particularly good – traditionally game development (speaking from an outsider’s perspective) seems to have been much more insular and shrouded in secrecy, whereas web development has a strong history of open source and collective effort.  Great to see the two worlds meet.

    Oh, and great work on Cut the Rope!  Thanks for dev blogging it, too.

  • http://twitter.com/toddhooper Todd Hooper

    I think it’s a very well executed and interesting HTML tech demo for desktop browsers, but in terms of game performance on a phone, it is not ready for prime time. I tried this demo on several phones when it came out – iPhone 4S, Droid Charge and a Meizu M9 and even with the minimal amount of animation present, it’s slow to load, laggy and not fun to play on the first two, and won’t play at all on the Chinese phone. Conversely, native games perform great on all of those phones.

    Cut the Rope started life as a mobile game, not a desktop browser game. Lot of companies create viable games demos of HTML5 running in desktop browsers, but the same demos do not run well or at all on phones, because of limited resources and less capable browser technology. Popular animation and physics heavy games are a poor choice for HTML  technology in my opinion. HTML5 is interesting for corporate apps, and less demanding games like Grant’s excellent WordSquared board game and the like, but saying it’s ready for 95% of games is just hype.

    I talk to top mobile game developers every week, and I’m not aware of any with HTML5/JS games ranking in the top 50 on any mobile platform. Game devs tend to investigate it, hit the wall quickly, and stick to native development or something ‘closer to the metal’. A good example is the lackluster HTML5 games in the new Facebook iOS app – they aren’t exactly storming the charts.

    Beyond developer preferences, now that the app store paradigm has taken hold, it’s going to be hard, if not impossible, to change both consumer and corporate behavior to an open web paradigm. If Apple, Google, the handset manufacturer and the carrier don’t get a cut of app revenue, why do people think they are going to promote or enable it? It’s obviously in Microsoft’s interest because they have lost critical mass on their native development environment, but they are no longer the market leader in the mobile space.

Job Listings on GeekWork