《Cut The Rope》 HTML 5版背后的开发故事
译者注：Cut the Rope 是一款人见人爱的小游戏。有一个开发团队将它改造成了HTML5版本。想看看他们在改造过程中的经验之谈吗？那就看下面由开发人员自己写的文章吧~
启示
Cut the Rope 是一款人见人爱的小游戏。所以我们有了个点子，即通过使用HTML5将这款游戏放到网上以便让更多的人能接触到它。
为了做到这一点，微软的IE团队和ZeptoLab团队（游戏的开发者）以及Pixel Lab的专家们合作以便将Cut the Rope 的网络版本实现。最终效果要能将游戏毫不失真地翻译成网络版本，并且能展示出HTML5的强大功能：画布提供的绘图、基于浏览器的音频和视频、CSS3风格以及WOFF字体的个性。
如果你想玩一下Cut the Rope 的HTML5版本，就去下面这个网址吧：www.cuttherope.ie.
我们觉得HTML5版本的游戏让网络更有趣了，同时，它也展示了IE的上一个版本因支持开放标准而显示出的长处。因此，我们想要分享一些开发 Cut the Rope 过程中的技术细节，以便帮助构建你自己的HTML5站点，并最终为Windows 8 Store做准备！
在IE9中作为一个HTML5应用来运行，从原始的iOS源码改写而来。从Objective-C到 JavaScript
在将Cut the Rope应用到一个新平台上的时候，我们希望我们保留了这个游戏的独特的物理特性、动作以及风格。所以，在开始的时候，我们想要改写iOS版本（而不是重写）。我们仔细分析了用Objective-C写成的原始版本，发现工程量很大，并且很复杂。iOS版本包含大约15，000行代码（不包括库！）代码中最复杂的部分是动作、动画以及绘图引擎。它们本身就很复杂，使事情变得更为复杂的是这三块之间耦合度很高，并经过了大量优化。
这是个令人生畏的工作：要将这些代码在浏览器上实现，而又不丧失原先的独特个性以及很高的质量。为了完成这个工作，我们赌上了Javascript。
在过去，Javascript一直被人看做是速度很慢的语言。坦白讲，这种说法在最初的确是对的。老的Javascript引擎是为处理简单的“脚本”（scripting）类型的工作设计的（如它的名字所示）。然而，在现在，Javascript引擎已经经过大量优化了。整合进just-in-time等功能以后，Javascript执行速度已经可以接近底层代码执行速度了。
除此以外，我们知道使用Javascript编程不同于——并且需要的思维方式也不同于——用编译型语言编程。当我们将这个游戏从Objective-C改写过来的时候，我们知道应该充分利用Javascript编程的不同以及优点。
一个明显的例子是在Javascript中缺少structs。Structs是相关属性的轻量级的聚合。使用Javascript对象来聚合一系列属性是很容易的，但是这和使用一个合适的struct是很不同的。第一个不同是一旦structs被赋值给一个变量或则传递到一个函数的时候，它都会被复制。因此，一个使用如Objective-C这样的编译型语言编写的函数可以修改以参数形式传过来的struct的值，而又不改变原来调用函数中的值。即使是在同一个函数中，将一个不同的值赋给struct也会将值复制一遍。而Javascript对象，是通过引用传递的。所以一个函数修改了一个对象参数的时候，原调用函数也能看到这个变化。
一个用来模仿structs的简单的方式是每当将Javascript对象作为赋值对象或者参数传递的对象时都创建一个副本对象。在底层语言（native languages）中，使用structs的开销是很小的。但在Javascript中创建一个对象则会有很大开销，因此我们要非常小心，减少创建对象的次数。特别是在赋值的时候，我们尽可能地复制单个属性，而不是创建一整个新的对象实体。
另一个例子是Objective – C代码库面向对象的本质。与传统的基于对象的继承不同，JavaScript提供了基于原型属性（Prototype property）的继承。这是对基于对象的继承的一个高度简化的形式，与传统的Objective – C这样面向对象的语言不兼容。幸运的是，有各种各样的类库，可以帮助你写的面向对象编程（OOP）风格的JavaScript代码，我们使用的类库是一个非常简单的由John Ressig写的。 （需要注意的是，ECMAScript5，最新版本的JavaScript的规范，也提供了对一些类的支持，但我们选择不使用它，因为我们对该版本的语言不熟悉，而我们的开发进度非常紧张）。
除了将代码从Objective-C改到Javascript，我们还需要将图像代码从OpenGL改到HTML5的Canvas API。总体上说，这一切都进行地很顺利。Canvas是一个很快的渲染表面，特别是在一个API由硬件加速的浏览器中（比如IE9）。
一个使用帆布API完成的aliased lines来画绳子的例子。令人惊讶地是，我们遇到了好几个地方，都是Canvas比在移动版本Cut the Rope中使用的OpenGL ES提供了更多功能的。一个例子是画anti-alias lines。在使用OpenGL画anti-aliased lines的时候，需要将一条线镶嵌到一个三角形地带中，并且将末端的浑浊部分褪色以完成透明化。而在HTML5的canvas中，anti-aliasing lines的绘制是由line API自动完成的。这意味着我们实际上需要从OpenGL版本中去掉一些代码。将OpenGL代码中的三角形顶点数组解约掉可以提供更好性能。
最终，我们有几乎15，000行代码在浏览器中执行（它已经被最小化了，所以如果你在浏览器中查看源代码的时候，你会看到少得多的代码）。考虑到这么多代码带来的复杂性，Denis Morozov（ZeptoLab开发部门的总监，the Director of Development at ZeptoLab）在开始的时候问了一个问题：HTML5能给我们我们所需要的速度和性能吗？
为了回答这个问题，我们创建了一个早期的“性能”里程碑，在这里，我们集中精力去得到游戏运行时难度最高部分的最小版本。也就是说，我们想要看一下绳子看起来是什么样子的，以及我们是否能在浏览器中处理复杂的物理引擎。
Performance性能
项目开始以后三个星期，我们最终有了物理和绘图引擎的基本部分，以及一个简单的用于启动动画的计时器。现在，我们可以在游戏场景中呈现出一些绳索，一颗星星，以及一个Om Nom sprite。不错的进步！第四周的时候，我们加入了一些基本的和鼠标的互动，这样，我们就能真正开始玩游戏了。我们在开发的过程中一直都在测试性能，并且希望ZeptoLab的团队能够给我们一些反馈。
当我们把这些代码和ZeptoLab分享的时候，他们对这些代码在浏览器中的性能表现感到惊喜（尤其是游戏的速度和平滑度）。说句实话，我们一直都提着一口气呢。我们希望Javascript能快点，因为物理计算非常复杂，并且有实时性要求。这是一个很好的例子，证明了人们过去认为Javascript很慢的观点实际上是错的。最新的Javascript引擎是非常快的。
在这个项目中，我们在IE9中预览了游戏。当你加载了游戏的时候，IE9的Chakra JavaScript引擎在一个后台线程中将代码进行了预编译——就像一个编译器编译Objective-C 或者 C++一样。然后，它实时将编译过的代码（字节码）发送给游戏线程去执行。执行速度几乎和本地执行速度一样。令人惊讶的是，这样的性能是来自于Javascript引擎，我们不需要在代码中做任何特殊处理。
项目早期帧率检测结果（注意帧率上限是60FPS）我们在Javascript上打的赌成功了，因此，我们将注意力转向了硬件和浏览器。由于IE的硬件加速堆栈以及我们在 Disney Tron和其他一些HTML5站点上积累的经验，我们对于游戏在测试机器上的完美表现毫不担心。我们很轻易地达到了上限60 FPS（帧/每秒）。但是，我们想要确认游戏在其他硬件和其他浏览器上也能表现得很好。下面是我们经过一些初步测试后所看到的结果。
根据测试数据，我们将30 FPS（帧/每秒）设置为最小阈值。当浏览器速度低于这个阈值的时候，我们将会通知用户。他们仍然可以玩这个游戏，但是我们会通知他们在游戏中他们可能会感觉到一些迟缓现象。这确保了这个游戏能支持不同硬件和软件，并且提供给玩家我们所能提供的最好体验。
我们想要指出两件事情。第一件事，这个游戏的现有版本在桌面PC机和Mac机上使用鼠标玩时效果是最好的。我们还没有加入对触屏输入的只支持，但在未来的版本中，我们会考虑这一点。
第二件事，现有的Chrome版本（version 16）有一些已经为大家所知的和媒体播放相关的问题，使得Cut the Rope中的声音飘忽不定。我们进行了深入调研，试图用不同格式（包括WebM）重新编码媒体文件，但是没有找到一个合适的格
补充：web前端 , HTML 5 ,
