本节书摘来自异步社区《HTML5完美游戏开发》一书中的第1章，第1.2节,作者： 【白】Egor Kuryanovich , 等 更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.2 为什么要关注Open Web Game

Open Web Game是基于Open Web技术开发的原生游戏，而Open Web技术是指HTML5、CSS和JavaScript。Open Web Game凝结了这些技术的主要特性，所以与其一个个学习这些技术，我更愿意在Open Web Game这个庞大的题目中学习，因为可以综合这些技术练习。因此，我们要对Open Web Game心存感激。

Open Web Game开发技术魅力在于，它跟网站或网页应用开发（有人说这两个定义是相同的，不过，这里我还是把它们分开了）用到的技术是一样的。在Internet诞生的时候，这些技术就已经非常盛行了，而且事实证明，在各种技术此起彼伏的时候，它们是最可靠、最稳定的。

1.2.1 入门很简单
用Open Web技术开发游戏几乎没有任何障碍。首先，Open Web技术是完全免费的；其次，Open Web Game开发所需要的工具都有免费版或者只需极少的费用。简而言之，用Open Web技术开发游戏只需极少的投入。对于那些用指定开发环境（如Flash IDE）的开发人员来说，这是一个很大的亮点，因为开发者通常需要向这些开发环境购买一些技术支持和相关的开发工具。

1.2.2 优秀的技术文档
除了“零障碍”入门，良好的编写风格和免费的技术文档，都可以帮助开发者学习这些技术的每一个细节。像Mozilla Developer Netword网站在几年前就已经开始提供这种服务了。另外，还有大量其他的网站和个人博客也会发布相关的信息。

**1.2.3 庞大而友好的社区
**有这样一个流行的社区，它由一群持续关注Web的发展趋势、分享经验的开发人员和设计人员组成，他们竭力为大家提供更多的精品技术文章。这样的社区随处可见：从Facebook的HTML5小组，到Tiwtter的HTML5小组，到专门的技术论坛（如SitePoint），再到IRC上实时聊天室。另外，现在irc.freenode.net上新开了一个Open Web Game频道，期待你的加入。

1.2.4 一次编写，一劳永逸
从更专业的角度看，Open Web技术开发游戏的魅力在于，它是一个“一次编写，一劳永逸”的技术。现在可能还不完全如此，因为各个应用平台上的使用规范还是有些细微的差异。但Open Web是一个原生的跨平台技术，除了少许的非指定平台专用代码外，已经在各种不同的操作系统和浏览器中应用。

可以肯定的一点，如果一个平台支持游戏所需的HTML5和JavaScript API，那么游戏运行状况应该可以跟开发者预想的一样。当然不同的硬件配置对性能会有不同的影响，不过这也是其他技术同样无法避免的问题。

1.2.5 代码未编译及开源
一些拥有个人专利的开发者在转向Open Web技术时，会感觉很不习惯，因为代码没有经过任何编译，开源的给所有用户查看。在浏览器的页面中，单击鼠标右键，可以轻松地查看页面的源代码和素材——Open Web Game亦是如此。

这种现象同时也是Open Web概念和强大的核心所在，无法撼动。但是很多从其他平台转行过来的开发人员试图改变这个特性。数字版权加密保护技术（digital rights Management，DRM）试图以一种非专利方式管理Web，也可以说是对代码和素材进行编译。这样其他人就无法那么轻易地获取这些资源了，不过这未必能实现。

译者注

由于数字化信息的特点决定了必须有另一种独特的技术，来加强保护这些数字化的音视频节目内容的版权，该技术就是数字版权加密保护技术DRM。
在我看来，这个文化上的冲突，是其他平台（如手机、Console和PC）上转行过来的开发者一直担忧的主要问题。传统的游戏开发理念是保护知识产权，使代码和素材无法被获取。有人尝试过在Open Web中隐藏代码和素材，但最终毫无收获（我尚未看到DRM提出一个真正的可行的方案）。我能理解他们的想法以及他们的目的。不幸的是，没有浏览器会支持他们的观点，所以对Open Web Game不适合。

译者注

Console是指游戏主机，如Sony的PSP及微软的Xbox等都叫做Console。
向开发者证明Web是个可行的开发平台，并证明它对开放资源和代码可以进行保护，不至于被疯狂盗用，失去控制，是很重要的。我坚信，历史告诉我们盗用或复制都不会发生，我坚信，Web作为游戏开发平台所带来的利益会远远大于这些细小的不足。换句话说，你见过多少盗用或复制的网站，会比原始网站要好？
**
1.2.6 全民参与**
还有一点让我很吃惊，即没有任何一个组织来管理Web开发技术和平台。这对从专利背景转过来的开发者来说是个很陌生的概念，因为当他们想要添加或变更什么东西时，找不到对应的窗口。

Web开发技术是由一系列规范来定义的。这些规范分别由万维网（World Wide Web，W3C）或者网页超文本应用技术工作组（Web Hypertext Application Technology Working Group，WHATWG）来管理。这两个组织由各种不同的股东组成，从浏览器开发商到科技技术公司，再到普通的 Web开发者，任何人都可以成为组织中的一员。这就是为什么说是全民参与了。如果需要添加或变更说明什么，只需要加入讨论，就能畅所欲言。如果你想参与讨论Open Web Game技术，请加入W3C游戏社区组织。

1.2.7 拥有世界上最大的用户群
Web开发游戏的优点还在于Web拥有世界上最大的用户群。通过Web技术，可以接触到69亿的Web用户。当然我承认并不是每个人都会把浏览器升级到最新，所以不可能接触到所有的用户。但我想说的是，Web用户的数量是非常惊人的，而且每天都有越来越多的用户连接到Web上。即便只计算Firefox火狐浏览器的用户，也有上亿（好多啊）。Facebook用户呢？有超过8亿的用户。

如何发布游戏给广大的用户玩，是另外一个问题。我会在本章的后面章节中进行简单地说明。

1.2.8 Open Web Game现状
在过去的几年中，浏览器平台和Open Web Game开发技术取得了突飞猛进的进步。这与APP商店和社交网络中不断增涨的Open Web Game是分不开的，而且这个数量每天都在增加。此外，一些大型的游戏公司也开始对Open Web Game产生兴趣，使得游戏的质量也呈明显改善趋势。但是，我觉得在这些改善中最重要的一点是Flash将不再支持移动设备和Web，而HTML5和JavaScript是一个永远不会因为兼容性问题被抛弃的平台——Open Web Game应运而生。

1.2.9 现有游戏浏览器技术
我觉得Web领域中最吸引人的除了现有的技术，还有即将到来的新兴技术，比如GamePad API、鼠标锁定API和全屏API等。这些简易的技术会帮助我们摒弃“Web游戏只不过是网页中嵌入的小盒子”的观念。有了连接游戏机控制器，就有了全屏运行HTML元素的能力，Open Web Game也会变得像Console和PC一样，带来更诱人的用户体验。

接下来，我举例说明一些现有的和即将到来的新兴技术，建议你好好看看，从中你会发现入门其实很简单。值得一提的是，在这些技术更新时，浏览器会相应地很快做出更新来支持这些技术。我经常去When Can I Use网站关注这些更新信息（http://caniuse.com）。

1.2.10 canvas和SVG实现2D图形
因为图形输出是大多数游戏的核心组件之一，所以创建和管理2D图形的能力对浏览器来说很重要。这样一来，HTML5 canvas和可变矢量图形（Scalable Vector Graphics，SVG）就应运而生了。

译者注

可缩放矢量图形是基于可扩展标记语言（XML），用于描述二维矢量图形的一种图形格式。SVG由W3C制定，是一个开放标准。另外，SVG还是Static Var Generator（静止无功发生器）的简称。
HTML5 canvas（通常简称“canvas”）是一个JavaScript API，与同名的HTML元素相对应，可以在浏览器中创建和编辑位图图形。它的优点是快速，且创建像素级图像而不影响运行速度。它的缺点是性能在不同的平台上不尽相同，并且没有内置的动画功能。

另外一个2D解决方案是SVG，使用文件物体模型（Document Object Model，DOM）来创建和管理矢量图形。它的优点是易于读取（图形都用DOM元素表示），并且有内置的动画功能，另外因为是矢量图形，所以图形可以轻松缩放以适应不同的屏幕大小。它的缺点是没有像canvas那样流行，对完美的像素级操作处理得不是很好。

1.2.11 WebGL实现3D图形
如果需要在游戏中添加一些3D图形，那就需要使用到WebGL JavaScript API（简称WebGL）。WebGL基于OpenGL ES2.0，包含了一些炫酷效果所需的所有功能。

WebGL的优点是基于硬件加速（非常快），可以创建非常复杂的视觉效果。它的缺点是，学习起来非常复杂，而且不支持IE浏览器。不过通过第三方框架，比如three.js，可以大大降低学习的难度。

1.2.12 requestAnimationFrame实现高性能动画
大部分的Open Web Game中的动画都是通过我们常说的循环，重复不断地更新屏幕实现显示的。当更新速度足够快时，图像的更新就会非常平滑，形成动画。

到目前为止，实现动画最简单的方法还是用JavaScript的setTimeOut和setInterval。需要注意的是，这两种方法会使代码持续运行，带来一系列的性能问题。另外，当游戏页面处在非活动状态或浏览器最小化的时候，这两个方法不会停止运行，使得动画实现起来很不理想。

为了解决这个问题，HTML5引入了requestAnimationFrame方法，目的是将动画循环管理功能指派给浏览器。这样就尽可能以最佳的方式来实现动画，同时大幅度提升游戏性能，防止在非活动页面或者最小化浏览器中持续运行动画。通过这个方法可以大幅度降低动画循环的速度，甚至是停止播放。这对延长手机电池使用寿命等有非常好的效果。

1.2.13 HTML5 音频和音频数据处理API
对于大部分游戏来说，另外一个基本的元素是音频。截止到目前，在Web中实现某些音频效果还存在困难，因此很多时候都选择使用Flash。HTML5 audio元素的到来为我们解决了这个问题。它可以在浏览器中无插件播放音频。

HTML5 audio元素还是存在一些局限性的，比如它的目的只是播放单个音频文件，如游戏中的背景音乐，而不适合做音频效果，特别是那些快节奏、一次播放多个音频文件的效果。

为了解决这个问题，Mozilla和Chrome分别引入了Audio Data API和Web Audio API，提供了更多详细的音频功能。通过这些API，我们可以用JavaScript创建声音，可在运行时编辑音频，同时播放多个音频通道，还可以获取音频在实时播放时的数据。

遗憾的是，音频数据API解决方案还没有一个统一的标准。因此，在使用时，对于Mozilla和Chrome内核的浏览器要做些细微的调整。我希望在不久的将来能有一个统一的标准规范音频数据API。

1.2.14 WebSocket实现多人实时游戏
提到多人游戏，你想到的可能是实时发送Ajax请求（带来无法忍受的延迟）及Flash。但这两种方法都不是很理想。不过那个年代将一去不复返了。从2011年起，WebSocket进入了各大浏览器（是的，包括IE10），实现了浏览器与服务器之间的双向实时通信。

为什么双向实时通信对游戏那么重要呢？实时通信从字面上来说，就是数据可以在用户浏览器中实时地流入流出。它的一个显著的优势是节省带宽。不像Ajax需要定时发送需求来检查新的数据。WebSocket会始终保持连接，在有需求时，立即将数据添加到客户端和服务器端。这个优势在每几毫秒更新一次的快节奏游戏中展现得淋漓尽致。除此之外，WebSocket的双向通信特性，也表示数据可以从服务器端到客户端，以及从客户端到服务器端即时传送。

1.2.15 数据本地存储IndexedDB/ Local Storage和其他API
很多游戏都可以将玩家数据保存到玩家的电脑上，以便以后可以读取这些数据继续游戏（比如游戏存档或图形缓存等）。过去，唯一的方法是将数据保存到服务器上，要忍受重新加载的延时，或者使用cookies之类的方法，且只能保存很少的数据。

幸运的是，现在已经有很多不同的方法来解决这个问题。最常用的是IndexedDB、LocalStorage和各种File和FileSystem API。前两个方法可以在用户浏览器中存储大量结构化数据，Indexed DB方法甚至还可以存储文件。文件（File）和文件系统（FileSystem）API使游戏可以通过JS读取用户操作系统中的文件，可以保存和读取更大的数据。这一点是其他任何一种方法都无法比拟的。

1.2.16 通过应用缓存离线玩游戏
在Web中创建游戏的想法是不错的，但是如果玩家想在离线状态玩游戏呢？或者说，当玩家正在玩EPIC的游戏时，网络突然掉线了，会这么样呢？从目前的Open Web Game来看，最坏的情况是掉线后游戏立即停止。最好的情况是向服务器端发送数据，保存完当前的游戏数据。在未发现新技术时，掉线的玩家刷新页面后，游戏会继续运行，不过玩家们看到的将会是一个空白的页面，而且他们在离线状态下辛辛苦苦玩的游戏进度全部丢失。玩家对此会很不爽。让玩家不爽是很糟糕的。

译者注

EPIC指EPIC公司（Epic Games）。Epic Games是全球领先的数字游戏及图形交互技术开发商，1991年创立于美国。著名电脑游戏虚幻（Unreal）和《虚幻竞技场（Unreal Tournament）》系列是Epic Games的成名作。
现在已经有一些方法可以帮我们解决这个问题了。首先是使用缓存。通过缓存文件保存一些特定的元素（如HTML、CSS、图片和JavaScript），即一些你希望浏览器缓存下来供离线使用的元素。不仅如此，通过这些缓存文件，可以加快游戏的加载过程。

另外一个方法是将玩家游戏数据存储到本地电脑中，然后周期性地与服务器同步。过去浏览器无法存储足够的数据来实现这个功能，但是当Local Storage和IndexedDB出现后，我们可以有条不紊地存储上百兆的数据。

另外还可以在游戏中添加一个提示功能，当网络断开时提示玩家。JavaScript中的navigator.online属性可以用来检测用户网络是否处在连线状态。还可以用offline和online事件，在网络连接发生变化时，自动触发游戏的一些行为，比如停止所有的WebSocket通信，将用户数据缓存在本地电脑中，直到网络连接恢复。

1.2.17 全屏API让游戏身临其境
现在的网页游戏看起来都像是嵌入在页面中的小盒子，这使游戏很难让人感觉到身临其境。为什么会这样呢？因为它实际上就是嵌入在页面中的小盒子。午饭时间花个五六分钟，玩玩简单的益智游戏，虽然是在小盒子里，周围是浏览器UI和其他让人分心的东西，但感觉也还好。不过，如果是玩第一角色的射击游戏或赛车游戏，那感觉就不怎么样了。

很幸运的是，现在我有FullScreen全屏API来解决这个问题。它可以将任何一个DOM元素填满用户的整个屏幕，而不仅仅是视频。它可以带来与几分钟的益智游戏完全不同的游戏体验，让你身临其境地玩上几个小时。

1.2.18 鼠标锁定API让鼠标变听话
在玩家用鼠标围着一个固定点旋转（比如3D第一角色射击游戏）或者在2D俯视游戏中用鼠标控制方向时，经常会遇到的问题是鼠标不听使唤，且鼠标一直都是可见的，这时会很烦人，会毁掉游戏体验。让游戏体验变得更糟糕的是，鼠标离开浏览器窗口时，所有的运动都会停止。在全屏模式下，当用户的鼠标移动至屏幕边缘时，也会出现同样的问题。对于用户来说，这个简单的问题很可恶，会完完全全毁掉游戏体验。

好消息是，Mouse Lock鼠标锁定API已经诞生了。它专门用来解决这个问题。不过，现在只有试行版的Firefox Nightly支持这个API，不久它会登录Chrome（在读到此文时，这两个浏览器的正式版应该都已经支持了这个API）。这个API唯一的目的就是隐藏鼠标，并将其锁定在一个固定的位置，使它无法到达屏幕边缘。就是说，以前以浏览器左上角为基准点的坐标系，将被替代为以鼠标与锁定点相对距离决定。

1.2.19 GamePad API实现console般游戏体验
Web游戏中另外一个与输入相关的改善当属GamePad API了。对于玩家来说，鼠标和键盘将不再是游戏过程中唯一的输入方案。有了GamePad我们可以通过JavaScript调用各种游戏手柄，甚至包括一些console的控制器，比如Xbox360和PS3（但是要有第三方驱动）！

译者注

微软Xbox 360是唯一一款具备定时功能的游戏机，家长们可轻松设定相应游戏时间，同时也能对孩子们所玩、所观看的内容加以限制。PlayStation 3简称PS3，是索尼电脑娱乐所开发的家用游戏机，也是该公司推出的第三款电视游戏机。
和Mouse Lock API一样，目前只有试行版的FireFox Nightly和Chrome支持GamePad API，而且用起来非常简单好用（同样，在你读到本文时，正式版的Firefox和Chrome应该已经支持GamePad API了）。结合着FullScreen API，GamePad API可以让Open Web Game的游戏体验从网页里面的小游戏完全蜕变为桌面游戏和Console游戏。

1.2.20 BrowserID服务识别用户
正如iOS提供的OpenFeint和Apple Game Center服务，Web游戏需要有一个公开可靠的方法来识别用户。BrowserID是Mozilla对这个问题的解决方法。它允许用户用自己的电子邮箱登录游戏而不需要密码。

译者注

OpenFeint是一个基于SNS的平台，为iOS和andriod系统提供在线游戏竞技的技术平台游戏中有很多与用户相关的功能，比如好友列表、积分榜、聊天或多人游戏功能，第一步要做的是识别用户。
1.2.21 创建WebRT一样的本地OS应用
Mozilla更为显著的一个特性是集成了Web实时运行环境（Web run-time，WebRT），这是首创。用户可以将游戏安装到自己的本地操作系统（Windows、Mac和现在流行的Android）中，然后向其他OS一样，有一个发布后的应用图标。

WebRT是以应用为中心的用户代理（app-centric user agent）形式运行游戏的，与Firefox中以浏览器为中心的用户代理（browser-centric user agent）不同，其使用的是单独的用户配置和系统进程运行。

WebRT分出单独的进程运行游戏，同时移除浏览器的UI（User Interface，用户界面），使游戏用户体验更加有亲和力。这与点击Mac的dock工具中的图标在本地窗口中运行游戏有异曲同工之妙。用户丝毫没有在浏览器中玩游戏的感觉。

对于一个开发者来说，这一切看起来有点虚幻。WebRT使Web游戏不再只是一个漂亮的页面，而是一个真正的应用，即拥有自己的用户体验的应用。用我的话来讲，这将是Web游戏从5分钟的益智游戏到拥有Console游戏版用户体验的专业级游戏转变过程的转折点、里程碑。

1.2.22 未来的路还很长
前面所提到的技术只是真正的Open Web Game时代中的Open Web技术的冰山一角。Mozilla和其他的厂商也在努力为我们带来更多这样的API和服务，帮我们把Web打造成更好的游戏环境。

1.2.23 现有的出色的Open Web Game
尽管Open Web Game开发是个相对新兴的技术，但是现在已经创造了很多相当出色的游戏。下面简单地列举其中的几个。

1．宝石迷阵
大约在2011年年底，PopCap发布了非常火爆的“宝石迷阵”（Bejeweled）游戏的HTML5版（如图1-1所示）。它使用WebGL技术进行图像加速。如果不支持WebGl的话，会用HTML5 canvas取代。

译者注

Popcap Games是世界领先的休闲游戏的开发商和发行商，在2000年由John Vechey、Brian Fiete 和Jason Kapalka共同建立，总部位于美国的西雅图。

https://yqfile.alicdn.com/ace8d9b3df42b09423406dd59992c9f009da00f4.png" >

2．愤怒的小鸟
愤怒的小鸟可以说是现在最流行的游戏了。在今年年初的时候，Revio公司发布了HTML5版的愤怒的小鸟（如图1-2所示），使用WebGL进行图像加速。

译者注

Rovio娱乐是一家颠覆行业的娱乐媒体公司，成功打造了全球闻名的愤怒的小鸟形象。

3．机器人也是人
一个新颖独特的游戏总会在当前千篇一律、相互模仿、复制的游戏中鹤立鸡群。“机器人也是人”（Robots Are People Too，如图1-3所示）就是这样一个游戏。这个游戏需要两个人相互合作才能完成。游戏中运用了新颖的分屏技术，同时用canvas进行图像渲染。

4．跑路
Firefox4在2011年初正式发布。作为发布的一部分，跑路（Runfield）（如图1-4所示）展示了浏览器的一些特性。其中HTML5 canvas进行图像渲染，HTML5 audio元素处理声音。

https://yqfile.alicdn.com/369423f0c107626bb027e02764b874990d86bf9a.png" >

5．TF2 WebGL示例
严格来讲，Brandon Jones创作的这个TF2示例（如图1-5所示）算不上一个真正的游戏。它是一个教学范例，用来展示Value’s Source引擎是如何用高性能的WebGL来渲染图像的。
译者注
Source引擎是由Valve电子软件公司开发的3D绘图引擎。卡法师是为了它制作的，用了大量的3D设置，并且对其他的游戏开发者开放授权。
图像说明文字

https://yqfile.alicdn.com/bee90070b1a134956b77cad94d2d8a81de95d2b4.png" >

1.2.24 现有的游戏发布和盈利方式
在本章开始的时候，我提到过发布游戏并通过游戏盈利，是Web成为一个可行的游戏平台的必要条件。很高兴，现在已经有很多这样的平台和服务了，未来会有更多。下面我简单地列举其中的几个。

1．Mozilla APP实验室
目前，大多数的应用平台都是封闭的系统，不会在所有平台或者设备上释放它们的游戏或应用。这势必威胁到了用户的自由。Mozilla相信建立一个开放的系统能够让目前的应用开发平台得到改善，开发者在发布自己的游戏时有更多的选择。现在这个项目叫做Mozilla实验室。
Mozilla应用商店的支付方式是PayPal。用户要做的只是在商店里设置好价格，其他的工作应用商店会自动完成。当人们开始购买游戏时，开发者的PayPal账户会自定接收付款。未来，开发者可以在自己的网站或者其他的应用商店上发布游戏并出售，即开发者可以选择自己的支付方式。

2．Chrome Web商店
谷歌的APP应用平台是Chrome网上商店，虽然也是封闭的，但Chrome网上商店的应用可以在出谷歌Chrome之外的浏览器中运行。但目前这些应用无法在其他浏览器中通过网上商店直接安装。

Chrome网上商店使用Google账户作为支付方式，而且每笔交易收取5%的提成。这比iOS平台要少多了。

3．Facebook
Facebook拥有超过8亿的用户，所以其进入应用发布行列将发挥举足轻重的作用。任何用户都可以安装Facebook提供的应用，通过新增的绘图功能，用户可以构建自己在社区里的朋友关系图。

Facebook使用了一个叫做Facebook信用值的系统作为应用和游戏支付方式。这也是很多常用的一些标准支付方式（比如信用卡和PayPal）的一种有效代理模式。

4．iOS APP商店
iOS APP商店虽然也是封闭的平台，但是对于一些通过PhoneGap等技术开发的、面向iOS的游戏来说，其是个非常实际的选择。

其他的很多公司也在开拓新的应用平台理念，来帮助开发者发布和出售自己的游戏。在未来的几年里，究竟哪个方案最为流行呢？我们拭目以待吧。

1.2.25 Open Web Game的缺点
现在，写一篇介绍Open Web Game开发优势的文章并不是件难事，就像本章一样。不过平心而论，我相信列举一些Web作为游戏开发平台的缺点也很重要（不过确实没多少）。

首先，不同的平台和设备所表现出的性能各不相同。这个跟硬件有关系。这个缺点公然违反了“一次编写，一劳永逸”的原则。因此，针对游戏，寻找一个合适的平台很重要。要确保这个平台所支持的功能级别，可以让游戏给用户带来娱乐性和可玩性体验。

其次，不同的浏览器对各种游戏相关的开发技术支持状况不一致。比如，GamePad API只有Firefox和Chrome才会支持。目前还没听说其他浏览器是否要应用这个API。Mouse Lock API和其他的一些API也是相同的状况。另外的例子就是Internet Explorer不支持WebGL，短期内应该也不会支持，至少要等到停止SilverLight开发之后。

最后一个问题，对于部分开发人员来说，Web Game开发的开放特性是不可行的。这可能源于法律要求。正如我在前面提到的，改变Web游戏开发的开放特性去适应DRM要求，或编译代码去适应所有的浏览器，是不可能实现的。如果开放特性真的不适合你，那么在考虑用 Web 作为开放平台之前，请先考虑好这个平台的利与弊。

其他平台也存在适应性问题。比如Flash开放将不再支持移动设备，其他的技术比如Google的本地客户端不支持其他浏览器。没有一个平台是完美无缺的，没有一个平台会兼容所有的问题。重点是不要对所有的平台一视同仁，要个别对待，这样才能找到合适的平台。

1.2.26 未来发展方向

虽然现在是Open Web Game开发兴盛的时代，但我希望大家清楚，Open Web Game不是魔术棒，其无法完全解决其他平台遇到的问题。实际上，Web不可能成为适用所有游戏和开发者的平台。道理很简单：并不是说有了Open Web Game开发平台，大家就都要用它。

除此之外，Open Web Game开发是值得庆祝的平台。它每天都在完善，不过要发生几个重大的标志性事件来记录其完善的过程。

首先，各个浏览器需要支持一些Open Web Game必须的开发技术，比如为了阻止平台之战，大家蜂拥而上，为Chrome Web商店开发仅支持WebKit的游戏。这部分需要着重改善的就是音频数据API、WebGL、GamePad API和Mouse Lock API。

其次，需要有更多的游戏发布和盈利方案。我们需要跨浏览器的解决方案，而且这些方案本身就可以发布游戏，比如Mozilla实验室。毕竟，如果无法在每个浏览器和平台上安装游戏，那Web Game就没什么意义了。

再次，我们要提供简单易用的游戏交易系统，而且要包括原始计量单位，未来还可以在游戏里交易。PayPal和Google账户就挺好，但是现在是网络时代，开发者应该可以选择自己的支付方式，应该拥有网络允许范围的自由选择权。

我们要有更多的文档，分享更多的源码来帮助初学者和自由开发者更好的入门。Open Web Game社区的魅力在于它可以不断地分享技术和代码来帮助其他人，就像Web开发者分享代码和技术共同学习，构建网站一样。在这个问题上，我们还需要更多文档。这不是关于如何做一个好玩的游戏，而更多的是关于如何用Web Game开发作为一种职业，以及如何更有效地把游戏发布出去。

最后，我们需要一个像愤怒的小鸟这样的Open Web Game的成功案例。我们需要有力地证明Open Web是可以作为游戏开发平台的，而且它可以为我们带来收入。我想这将预示着大量大型游戏开发商的蜂拥而至的同时带来大量投资的资金。

可能你有所鼓舞，并帮助推动Open Web Game的发展，使其成为一个平稳可行的游戏开发平台。