移动应用广告现状

以上可以看到，现在移动应用广告的发展状况令人堪忧，低质量的 Banner 广告和骗取点击量的劣质广告充斥在众多普通应用之中，尤其以安卓平台为甚，广告正在侵蚀系统平台。这些本来应该是开发者或开发商盈利的应用广告由于影响用户体验以至于被很多第三方进行了“去广告化”修改。而高质量广告门槛太高，对于普通开发者基本无望。

我们都说这个世界上本没有广告，广告只是放错了地方的信息，广告最大的追求就是怎么把这个广告变成信息。而广告变成信息就是要做成精准，这就也解释了为什么人们为什么不喜欢现在的应用广告，除了很多广告本身制作粗糙外最大原因还是在于“放错”了地方。那么又是为什么“放错”了呢，因为很多广告商还在以传统互联网广告的思维做移动互联网广告，忽略了移动互联网不仅仅简单是传统互联网的延伸，它有着自己的特性：精准、位置、动态和感知性。如果没有充分利用移动互联网的这些特性（如只考虑文字匹配而忽视场景匹配）就会容易造成广告“放错”地方。

而现状是，开发者和开发商只是简单粗暴的以广告来挣钱。移动互联网本质上来说是一个信息载体和传媒平台，而一款应用的价值实现绝不仅仅是拉广告，广告应该是推荐、内容延伸，除了高质量广告 iAd 外，应该有更新颖的广告来和内容进行更好的融合，变成不是像广告的广告，这才是是未来的趋势。

因此我们认为未来移动应用广告应该有一些新模式：

考虑到移动互联网虽然处于爆发阶段，但是移动广告的发展并没有移动互联网的发展速度成正比，可以说还是比较滞后的，这也说明了移动应用广告市场潜力是巨大的。正处于高速发展的应用广告虽然迫于一些现状受到一些制约，但是新颖广告模式的探索和发展一直在持续中，未来虽然不知道具体会怎样，但是我们相信未来一定是美好的。

最近一位HTML5专家Rich Clark（作者的好朋友）为大家做了一个HTML5 APIs的简介，在文章中为大家指向了一个令人迷惑的网页（web平台：浏览器技术http://platform.html5.org/），其中包含两 个很长的专栏和小正文并提及到一些让人感到迷茫的技术，例如“window.crypto.getRandomValues”和“DOM Mutation observer”。

别担心，咱们不去管那些啦，因为有些还远远没有完成呢，在浏览器中见到它们还要等一阵子。然而，其它已经在浏览器中，或者距离您很近，或者马上就要 出现。人们可能将称之为“HTML5”，尽管它们并不是。其实，它们都属于令人激动的新兴Web技术（New Exciting Web Technology），值得每个开发者关注。

WebGL

WebGL是一种基于Web的Graphic库，由非盈利组织Khronos运营,目前结合HTML5<canvas>元素广泛应用在3D图形开发中。

学习WebGL比较困难，因为它是底层开发——它运行在GPU上面，而且它实际上是一个OpenGL的JavaScript port，是一种游戏开发者使用的已经长期建立的API集。WebGL的主要受众是哪些已经拥有丰富OpenGL经验的游戏开发者，他们可以通过 WebGL为web平台编写游戏。

好在有很多资源可以帮助您学习WebGL，这些资源不仅仅是关于游戏开发的，还有很多奇幻的图形、视觉和音乐视频等方面。作者个人比较推荐的是：

• Introduction to WebGL。http://dev.opera.com/articles/view/an-introduction-to-webgl/作者Luz Caballero，简介可以获得的各种库。
• Raw WebGL 101。http://dev.opera.com/articles/view/raw-webgl-part1-getting-started/适合那些不使用库的用户。
• Learning WebGL。http://learningwebgl.com/一个非常好的引导网站。
• WebGL 101。http://www.youtube.com/watch?v=me3BviH3nZc一个由Erik Moller制作的介绍视频（2.5小时）。
• See Emberwind。http://operasoftware.github.com/Emberwind/一个由Erik Moller做的WebGL游戏port，您可以深入Github或看代码。

WebGL目前在所有桌面浏览器（发布版和开发频道）中都支持，除了IE10（微软表示不支持）。对于移动产品来说，已经在Opera Mobile 12中发布了，最终会出现在Android，BlackBerry Playbook 2.0，Nokia N900，SonyEricsson Xpertia Android Phones等以及Firefox移动浏览器中。

SVG

SVG（Scalable Vector Graphics）已经在Opera，Firefox，Chrome中存在多年了，但是直到IE9开始支持它之后才渐渐变得主流一些它在 HTML5<Canvas>的光环下显得有点暗淡，尽管SVG和HTML5<canvas>是面向不用应用的不同工具。

Canvas2D可以迅速paint图形到屏幕上面，这一点很犀利。但是其全部功能就是paint了，没有内存来做那些（位置，顶层或其他）其他功 能。如果您需要那种book-keeping工作，就只能自己用JavaScript实现，因为Canvas2D不会把DOM保存到内存中，也正因为如此 Canvas2D速度快，十分适合第一人称射击类应用。

与Canvas2D不同，SVG在您需要保存DOM的时候就给力了。使用JavaScript，所有的Objects都可以移动并且与动画无关。您 可以试试Daniel Davis做的复古类SVG游戏Inbox Attack（http://people.opera.com/danield/svg/inbox-attack.svg）来体验一下，并且看看源代 码来了解如何完成动画效果。

因为shape和path是用Markup来描述的，所以他们可以用CSS来定型。与<canvas>不同，text在SVG中保持 text格式并且更加的灵活，更加可扩展，更加易于访问。在Canvas中，text变成了像素，就像Photoshop中的图形text。

SVG最强大的特性是它基于矢量，这样您的插图，图形和UI图标等都是矢量图了，这样无论是在50英寸的电视屏还是手机屏幕桌面上，看上去感觉都是 一样的清晰。在当今这样一个web应用无处不在的时代，SVG图形甚至可以包括媒体查询（http://my.opera.com/ODIN/blog /2009/10/12/how-media-queries-allow-you-to-optimize-svg-icons-for- several-sizes），可以是响应式的，可以根据不同的目标设备做尺寸的调整。

综上所述，在最新的桌面浏览器中SVG已经能被广泛支持了。在移动产品方面的支持总体上来说也很好，以及预期在Android 3.0版本之前原生浏览器也会支持它了。

Daniel Davis有一些SVG 介绍性的资源（http://my.opera.com/tagawa/blog/learning-svg），作者个人也推荐一本免费的电子 书：Learn SVG（http://www.learnsvg.com/book-learnsvg/），您也可以看看《SVG or Canvas？Choosing Between the Two》（http://dev.opera.com/articles/view/svg-or-canvas-choosing-between- the-two/）来了解二者的区别。

getUserMedia

不像那些被错误地称为HTML5的API，getUserMeida（在下文中简写为gUM）有个相对正当的理由：起初它是HTML5<device>元素，之后它改名了然后离开了W3C WebRTC规范集合。

gUM允许访问用户的摄像头和麦克风，本来是在WebRTC规范中在浏览器中进行P2P视频会议的，当gUM拥有了其他的用途，就离开了WebRTC。

摄像头的访问最终在Opera12安卓版，Opera桌面实验室和Google Chrome Canary里面实现了，不过Opera和Chrome都还没有实现麦克风的接入。

W3C规范依然在用，所以Opera和Webkit有不同的语法规范，这样的麻烦被一个叫做The gUM Shield（https://gist.github.com/f2ac64ed7fc467ccdfe3）的小JavaScript片段搞定了。如果 您想更深入地了解这方面请看作者的另一篇文章：It’s Curtains for Marital Strife Thanks to getUserMedia（http://html5doctor.com/getusermedia/）

当视频从设备开始流传输的时候，源数据可以被做成变成了<video>元素，如果需要的话还可以被定为到屏幕外面，然后拷贝 到<canvas>里面进行所需要的操作。Paul Neave写的《HTML5 变成玩具！》（http://neave.com/webcam/html5/）为了方便操作把流媒体数据拷贝到WebGL中。作者在.net 杂志的226话有采访他的报导（http://www.netmagazine.com/shop/magazines/april- 2012-226）。

如果想把web app的功能做得像native app，gUM需要做很多的工作。试了一下Neaver的gum和WebGL 在Opera Mobile 12上面的demo，感觉和平台独有的app一样富有响应式并且很时髦。当在浏览器产品中其功能被广泛应用的时候，作者语言会有很多基于web的QR代码 阅读者以及很多增强现实的应用。

File APIs

W3C File APIs允许JavaScript访问本地文件，其中最常用的API是FileReader，可以从Opera，FireFox，IE10平台等的预览版看到（不包括Safari）。

这一份W3C规范“为了在web应用中提供API来代表文件对象，以及编程选择和访问数据”。例如：你可以上传文件到浏览器中，并本地查找相关信息 （例如文件名，尺寸，类型）而不需要到服务器端。您也可以打开文件，操作内容，这样可以加强基于浏览器的应用的交互性，用起来更像是本地应用。

另一个常用的用途是使传统的图像上传兑换狂更具有Web2.0特色：通过允许在浏览器内部的Drag and Drop，而不是本地文件系统中改变。

您可以通过使用一个普通的<input type=”file”>开始，然后循序渐进地提高。HTML5 Drag&Drop支持特征检测，如果存在的话就使用<div>替换<input>，那就是您的drag图像目标了。当 图像被drag到目标的时候，使用File Reader API来显示一个指甲盖大小的图像。您可以看一下Remy Sharp的demo（http://html5demos.com/file-api）。

还有很多写文件和操作文件系统的规范，不过这些对目前的跨浏览器应用来说还不太够：

W3C文件API：（http://dev.opera.com/articles/view/the-w3c-file-api/）非常基础的介绍。

开发文件系统API：（http://www.html5rocks.com/en/tutorials/file/filesystem/）HTML5 Rocks文章，（仅限Chrome）。

Feature-detecting, progressive enhancement and upgrade messages（特征检测，渐进式增强和消息通知）

诚然，在没有那些奇幻的API的时候，大家总是试图使用渐进式增强和HTML语义的方法让网站照常工作。然而有时候却不能这样，例如Paul Neaver的《HTML5变成玩具》中，如果gUM和WebGL现在不存在的话，其网站不能有什么补救措施了，整个网站的核心都没了。

在这样的情况下有两种典型的惯例：要么是显示一条消息说“你的浏览器太垃圾了，塞油哪啦”或者说“你必须用Chrome6/Firefox 4/Opera10等[插入能支持你应用的浏览器]才能访问”。第一种方法又没用又粗鲁，没有建议和补救措施；第二种方法是个临时办法，因为六个月之内所 有浏览器可能都能支持你现在使用的技术了，让你在网站上留下的信息过时：例如您写的解决方案是建议使用Firefox4来访问，可是半年后用户安装着 Firefox7回来访问你的页面了，这可就真的没救了。

如果您真的不能使用渐进式增强，那么就用新型的HTML 5 Please API吧（http://api.html5please.com/）。这是Jon Neal，Divya Manian和其他几位大虾创作的。通过使用它，可以先查询caniuse.com然后返回一个最新（能支持你的新特性的）的浏览器版本列表。

如果您已经做了一个需要Canvas或WebSQL DB技术的DEMO或者网站，恐怕你已经处在一个这样的尴尬境地了：您只是在告诉访问者们他们的浏览器不咋地。但是您不能只推荐他们使用一个能支持这些特 性的浏览器来补救，例如“找个支持WebRTC性能的浏览器再来吧”，这样对于大家都没啥效果。

HTML5 Please API把开发人员的语言（和特性）翻译成用户能理解的语言（浏览器）。通过调用这个API你就可以得到一些HTML返回值来告诉访问者，或者返回一个带有 相关数据的JSON对象（包括浏览器Logo及下载介绍等信息）。这样您可以根据不同的客户来显示不同的补救信息了。

使用这种方式最令人欣慰的是：如果所有新特性在客户当前浏览器的升级版都能支持的情况下，Please API值建议访客对浏览器升级，而不是让访客单纯为了访问你这个页面而更换浏览器。效果图如下：

结束语：

正如您所看到的，大量的令人惊喜的新技术正在接踵而至，您着手研究上述某项技术的时候恐怕又要担心更新鲜的技术到来了吧。希望您开发得愉快，请记得让您所开发的应用在尽可能多的浏览器上面测试一下。

———————————————————————————————

原文作者：Bruce Lawson2012年3月19日

图片整理：Rob Winter ；HTML5阐述： Mike Brennan

原文地址：http://www.netmagazine.com/features/developers-guide-new-exciting-web-technologies

关于Bruce Lawson ：支持Opera开放标准，专注于HTML5，窗口小部件和接入性。他是一位HTML5专家，与Remy Sharp共同编写了《Introducing HTML5》。他的个人网站：http://brucelawson.co.uk/

v12（之前基于AS的TweenLite最后更新至v11）不仅给Flash带来了前所未有的动画特性，并且从现在起它也支持Javascript！木有错！你的Flash和HTML5项目将能够使用同一个工具集！同样的API，同样的用户友好度，以及同样专注于性能的强壮功能集！如果你是个Flash开发者，v12将扫清影响你适应HTML5的障碍；而如果你是个Javascript开发者，这货能助你更轻松的创作出性能卓越的高级动画！革命吧，工作流！

在深入了解v12新特性之前，让我们首先将本平台视为一个整体并看看为什么它如此值得你拥有。

超快！
性能就是一切，尤其是在处理器性能有限的移动设备上。能使动画效果丝般柔顺的引擎才会显得物有所值，而GSAP比旧的“工业标准”货在性能上至少1000%！曾经硬邦邦的抽筋动画现在爽滑了！这一切源自于无数的优化工作，以此来确保你的交互项目反应敏捷、效率卓越、柔滑润泽！来看看实际的速度对比测试吧！

超强壮！
GSAP的诸多新特性都为专业人士量身打造，其他大多数同类引擎都弱爆了：能操作颜色、贝赛尔、CSS属性、Flash滤镜、数组等等；Round数值，执行中平滑reverse()，可使用相对值，自检测并自适应getter/setter方法，可使用任何缓动公式（easing），像职业选手那样自如应对冲突动画；定义多种多样的回调函数，基于时间及帧创建动画，轻松创建动画序列（甚至包含叠加动画），repeat（重复），yoyo（溜溜球效果）等等……

兼容性！
Flash，HTML5，jQuery，Canvas，CSS，新潮浏览器，古董浏览器，RequireJS，EaselJS，移动设备等等等等——都能与GSAP和睦共处相亲相爱！用你最喜欢的开发工具，不再无止境地踩兼容性坑。JS版甚至无需繁杂的浏览器前缀和各种hack，就能在时下的主流浏览器（比IE6新）上实现各种各样的变形（缩放、倾斜、旋转、xy）。让Greensock来关心兼容性吧，您就别操心头疼了！

Javascript，AS3，还有AS2！
无需舍弃你最心爱的动画工具即可欢快地切换于Flash和JavaScript/HTML5之间！无需再跟暗淡无光的JavaScript功能和臃肿的API们耗着了，我们把动画编程的乐趣还给您！

轻量化、扩展性！
模块化、弹性化、超高效，其插件化架构允许用户以可选插件的形式使用所有功能，保证了核心引擎的密封性。TweenLite将惊天地泣鬼神的强大能量全都打包得吓死人不偿命地小（3种语言环境版本下都不超过7kb）！

独立性！
GSAP不基于诸如jQuery这样的任何第三方工具（虽然它作为选择器的话可以和jQuery相处的很恩爱），以此实现性能最大化，载入时间最小化！

高级序列！
不再受限于“下一个下一个下一个”这样的土序列，而可以任意叠加动画，Timeline套Timeline，插入断点、回调、标签、交错动画等等……。用最少的代码精确掌控动画时间，灵活地创作出表现诱人的动画。

专业无私的技术支持！
人人都有需要帮助的时候，我们会支持你。哪天你项目交付时间近在眼前了可你死活做不粗来东西的时候，来http://forums.greensock.com找寻有关GreenSock的所有答案吧。原作者积极投入身先士卒加上大批用户粉丝的无私奉献，事实证明GreenSock工具和其他那些停停走走呆滞不前甚至根本就没有支持的开源项目们相比简直碉堡了！

啥都能动！
你没看错，啥都能动！不用找支持属性的列表，任何对象的任何数值属性都可以动！而且你总能在需要时找到个插件可以对属性进行特殊加工（比如颜色、滤镜、非数值等），哪怕实在没找到，你也可以自己尝试做一个插件，总之就是有无穷的可能。

覆盖管理！
另一个动画引擎中罕见的功能，是识别冲突动画并优雅地化解它们，并且这些都由GSAP自动实现，当自动处理的结果不如你的预期时，也还有些高级选项可供使用。GSAP保护您远离那些能让其他引擎绝望的冲突。

易于上手！
框架多的是，但鲜有能完整地提供文档、教程、交互样例、详细的“新手上路”指南和专注的论坛的。你无需多天才多牛逼，有大量资源能指导你学会使用本引擎。

许可协议
完全免费，特定商业用途（转售多个客户）除外；Learn more about licensing

GreenSock Animation Platform v12 十大新特性
除了推出JavaScript版本之外，对于Flash开发者来说，最新发布的GSAP（GreenSock Animation Platform）v12的ActionScript版本还带来了大量让你兴奋不已的提升。不过如果你从未使用TweenLite和TweenMax那就别往下看了 。

此次更新的一大成果是简化了使用方式，尤其是序列和数组方面。API现在限制更少，啥都能做。现在能通过一条动画语句操作对象数组，可以向killTweensOf()传递数组，可以向Timeline的insert()或append()方法传递回调、标签、缓动和数组。有新的更简易的方法来大幅简化序列，大多数情况下完成相同的序列动画将比以前至少减少50%的代码量。许许多多的细节改良使工作变得甚至是愉悦人心了。

一如往常那样，性能始终是至高无上的。所有缓动（easing）方法都得到了进一步优化，大量的内核改进保证了执行速度无比迅速。一般来说性能是优先于文件尺寸的，除了在TweenNano上，它是以文件尺寸为最高追求的。

事实上，如果不是单纯从类型的角度做考量的话，在未来的手机游戏层面将重新凸显出两种基于用户粘着度的方式：用户的情感沉浸和基于关系链的社区交互。

早先我们解析过玩家离开游戏的相关缘由，除了游戏机制和题材方面的困惑（游戏邦注：比如游戏的可玩性不足，趋于重复式或者强迫式操作；所涉素材对于玩家而言没有新鲜感），以及在画面与声效方面不够愉悦的表现力（要知道玩家最初是基于画面和声效来识别游戏的，在未深入体验游戏机制以前，画面和声效承载着从视听的角度将游戏的表面价值拼接给玩家，并促使玩家在首次判别的情况下有浅度的认同意识，而后所扮演的是在玩家操作或者等待的进程中从视听层面继续和玩家进行交流）之外，玩家间因为游戏频度差异出现过大的进度差距或者关系链断裂失去社区交互价值也是其中需要权衡的环节。

第一个层面：基于关系链的社区交互对用户粘着度和游戏延续价值的影响

Zynga首席执行官Mark Pincus在界定社交游戏的时候以盛大鸡尾酒会的名义重新界定了游戏在交互中所扮演的具体含义，在他的描述中玩家首先会为与老朋友重会而欢愉，但更让玩家雀跃的是还能因为游戏偶遇一些值得结交的人（从朋友那获得引荐的新朋友），在他的终极想法是让玩家和玩家的朋友以及朋友的朋友在游戏中欢聚在一起（可能生活中想要所有人聚在一起并不现实，而社交游戏所呈现的在线异步交互能够实现不同的人在不同的场所和不同的时间段因为同样的游戏媒介获得类似现实欢聚一般的互动与交流）。

换句话说在弱游戏性的环境下，玩家之间彼此架设的粘着效能最终决定着游戏所能呈现的价值，Steve Meretzky在定义游戏的时候就认为做好游戏交互氛围以情感纽带才能长久留住用户，这种提法和Tony Ventrice相似，在他看来创建一个持久交互的稳定内部社区并驱动和培养用户虚拟的交互环境对游戏未来生命周期的延续性具有决定价值。或者Amy Jo Kim将这层关系说得更为直白，单个的玩家可能烦透某款游戏并从心底否定游戏的可玩性，但因为他的现实关系链好友都在游戏进程中，并且刚好其他的玩家的游戏进程需要该玩家予以配合，在这种交互框架下，持续游戏就变成了完成友谊价值的一部分。密歇根大学和巴西佩洛塔斯联邦大学的研究证实了关系链在游戏玩家的相互粘着力方面起着很好的隐性受迫力和牵制力（以受邀请的名义参与游戏的玩家比其他因为广告吸引或者偶然要素接触游戏的玩家能够在游戏中停留更久，这种用户推荐的效能在留存率上表现得相当明显，用户之间的协同性所附着的稳固用户对交互进程和游戏的依赖，驱动了游戏用户自发地粘住其他好友共同成为一个缠绕纽带）。这种协同关系不一定是好友以固定的方式结盟形式，也可能可以是密集交互的支撑架构，不管是竞争还是协作，只要他们在游戏中经常以各种形式接触，其社区依赖就可能产生。

游戏邦曾经基于这个问题探讨过如何营造好友邀请时被邀请者的荣誉感，这可能也是架构游戏虚拟社区所需要顾及的一个层面（即被邀请的玩家如何消弭刚开始时的被迫参与感，基本上所有被动受邀的玩家在起始阶段都有某种惶惑心态），而在现实生活中我们常常不会有这样的顾忌，好友之间的互相邀约基本是一件荣耀的事情，不管是家庭聚餐还是简单的小舞会都能够觉得这是被朋友重视的肯定，正如我们所即将分析的，这个时候现实生存状态和游戏间的这种协作出现了严重的脱节（如何消弭现实中兴高采烈赴宴而虚拟游戏生活中被动接受留存率听天由命补充，尽管这种类比可能拔高了作为游戏本身的意义，但如果从粘着层面考量的话，反而能够具有深度挖掘的价值），其实我们一直在重复描述的就是群体情感和社区归属感，特别是由病毒式传播所承载的好友邀约，更将形成一种独特的生态圈，因为不得不承认好友间的交互让现实纽带已经逐步延伸到虚拟网络，就有必要思考如何让游戏中的泛友谊更具互动的针对性（被虚拟邀约是荣誉吗？）。

美国罗格斯大学的社会学教授Karen Cerulo就认为尽管这些并不即时且不够严谨的数字化虚拟关系看起来不是那么关键（事实上我们前文的论述并未过度拔高游戏交互的价值，在未来，虚拟关系链的紧密程度将比现在被更为正式地呈现出来），但仍将因为玩家之间的频繁交互而被明确地定义出来。就像我们对社交（手机）游戏的私底下认同：一款社交游戏真正的生命力不在于一个用户自娱自乐是否开心，而在于该玩家是否觉得他和更多的朋友一起分享会更有意思。

甚者，不管是从Facebook或者从App Store所呈现的交互趋势来看，玩家之间的交互已经有从鸡尾酒会转向游乐场（游乐场为Zynga副总裁Bill Mooney在加州大学的表述）转化的趋势，大量ADD ME的出现使得游戏交互圈从刚开始的好友和关联纽带逐步突破为更广义的甚至更为直接的纯游戏友情。尽管这一趋势的出现让游戏市场上出现了各种顾忌，诸如社交环境的好友真诚性问题，被冲淡之后的交互圈将失去原先的情感架构和粘性价值，从而稀释社区的归属感。事实上如果单纯从社群感的角度看待问题的话，这种看似虚伪的友情仍然具备极强的拓展游戏交互层面的价值，就像David Barnes所宣扬的也是一般社交游戏遵循的原则：与陌生人竞争，与好友合作，Geoff Howland甚至认为竞争也是造成玩家沉浸的一个积极要素，更为可能的情况是玩家因为同一款游戏的竞争或者协作互动而慢慢的从现实中的陌生关系衍化为无话不谈的真诚好友。

第二个层面：玩家的情感沉浸对用户粘着度和游戏延续价值的影响

环节1：游戏中的玩家情感维度

Ernest Adams认为开发者的游戏需要在设定时充分考量玩家在游戏中可能展现的情感环节，或者说玩家是否能够在游戏中找到情感短暂的依托和归属感，在游戏的某些进阶环节，玩家的情绪又将如何变化和引导。Brenda Brathwaite就认为好的游戏应该让玩家有重回游戏的期待，并在证实了某种期待之后产生新的牵引力。

Nicolas Lamanna因此建议将情感影响力作为评判游戏优劣的指标引入游戏的分级中，一个玩家可能为了升到一个的游戏等级或者获得某种特殊的游戏道具而无数次地在刷重复式的任务，在外人看来这可能是不可思议的，但对

于正在其中的玩家而言他反倒很享受这种进程，特别是最终实现自己预期目标的那一刻对他而言更是莫大的荣耀。而反而很多情况下玩家的正常心态并不被认真考虑，事实上情感更能权衡一个玩家对游戏的认可价值。

Only A Game曾经基于游戏对玩家情感的影响作出一个调研，排比出玩家在游戏中的10大普遍情感（1040份调查问卷），依次是有趣（4.28，5分制，下同）、满足感（4.09）、惊叹（4.07）、兴奋（4.02）、好奇感（3.92）、自豪感（3.89）、吃惊（3.59）、欣慰感（3.57）、安慰（3.26）和欣喜若狂（3.26）。对此知名游戏博客Lost Garden曾就Triple Town所涉及的情感元素进行了剖析，涉及到期待下一个道具模型的好奇心、创造出美丽景象的自豪感、对碍手碍脚远程传送忍者的厌恶感、对道具在不正当时间出现的愤怒、对自己版图无能为力的无助感、对突然出现神奇移动所带来的期待和欣慰感等，直接将用户的情感灌输在游戏设定的每一个具体的环节中，也正是因为情感的渗透慢慢地将抽象的游戏概念演变为丰富而多变的游戏世界，时刻维持着游戏机制与情感节奏的相互协调，甚至反向互补。

而这也可能正是Stéphane Bura所宣扬的情感工程学的定义，丰富的内涵引导着玩家持续而富有激情的往前探索游戏。显而易见的游戏需求伴随着复杂而多变的游戏解决方案层，既挑战玩家懒散的游戏惯性，又能够在恰当的时候让玩家在彷徨无助的情况下重新燃起未来的希望，甚至让玩家在这一进程中成为其他后进玩家的先导者，以获取更高的荣耀。

环节2：关于情感与沉浸的论述

Keith Stuart曾对玩家在游戏中的真实沉浸描述得淋漓尽致：玩家在游戏中进入了某种沉浸，可能很快就进入了虚拟的状态，忽略了时间的流逝、没有觉察身边人员的走动、完全与游戏的当时氛围同步。Sean Baron更进一步拓展了这种随机意识：玩家本来可能只是打算稍微体验下游戏单纯消磨下时间，但是因为游戏设置的关系突然间完全融洽在其间，不知不觉几个小时过去之后才后知后觉地意识到自己正在扮演一个某个游戏角色，并一直努力试图在游戏中获取更高成就和分数，而后才不无惊讶地追问自己这究竟是怎么回事。

Nicholas Yee早先就从更为理论的角度来阐述游戏机制和心理层面的关联影响，这些因素可能包括成就感、人际关系、沉浸感、逃避现实和控制欲。Mihaly Csikszentmihalyi将之归因于经由游戏设计师合理引导而不断获得强化的潜意识认知，包括我们寻常所能够在现实生活中所能够感知的以及脱离于生活但能够随处寻找到合理影像的游戏素材，经由这种题材的熟悉度和玩家在游戏中所架构起来的社交临场感达到了直接性和沉浸性的双重感受。

Geoff Howland将它引申为五种玩家的心态体验，包括完成任务的沉浸感（特别是作出难以抉择的或者随机性很强的决策最终征服了挑战所呈现出来的感触）；竞争的沉浸感（竞争与协作所维持的长期交互）；控制权的沉浸感（提升玩家在游戏中的自我主导）；探索的沉浸感（让玩家在必要引导的情况下独立去发现游戏）以及获得高分的沉浸感（来自直接的成就）。在最后一个成就沉浸的问题上，Lucas Blair似乎更具话语权，他在定向Angry Birds系列的研究中梳理了完整的成就意识对玩家心态的影响，他认为有价值的成就系统最终可能会影响玩家的游戏进程以及积极性和态度，诸如在Angry Birds Rio中的星级评定和New HighScore对于任何一个玩家都具有心理暗示和行动激励（即使是在Angry Birds Space中玩家也会执着在如何以三颗星的方式顺利通过游戏关卡，即使当前受限不能也会想尽各种方式再度回到游戏以完成自己对三颗星通关的强烈夙愿），或者可以说成就系统更大的功能在于引发玩家的内在动机，从心里分析学的角度看激起玩家对某些特征属性的沉浸有助于驱动玩家的时间和情感投入，而不仅仅只是一个简单的成就排行榜或者可有可无的反馈机制（按照Jamie Madigan的说法，这已经涉及到整体游戏环境对玩家的心态影响层面了）。

基于这种情况，Michael Heald认为杰出游戏最大的特征是能够立即引起情感共鸣（投入情感就会立即同其建立联系），好像每个玩家都具有感知的真实性，都能够被这种预设的认知会被带进游戏中，并产生某种背景的熟悉度而与游戏本身出现情感的契合度，Douglass C. Perry认为在这样的情况下就必然意味着玩家已经开始认同和珍惜自己同其他玩家或者同游戏本身的虚拟纽带关系（也如Nicholas Lovell所说的群体的或者个体性的情感共鸣）。

对于很多顶尖的开发者而言，捕获用户在情感线层面的投入已经成为未来必需的层面，Neil Young曾多次呼吁开发者需要更多关注用户的游戏体验，甚至将游戏的研发进程比拟为类似电影的制作，按照Clive Downie的说法，游戏玩家是具有情感和智慧的群体而非简单的付费对象，就像音乐或者影视一样，需要为玩家带来内在的促动价值，特别是情感投入的回报，也只有我们前面提到的社区性的交互和玩家情感投入才有可能最终有持久性的黏着力，Steve Swink认为游戏的真正价值在于它让多少人为之动容。

转自游戏邦：http://gamerboom.com/archives/52327

译者序：很久以前就知道了A*算法，但是从未认真读过相关的文章，也没有看过代码，只是脑子里有个模糊的概念。这次决定从头开始，研究一下这个被人推崇备至的简单方法，作为学习人工智能的开始。
这篇文章非常知名，国内应该有不少人翻译过它，我没有查找，觉得翻译本身也是对自身英文水平的锻炼。经过努力，终于完成了文档，也明白的A*算法的原理。毫无疑问，作者用形象的描述，简洁诙谐的语言由浅入深的讲述了这一神奇的算法，相信每个读过的人都会对此有所认识（如果没有，那就是偶的翻译太差了–b）。
现在是2005年7月19日的版本，应原作者要求，对文中的某些算法细节做了修改。
原文链接：http://www.gamedev.net/reference/articles/article2003.asp
原作者文章链接：http://www.policyalmanac.org/games/aStarTutorial.htm
以下是翻译的正文。

会者不难，A*(念作A星)算法对初学者来说的确有些难度。

这篇文章并不试图对这个话题作权威的陈述。取而代之的是，它只是描述算法的原理，使你可以在进一步的阅读中理解其他相关的资料。

最后，这篇文章没有程序细节。你尽可以用任意的计算机程序语言实现它。如你所愿，我在文章的末尾包含了一个指向例子程序的链接。 压缩包包括C++和Blitz Basic两个语言的版本，如果你只是想看看它的运行效果，里面还包含了可执行文件。

我们正在提高自己。让我们从头开始。。。

序：搜索区域

假设有人想从A点移动到一墙之隔的B点，如下图，绿色的是起点A，红色是终点B，蓝色方块是中间的墙。

[图1]

你首先注意到，搜索区域被我们划分成了方形网格。像这样，简化搜索区域，是寻路的第一步。这一方法把搜索区域简化成了一个二维数组。数组的每一个元素是网格的一个方块，方块被标记为可通过的和不可通过的。路径被描述为从A到B我们经过的方块的集合。一旦路径被找到，我们的人就从一个方格的中心走向另一个，直到到达目的地。

这些中点被称为“节点”。当你阅读其他的寻路资料时，你将经常会看到人们讨论节点。为什么不把他们描述为方格呢？因为有可能你的路径被分割成其他不是方格的结构。他们完全可以是矩形，六角形，或者其他任意形状。节点能够被放置在形状的任意位置－可以在中心，或者沿着边界，或其他什么地方。我们使用这种系统，无论如何，因为它是最简单的。

开始搜索

正如我们处理上图网格的方法，一旦搜索区域被转化为容易处理的节点，下一步就是去引导一次找到最短路径的搜索。在A*寻路算法中，我们通过从点A开始，检查相邻方格的方式，向外扩展直到找到目标。

我们做如下操作开始搜索：
1，从点A开始，并且把它作为待处理点存入一个“开启列表”。开启列表就像一张购物清单。尽管现在列表里只有一个元素，但以后就会多起来。你的路径可能会通过它包含的方格，也可能不会。基本上，这是一个待检查方格的列表。
2，寻找起点周围所有可到达或者可通过的方格，跳过有墙，水，或其他无法通过地形的方格。也把他们加入开启列表。为所有这些方格保存点A作为“父方格”。当我们想描述路径的时候，父方格的资料是十分重要的。后面会解释它的具体用途。
3，从开启列表中删除点A，把它加入到一个“关闭列表”，列表中保存所有不需要再次检查的方格。

在这一点，你应该形成如图的结构。在图中，暗绿色方格是你起始方格的中心。它被用浅蓝色描边，以表示它被加入到关闭列表中了。所有的相邻格现在都在开启列表中，它们被用浅绿色描边。每个方格都有一个灰色指针反指他们的父方格，也就是开始的方格。

[图2]

接着，我们选择开启列表中的临近方格，大致重复前面的过程，如下。但是，哪个方格是我们要选择的呢？是那个F值最低的。

路径评分

选择路径中经过哪个方格的关键是下面这个等式：

F = G + H

这里：
* G = 从起点A，沿着产生的路径，移动到网格上指定方格的移动耗费。
* H = 从网格上那个方格移动到终点B的预估移动耗费。这经常被称为启发式的，可能会让你有点迷惑。这样叫的原因是因为它只是个猜测。我们没办法事先知道路径的长度，因为路上可能存在各种障碍(墙，水，等等)。虽然本文只提供了一种计算H的方法，但是你可以在网上找到很多其他的方法。

我们的路径是通过反复遍历开启列表并且选择具有最低F值的方格来生成的。文章将对这个过程做更详细的描述。首先，我们更深入的看看如何计算这个方程。

正如上面所说，G表示沿路径从起点到当前点的移动耗费。在这个例子里，我们令水平或者垂直移动的耗费为10，对角线方向耗费为14。我们取这些值是因为沿对角线的距离是沿水平或垂直移动耗费的的根号2（别怕），或者约1.414倍。为了简化，我们用10和14近似。比例基本正确，同时我们避免了求根运算和小数。这不是只因为我们怕麻烦或者不喜欢数学。使用这样的整数对计算机来说也更快捷。你不就就会发现，如果你不使用这些简化方法，寻路会变得很慢。

既然我们在计算沿特定路径通往某个方格的G值，求值的方法就是取它父节点的G值，然后依照它相对父节点是对角线方向或者直角方向(非对角线)，分别增加14和10。例子中这个方法的需求会变得更多，因为我们从起点方格以外获取了不止一个方格。

H值可以用不同的方法估算。我们这里使用的方法被称为曼哈顿方法，它计算从当前格到目的格之间水平和垂直的方格的数量总和，忽略对角线方向。然后把结果乘以10。这被成为曼哈顿方法是因为它看起来像计算城市中从一个地方到另外一个地方的街区数，在那里你不能沿对角线方向穿过街区。很重要的一点，我们忽略了一切障碍物。这是对剩余距离的一个估算，而非实际值，这也是这一方法被称为启发式的原因。想知道更多？你可以在这里找到方程和额外的注解。

F的值是G和H的和。第一步搜索的结果可以在下面的图表中看到。F,G和H的评分被写在每个方格里。正如在紧挨起始格右侧的方格所表示的，F被打印在左上角，G在左下角，H则在右下角。

[图3]

现在我们来看看这些方格。写字母的方格里，G = 10。这是因为它只在水平方向偏离起始格一个格距。紧邻起始格的上方，下方和左边的方格的G值都等于10。对角线方向的G值是14。

H值通过求解到红色目标格的曼哈顿距离得到，其中只在水平和垂直方向移动，并且忽略中间的墙。用这种方法，起点右侧紧邻的方格离红色方格有3格距离，H值就是30。这块方格上方的方格有4格距离(记住，只能在水平和垂直方向移动)，H值是40。你大致应该知道如何计算其他方格的H值了～。

每个格子的F值，还是简单的由G和H相加得到

继续搜索

为了继续搜索，我们简单的从开启列表中选择F值最低的方格。然后，对选中的方格做如下处理：

4，把它从开启列表中删除，然后添加到关闭列表中。
5，检查所有相邻格子。跳过那些已经在关闭列表中的或者不可通过的(有墙，水的地形，或者其他无法通过的地形)，把他们添加进开启列表，如果他们还不在里面的话。把选中的方格作为新的方格的父节点。
6，如果某个相邻格已经在开启列表里了，检查现在的这条路径是否更好。换句话说，检查如果我们用新的路径到达它的话，G值是否会更低一些。如果不是，那就什么都不做。
另一方面，如果新的G值更低，那就把相邻方格的父节点改为目前选中的方格（在上面的图表中，把箭头的方向改为指向这个方格）。最后，重新计算F和G的值。如果这看起来不够清晰，你可以看下面的图示。

好了，让我们看看它是怎么运作的。我们最初的9格方格中，在起点被切换到关闭列表中后，还剩8格留在开启列表中。这里面，F值最低的那个是起始格右侧紧邻的格子，它的F值是40。因此我们选择这一格作为下一个要处理的方格。在紧随的图中，它被用蓝色突出显示。

[图4]

首先，我们把它从开启列表中取出，放入关闭列表(这就是他被蓝色突出显示的原因)。然后我们检查相邻的格子。哦，右侧的格子是墙，所以我们略过。左侧的格子是起始格。它在关闭列表里，所以我们也跳过它。

其他4格已经在开启列表里了，于是我们检查G值来判定，如果通过这一格到达那里，路径是否更好。我们来看选中格子下面的方格。它的G值是14。如果我们从当前格移动到那里，G值就会等于20(到达当前格的G值是10，移动到上面的格子将使得G值增加10)。因为G值20大于14，所以这不是更好的路径。如果你看图，就能理解。与其通过先水平移动一格，再垂直移动一格，还不如直接沿对角线方向移动一格来得简单。

当我们对已经存在于开启列表中的4个临近格重复这一过程的时候，我们发现没有一条路径可以通过使用当前格子得到改善，所以我们不做任何改变。既然我们已经检查过了所有邻近格，那么就可以移动到下一格了。

于是我们检索开启列表，现在里面只有7格了，我们仍然选择其中F值最低的。有趣的是，这次，有两个格子的数值都是54。我们如何选择？这并不麻烦。从速度上考虑，选择最后添加进列表的格子会更快捷。这种导致了寻路过程中，在靠近目标的时候，优先使用新找到的格子的偏好。但这无关紧要。（对相同数值的不同对待，导致不同版本的A*算法找到等长的不同路径。）

那我们就选择起始格右下方的格子，如图。

[图5]

这次，当我们检查相邻格的时候，发现右侧是墙，于是略过。上面一格也被略过。我们也略过了墙下面的格子。为什么呢？因为你不能在不穿越墙角的情况下直接到达那个格子。你的确需要先往下走然后到达那一格，按部就班的走过那个拐角。(注解：穿越拐角的规则是可选的。它取决于你的节点是如何放置的。)

这样一来，就剩下了其他5格。当前格下面的另外两个格子目前不在开启列表中，于是我们添加他们，并且把当前格指定为他们的父节点。其余3格，两个已经在关闭列表中（起始格，和当前格上方的格子，在表格中蓝色高亮显示),于是我们略过它们。最后一格，在当前格的左侧，将被检查通过这条路径，G值是否更低。不必担心，我们已经准备好检查开启列表中的下一格了。

我们重复这个过程，直到目标格被添加进关闭列表(注解)，就如在下面的图中所看到的。

[图6]

注意，起始格下方格子的父节点已经和前面不同的。之前它的G值是28，并且指向右上方的格子。现在它的G值是20，指向它上方的格子。这在寻路过程中的某处发生，当应用新路径时，G值经过检查变得低了－于是父节点被重新指定，G和F值被重新计算。尽管这一变化在这个例子中并不重要，在很多场合，这种变化会导致寻路结果的巨大变化。

那么，我们怎么确定这条路径呢？很简单，从红色的目标格开始，按箭头的方向朝父节点移动。这最终会引导你回到起始格，这就是你的路径！看起来应该像图中那样。从起始格A移动到目标格B只是简单的从每个格子（节点）的中点沿路径移动到下一个，直到你到达目标点。就这么简单。

[图7]

A*方法总结

好，现在你已经看完了整个说明，让我们把每一步的操作写在一起：

1，把起始格添加到开启列表。
2，重复如下的工作：
a) 寻找开启列表中F值最低的格子。我们称它为当前格。
b) 把它切换到关闭列表。
c) 对相邻的8格中的每一个？
* 如果它不可通过或者已经在关闭列表中，略过它。反之如下。
* 如果它不在开启列表中，把它添加进去。把当前格作为这一格的父节点。记录这一格的F,G,和H值。
* 如果它已经在开启列表中，用G值为参考检查新的路径是否更好。更低的G值意味着更好的路径。如果是这样，就把这一格的父节点改成当前格，并且重新计算这一格的G和F值。如果你保持你的开启列表按F值排序，改变之后你可能需要重新对开启列表排序。

d) 停止，当你
* 把目标格添加进了关闭列表(注解)，这时候路径被找到，或者
* 没有找到目标格，开启列表已经空了。这时候，路径不存在。
3.保存路径。从目标格开始，沿着每一格的父节点移动直到回到起始格。这就是你的路径。

(注解:在这篇文章的较早版本中，建议的做法是当目标格（或节点）被加入到开启列表，而不是关闭列表的时候停止寻路。这么做会更迅速，而且几乎总是能找到最短的路径，但不是绝对的。当从倒数第二个节点到最后一个（目标节点）之间的移动耗费悬殊很大时－例如刚好有一条河穿越两个节点中间，这时候旧的做法和新的做法就会有显著不同。)

题外话

离题一下，见谅，值得一提的是，当你在网上或者相关论坛看到关于A*的不同的探讨，你有时会看到一些被当作A*算法的代码而实际上他们不是。要使用A*，你必须包含上面讨论的所有元素－－特定的开启和关闭列表，用F,G和H作路径评价。有很多其他的寻路算法，但他们并不是A*，A*被认为是他们当中最好的。Bryan Stout在这篇文章后面的参考文档中论述了一部分，包括他们的一些优点和缺点。有时候特定的场合其他算法会更好，但你必须很明确你在作什么。好了，够多的了。回到文章。

实现的注解

现在你已经明白了基本原理，写你的程序的时候还得考虑一些额外的东西。下面这些材料中的一些引用了我用C++和Blitz Basic写的程序，但对其他语言写的代码同样有效。

1.其他单位(避免碰撞)：如果你恰好看了我的例子代码，你会发现它完全忽略了其他单位。我的寻路者事实上可以相互穿越。取决于具体的游戏，这也许可以，也许不行。如果你打算考虑其他单位，希望他们能互相绕过，我建议你只考虑静止或那些在计算路径时临近当前单位的单位，把它们当前的位置标志为可通过的。对于临近的运动着的单位，你可以通过惩罚它们各自路径上的节点，来鼓励这些寻路者找到不同的路径(更多的描述见#2).

如果你选择了把其他正在移动并且远离当前寻路单位的那些单位考虑在内，你将需要实现一种方法及时预测在何时何地碰撞可能会发生，以便恰当的避免。否则你极有可能得到一条怪异的路径，单位突然转弯试图避免和一个已经不存在的单位发生碰撞。

当然，你也需要写一些碰撞检测的代码，因为无论计算的时候路径有多完美，它也会因时间而改变。当碰撞发生时，一个单位必须寻找一条新路径，或者，如果另一个单位正在移动并且不是正面碰撞，在继续沿当前路径移动之前，等待那个单位离开。

这些提示大概可以让你开始了。如果你想了解更多，这里有些你可能会觉得有用的链接：

* 自治角色的指导行为：Craig Reynold在指导能力上的工作和寻路有些不同，但是它可以和寻路整合从而形成更完整的移动和碰撞检测系统。
* 电脑游戏中的长短距指导：指导和寻路方面著作的一个有趣的考察。这是一个pdf文件。
* 协同单位移动：一个两部分系列文章的第一篇，内容是关于编队和基于分组的移动，作者是帝国时代(Age of Empires)的设计者Dave Pottinger.
* 实现协同移动：Dave Pottinger文章系列的第二篇。

2. 不同的地形损耗：在这个教程和我附带的程序中，地形只能是二者之－可通过的和不可通过的。但是你可能会需要一些可通过的地形，但是移动耗费更高－沼泽，小山，地牢的楼梯，等等。这些都是可通过但是比平坦的开阔地移动耗费更高的地形。类似的，道路应该比自然地形移动耗费更低。

这个问题很容易解决，只要在计算任何地形的G值的时候增加地形损耗就可以了。简单的给它增加一些额外的损耗就可以了。由于A*算法已经按照寻找最低耗费的路径来设计，所以很容易处理这种情况。在我提供的这个简单的例子里，地形只有可通过和不可通过两种，A*会找到最短，最直接的路径。但是在地形耗费不同的场合，耗费最低的路径也许会包含很长的移动距离－就像沿着路绕过沼泽而不是直接穿过它。

一种需额外考虑的情况是被专家称之为“influence mapping”的东西（暂译为影响映射图）。就像上面描述的不同地形耗费一样，你可以创建一格额外的分数系统，并把它应用到寻路的AI中。假设你有一张有大批寻路者的地图，他们都要通过某个山区。每次电脑生成一条通过那个关口的路径，它就会变得更拥挤。如果你愿意，你可以创建一个影响映射图对有大量屠杀事件的格子施以不利影响。这会让计算机更倾向安全些的路径，并且帮助它避免总是仅仅因为路径短(但可能更危险)而持续把队伍和寻路者送到某一特定路径。

另一个可能得应用是惩罚周围移动单位路径上得节点。A*的一个底限是，当一群单位同时试图寻路到接近的地点，这通常会导致路径交叠。以为一个或者多个单位都试图走相同或者近似的路径到达目的地。对其他单位已经“认领”了的节点增加一些惩罚会有助于你在一定程度上分离路径，降低碰撞的可能性。然而，如果有必要，不要把那些节点看成不可通过的，因为你仍然希望多个单位能够一字纵队通过拥挤的出口。同时，你只能惩罚那些临近单位的路径，而不是所有路径，否则你就会得到奇怪的躲避行为例如单位躲避路径上其他已经不在那里的单位。 还有，你应该只惩罚路径当前节点和随后的节点，而不应处理已经走过并甩在身后的节点。

3. 处理未知区域：你是否玩过这样的PC游戏，电脑总是知道哪条路是正确的，即使它还没有侦察过地图？对于游戏，寻路太好会显得不真实。幸运的是，这是一格可以轻易解决的问题。

答案就是为每个不同的玩家和电脑（每个玩家，而不是每个单位－－那样的话会耗费大量的内存）创建一个独立的“knownWalkability”数组，每个数组包含玩家已经探索过的区域，以及被当作可通过区域的其他区域，直到被证实。用这种方法，单位会在路的死端徘徊并且导致错误的选择直到他们在周围找到路。一旦地图被探索了，寻路就像往常那样进行。

4. 平滑路径：尽管A*提供了最短，最低代价的路径，它无法自动提供看起来平滑的路径。看一下我们的例子最终形成的路径（在图7）。最初的一步是起始格的右下方，如果这一步是直接往下的话，路径不是会更平滑一些吗？

有几种方法来解决这个问题。当计算路径的时候可以对改变方向的格子施加不利影响，对G值增加额外的数值。也可以换种方法，你可以在路径计算完之后沿着它跑一遍，找那些用相邻格替换会让路径看起来更平滑的地方。想知道完整的结果，查看Toward More Realistic Pathfinding，一篇(免费，但是需要注册)Marco Pinter发表在Gamasutra.com的文章

5. 非方形搜索区域：在我们的例子里，我们使用简单的2D方形图。你可以不使用这种方式。你可以使用不规则形状的区域。想想冒险棋的游戏，和游戏中那些国家。你可以设计一个像那样的寻路关卡。为此，你可能需要建立一个国家相邻关系的表格，和从一个国家移动到另一个的G值。你也需要估算H值的方法。其他的事情就和例子中完全一样了。当你需要向开启列表中添加新元素的时候，不需使用相邻的格子，取而代之的是从表格中寻找相邻的国家。

类似的，你可以为一张确定的地形图创建路径点系统，路径点一般是路上，或者地牢通道的转折点。作为游戏设计者，你可以预设这些路径点。两个路径点被认为是相邻的如果他们之间的直线上没有障碍的话。在冒险棋的例子里，你可以保存这些相邻信息在某个表格里，当需要在开启列表中添加元素的时候使用它。然后你就可以记录关联的G值（可能使用两点间的直线距离），H值（可以使用到目标点的直线距离），其他都按原先的做就可以了。

Amit Patel 写了其他方法的摘要。另一个在非方形区域搜索RPG地图的例子，查看我的文章Two-Tiered A* Pathfinding。(译者注：译文：  A*分层寻路)

6. 一些速度方面的提示：当你开发你自己的A*程序，或者改写我的，你会发现寻路占据了大量的CPU时间，尤其是在大地图上有大量对象在寻路的时候。如果你阅读过网上的其他材料，你会明白，即使是开发了星际争霸或帝国时代的专家，这也无可奈何。如果你觉得寻路太过缓慢，这里有一些建议也许有效：

* 使用更小的地图或者更少的寻路者。

* 不要同时给多个对象寻路。取而代之的是把他们加入一个队列，把寻路过程分散在几个游戏周期中。如果你的游戏以40周期每秒的速度运行，没人能察觉。但是当大量寻路者计算自己路径的时候,他们会发觉游戏速度突然变慢。

* 尽量使用更大的地图网格。这降低了寻路中搜索的总网格数。如果你有志气，你可以设计两个或者更多寻路系统以便使用在不同场合，取决于路径的长度。这也正是专业人士的做法，用大的区域计算长的路径，然后在接近目标的时候切换到使用小格子/区域的精细寻路。如果你对这个观点感兴趣，查阅我的文章Two-Tiered A* Pathfinding。(译者注：译文 :A*分层寻路)

* 使用路径点系统计算长路径，或者预先计算好路径并加入到游戏中。

* 预处理你的地图，表明地图中哪些区域是不可到达的。我把这些区域称作“孤岛”。事实上，他们可以是岛屿或其他被墙壁包围等无法到达的任意区域。A*的下限是，当你告诉它要寻找通往那些区域的路径时，它会搜索整个地图，直到所有可到达的方格/节点都被通过开启列表和关闭列表的计算。这会浪费大量的CPU时间。可以通过预先确定这些区域（比如通过flood-fill或类似的方法)来避免这种情况的发生,用某些种类的数组记录这些信息，在开始寻路前检查它。

* 在一个拥挤的类似迷宫的场合，把不能连通的节点看作死端。这些区域可以在地图编辑器中预先手动指定，或者如果你有雄心壮志，开发一个自动识别这些区域的算法。给定死端的所有节点可以被赋予一个唯一的标志数字。然后你就可以在寻路过程中安全的忽略所有死端，只有当起点或者终点恰好在死端的某个节点的时候才需要考虑它们。

7. 维护开启列表：这是A*寻路算法最重要的组成部分。每次你访问开启列表，你都需要寻找F值最低的方格。有几种不同的方法实现这一点。你可以把路径元素随意保存，当需要寻找F值最低的元素的时候，遍历开启列表。这很简单，但是太慢了，尤其是对长路径来说。这可以通过维护一格排好序的列表来改善，每次寻找F值最低的方格只需要选取列表的首元素。当我自己实现的时候，这种方法是我的首选。

在小地图。这种方法工作的很好，但它并不是最快的解决方案。更苛求速度的A*程序员使用叫做二叉堆的方法，这也是我在代码中使用的方法。凭我的经验，这种方法在大多数场合会快2～3倍，并且在长路经上速度呈几何级数提升(10倍以上速度)。如果你想了解更多关于二叉堆的内容，查阅我的文章，Using Binary Heaps in A* Pathfinding。(译者注：译文：在A*寻路中使用二叉堆)

另一个可能的瓶颈是你在多次寻路之间清除和保存你的数据结构的方法。我个人更倾向把所有东西都存储在数组里面。虽然节点可以以面向对象的风格被动态的产生，记录和保存，我发现创建和删除对象所增加的大量时间，以及多余的管理层次减慢的整个过程的速度。但是，如果你使用数组，你需要在调用之间清理数据。这中情形你想做的最后一件事就是在寻路调用之后花点时间把一切归零，尤其是你的地图很大的时候。

我通过使用一个叫做whichList(x,y)的二维数组避免这种开销，数组的每个元素表明了节点在开启列表还是在关闭列表中。尝试寻路之后，我没有清零这个数组。取而代之的是，我在新的寻路中重置onClosedList和onOpenList的数值，每次寻路两个都+5或者类似其他数值。这种方法，算法可以安全的跳过前面寻路留下的脏数据。我还在数组中储存了诸如F,G和H的值。这样一来，我只需简单的重写任何已经存在的值而无需被清除数组的操作干扰。将数据存储在多维数组中需要更多内存，所以这里需要权衡利弊。最后，你应该使用你最得心应手的方法。

8. Dijkstra的算法：尽管A*被认为是通常最好的寻路算法(看前面的“题外话”),还是有一种另外的算法有它的可取之处-Dijkstra算法。Dijkstra算法和A*本质是相同的，只有一点不同，就是Dijkstra算法没有启发式(H值总是0)。由于没有启发式，它在各个方向上平均搜索。正如你所预料，由于Dijkstra算法在找到目标前通常会探索更大的区域，所以一般会比A*更慢一些。

那么为什么要使用这种算法呢？因为有时候我们并不知道目标的位置。比如说你有一个资源采集单位，需要获取某种类型的资源若干。它可能知道几个资源区域，但是它想去最近的那个。这种情况，Dijkstra算法就比A*更适合，因为我们不知道哪个更近。用A*，我们唯一的选择是依次对每个目标许路并计算距离，然后选择最近的路径。我们寻找的目标可能会有不计其数的位置，我们只想找其中最近的，而我们并不知道它在哪里，或者不知道哪个是最近的。

进一步的阅读

好，现在你对一些进一步的观点有了初步认识。这时，我建议你研究我的源代码。包里面包含两个版本，一个是用C++写的，另一个用Blitz Basic。顺便说一句，两个版本都注释详尽，容易阅读，这里是链接。

* 例子代码： A* Pathfinder (2D) Version 1.9

如果你既不用C++也不用Blitz Basic,在C++版本里有两个小的可执行文件。Blitz Basic可以在从Blitz Basic网站免费下载的Blitz Basic 3D(不是Blitz Plus)演示版上运行。Ben O’Neill提供一个联机演示可以在这里找到。

你也该看看以下的网页。读了这篇教程后，他们应该变得容易理解多了。

* Amit的 A* 页面:这是由Amit Patel制作，被广泛引用的页面，如果你没有事先读这篇文章，可能会有点难以理解。值得一看。尤其要看Amit关于这个问题的自己的看法。
* Smart Moves:智能寻路：Bryan Stout发表在Gamasutra.com的这篇文章需要注册才能阅读。注册是免费的而且比起这篇文章和网站的其他资源，是非常物有所值的。Bryan用Delphi写的程序帮助我学习A*，也是我的A*代码的灵感之源。它还描述了A*的几种变化。
* 地形分析：这是一格高阶，但是有趣的话题，Dave Pottinge撰写，Ensemble Studios的专家。这家伙参与了帝国时代和君王时代的开发。别指望看懂这里所有的东西，但是这是篇有趣的文章也许会让你产生自己的想法。它包含一些对mip-mapping，influence mapping以及其他一些高级AI/寻路观点。对”flood filling”的讨论使我有了我自己的“死端”和“孤岛”的代码的灵感，这些包含在我Blitz版本的代码中。

其他一些值得一看的网站：

* aiGuru: Pathfinding
* Game AI Resource: Pathfinding
* GameDev.net: Pathfinding

好了，这就是全部。如果你刚好写一个运用这些观点的程序，我想拜读一下。你可以这样联系我：

现在，好运！

译者参考文献：
在A*寻路中使用二叉堆
A*分层寻路

尽管在今天的游戏开发领域HTML5已经不是什么新鲜事物了，但是对于大多数游戏开发者来说，这一技术更应该说是未来而非当前的重要资产。GamesIndustry International最近与一些手机游戏开发者就此问题展开了详细的讨论，Turbulenz的James Austi也参加了此次讨论。作为欧洲主要的社交/休闲游戏开发者，我们认为有必要在此分享GameDuell在开发一些HTML5项目时所获得的经验与教训。

也许未来HTML5将主导手机游戏领域，但是现在的它却还未准备好成为这一主角。任何严肃游戏开发者（特别是在网络/手机领域）为了未来的发展都需要不断探索一种全新的语言，但是在HTML5时代真正到来之前我们还需要解决并克服一些主要障碍。

首先便是玩家！

现在，大多数玩家都不希望因为下载游戏而费心。实际上，在即将到来的时代中，玩家不再想反复到多个平台下载游戏，并且他们也不愿意再不断付钱玩相同的游戏内容了。作为游戏玩家，我们希望能够马上使用自己所喜欢的设备而立刻开始游戏。
在过去几年里，社交游戏领域中掀起了一股不下载，不安装，不付费，不等待的游戏文化，并且似乎这一文化将逐渐主导着游戏发行类型，并最终可能取代传统的零售设计和心理模式。

作为一种完全基于网络的平台，HTML5似乎能够帮助发行商们满足用户的这些需求。HTML5让我们这些开发者能够立刻创造出一款游戏并将其直接发布于任何类型的设备平台上，如手机，网络，社交网站或掌机。而玩家只需要拥有连网设备或网络浏览器便能够进入游戏中。

另外一大优势便是发行商能够轻松且独立地发行自己的HTML5游戏，并且就此告别向平台运营商提交30%收益的时代。可以说，HTML5创造了一个完美的游戏世界，让众开发者能够立刻且毫无障碍地将自己所创造的游戏推向潜在玩家。
这一切听起来都美好得不真实？的确如此！

到底什么是HTML5？

我们都知道HTML是一种用于基于网页的编码语言。早在20年前来自CERN的Tim Berners-Lee创造了最初版本的HTML，并从那以后这一语言经过了多次迭代与更新才发展成今天这个样子。1996年，CSS 1.0和JavaScript被添加进去，经过了一系列的完善。但距离我们现在所看到的版本，即HTML4.01问世也将近十年了。我们必须正视的问题是，在这个快速发展的网络时代不存在一劳永逸的升级，所以我们便会慢慢发觉HTML似乎已经远远落后于时代的发展了。

如今最典型的一个例子便是我们不能有效地将视频整合到HTML中。于是，很多公司便创造出许多不同的方法和独特的格式（包括WMV和MP4）去播放视频。但是说实话，要求使用外部插件（如Adobe Flash）去运行这些格式都会让用户感到厌烦并察觉到风险性，因为他们将不得不寻找，信任，下载，安装并持续更新这些内容。

而HTML5不仅能够直接处理一些视频，也能够创造出之前的HTML语言所涉及不到的内容。从长远来看，这一优势能够帮助该语言贯穿整个浏览器和设备而创造出一种更具标准化且更具相容性的网络体验，并为用户和开发者带来更多便利。
所以我们再次得到的结论是：HTML5能够创造出更加美好的世界。事实是否真的这般美好？也许吧！

现实

现实其实有点不同。

HTML5将在未来的网络领域（特别是游戏领域）扮演一个非常重要的角色，但是现在的它尚未做好这种准备。

在GameDuell，我们并不会让HTML取代基于iOS或Android应用的原生开发（特别是从商业角度来看）。经过大量的研究和实验，GameDell认为现在还不适合将所有关注点放在HTML5的开发上。事实上，我们只投入10%的手机资源于HTML5，而剩下的90%的努力仍然是面向于原生应用开发。

如此看来，HTML5更像是原生开发的补充物而不是替代品，它能够帮助应用去获得那些通过传统生态应用而难以得到的流量。

HTML5还不是一种真正的跨平台技术，并不能帮助你快速编写出一款游戏并立即运行于任何平台和设备上。尽管新的HTML迭代是致力于将跨平台体验推向一个全新的层面，但是在HTML5项目能够真正运行于单独的平台上之前我们还需要克服重重障碍。

无需正式发行渠道便能获得用户？

从正面看，世界上两大最有影响力的网络公司都非常重视HTML5并极力推动着这一技术的发展。

毫无疑问，Facebook对HTML5报以信任。甚至在2年前，他们便为了迎接HTML5而面向此创造了一个专业性网站，并鼓励开发者“构建HTML5的未来”。当Facebook仍在被动地等待其他人能造出更加优秀的浏览器以处理HTML5代码时，谷歌早已明确创造出最优秀的浏览器才是成功的关键——因为浏览器将成为未来的娱乐平台。

随着Chrome OS和Chromebook的发行，谷歌以实际行动去证明浏览器便是未来，并且它的目标是将一切内容都运行在基于“云”的浏览器中。这里存在一个很大的问题：如果所有游戏和应用只能运行于浏览器中，那么用户便不需要去专门的应用发行商店下载内容，那么发行商如何才能将新游戏和应用带到大众面前？

为了解决这个问题，谷歌便创造了自己的Chrome Web Store，虽然这是个好方法，但是并非所有的开发者和发行商都能够打造自己的应用商店。苹果App Store和谷歌Google Play让用户能够更加轻松地购买应用，让他们能够明确方向寻找自己想要的内容。这就是为何今天的手机开发者无法承担开发HTML5游戏风险的重要原因——为了获得足够的曝光度，开发者仍需要继续开发“原生”应用。

但也有一些正面的情况：Facebook手机平台开始推行HTML5应用的社交搜索。行业博客甚至评价说“Facebook最终将成为那些无缘前100名手机应用的归宿。”大型游戏发行商同样也可以从病毒式手机网站流量中受益。我们也通过手机移动网站直接获得了许多流量，为此让GameDuell游戏的HTML5版本获得了更多额外用户。

快速发展的技术

HTML5取得了很大的进步，而如果从浏览器的兼容性来看，开发者似乎总是会低估这种兼容性。HTML5并不只局限于Chrome；我们的第一款HTML5游戏《Solitaire Harmony》便能够灵活地运行于所有手机浏览器上，包括Safari，Opera以及Silk。我们同样也注意到了技术对于休闲游戏（如纸牌游戏）的重要性，如移动传感器也能够被用于原生iOS和Android应用中。

我们同样也能够制作一些简单的动画，如弹跳或移动纸牌。但是我们也发现了在不同浏览器上会出现不同的弹跳效果：就像在Android的Chrome上，玩家只能围绕着纵轴转身，而在iPhone的Safari浏览器中，玩家却可以在水平面上弹跳。好吧，让我们想办法去创造额外代码来解决这一问题。

因为HTML5依赖于浏览器，所以玩家通常不能离线玩游戏。但是如果完全加载了游戏并获得所有缓存数据后，玩家便能够选择“脱机”玩游戏了，而如果玩家完全不能连网，他们便不能够访问游戏。

还有一个关于音频的问题，这也是众开发者非常关注的一个问题。没有声音的游戏也就失去了乐趣；因此HTML5必须谨慎地处理各种类型的音频并允许开发者能够利用这一工具。虽然HTML5的音频能够有效地运行于大多数浏览器中，但是我们却发现它在循环音乐中具有很大的局限性。HTML5音频存在的另外一个问题便是用户不能通过iPhone的硬件音量按钮关掉它，迫使用户只能使用屏幕上的软件按钮才能关掉声音。虽然在今后创造者将慢慢解决这一问题，但是现在它却严重困扰着用户的游戏体验。

多种设备，多种屏幕尺寸

尽管音频问题很重要，但是处理不同的屏幕尺寸和像素更让人备感压力。

假设你是一名游戏开发者，正致力于创造下一款“一鸣惊人”的游戏。因为听到别人说将HTML整合到手机平台上非常简单，所以你便决定基于桌面浏览器去开发HTML5游戏。你可能想着只要压缩桌面游戏的图像尺寸便能够轻松地将游戏移植到手机设备上。但是这明显是痴心妄想。

这么做你最终只能够创造出一款外表不堪的游戏，并需要额外投入更多精力和时间去完善它。对于不同设备之间，甚至连最基本的导航栏也会有所不同，这就意味着如果你想面向不同类型的智能手机发布游戏，你就需要合理地设置游戏的屏幕显示。

关于图像的另一大挑战便是像素问题。因为如今市场上出现了各种各样的手机设备，并且这些设备都具有不同的物理显示器并支持着不同的像素分辨率和密度。为了克服这一挑战，便出现了所谓的dip像素。但是因为我们最终仍需要将这种像素转化回屏幕像素，所以我们的设计难度也会随之大大增加。尽管我们在过去只拥有一个简单的“px”（即像素），但是在今天的HTML5世界我们则需要面对dpi，dip，dp，dps，sp以及sip。

但这还不是它的终点。几周前有客户与GameDuell商谈一个关于将HTML5游戏呈现在电视上的项目。这就意味着今后的我们不仅需要面对更多新的屏幕尺寸，同时还必须处理一些全新的问题，如控制方式。教新玩家如何使用HTML5的触摸和拖放操作就已经够复杂的了，现在我们还要考虑如何将这些操作方式运用于电视摇控器？

好吧，我们几乎每天都会迎来新的挑战——但是这也正是我们喜欢HTML5的重要原因。

用户留存问题

如何让人们找到一款手机游戏？更重要的是如何做才能让他们再次回到游戏中？比起网络游戏和社交游戏，手机游戏在这一领域上面临更大的挑战，并且似乎HTML5也不能扭转这一局面。

因为HTML5是基于浏览器而运行，所以一旦用户关闭了浏览器，也会随之关闭游戏。在iOS中，开发者至少可以建议玩家在主屏幕中添加一个书签按钮，但是在Android上却没有任何类似的设置。所以对于玩家和开发者来说这便是梦魇一般的存在。

最近我们在开发HTML5游戏《Solitaire Harmony》所面临的另一大问题是关于病毒式循环的问题。因为难以绑定Facebook Connect，开发者也无法有效地使用赠礼和发送请求等社交功能。所以如果开发者希望发布一款真正成功的游戏，他们就需要更加重视合理使用用户留存工具，拥有服务大量玩家的意识。

选择原生应用还是HTML5——或者两者皆得？

较低的用户留存也就意味着糟糕的盈利。所以那些想要赚钱的小型发行商最好选择原生应用开发，因为HTML5远不及原生应用赚钱。如果你必须从原生应用和HTML5中做出选择，你最好走向原生应用。

有限的付费选项将不利于应用盈利。与iOS或Facebook的便捷应用内置付费功能不同，如今的HTML5还没有一种快速付费的解决方案。如果用户如果难以付费，他们便会不想再继续玩游戏。另外一个问题是，与苹果iOS平台上分享了自己信用卡信息的2.25亿用户，还会为了在HTML5游戏中付费而反复与其他开发者或社交网络分享这些信息吗？

如果支付服务供应商和游戏开发者能够想出一些独特，安全且简单的解决方法，那么我们便可能利用HTML5获得盈利——甚至从长远角度来看其盈利结果还会优于原生应用，但是从当前来看我们却还有很长的一段路要走。如果拥有了开放网络，发行商将不再需要向发行平台支付30%的抽成。但是在此之前我们需要做的便是寻找所有潜在用户，并说服他们使用一种完全不同的付费系统。

HTML5仍然是一个冒险

在GameDuell，我们仍然将HTML5的开发当成一种冒险和学习过程。从正面视角来看，这也是我们为何如此乐观地看待HTML5的未来的重要原因。在过去8年间，我们一直在努力克服游戏开发过程中所出现的各种挑战。甚至直到游戏能够面向大众时，我们也仍需要花时间去完善它——但现在的HTML5仍然是一个美好但却不真实的开发之梦。
（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

HTML5: Too Good To Be True?
By Michael Kalkowski and Jonas Gebhardt

Although HTML5 is currently present everywhere in game development, most developers feel that the technology will be an important asset tomorrow, not today. GamesIndustry International recently discussed this topic in great detail with several mobile developers, and James Austin of Turbulenz has also weighed in. As Europe’s leading social/casual developer, we felt a need to share our own thoughts and insights that have come from working with HTML5 on several GameDuell projects.
HTML5 may be the future, but it certainly isn’t ready to be the main platform of the present. Any serious game developer (especially in the web/mobile field) needs to explore the new language in order to prepare for that future, but there are several obstacles that need to first be addressed and overcome before HTML5 saves us all.

Players First!

No gamer these days wants to be bothered with downloading a game. In fact, we are rapidly approaching an era where players are less interested in downloading a game multiple times on multiple platforms, and even less so in paying over and over to access the same content. As gamers, we want to use our favourite device right now and begin playing immediately.

“Any serious game developer needs to explore HTML5 in order to prepare for that future, but there are obstacles that need to be overcome before HTML5 saves us all”

This no-download, no-install, no-payment, no-waiting culture has evolved over the past few years within the social gaming scene, and looks likely to become the dominant form of games distribution, replacing traditional retail design and mentality.
As a purely web-based platform, HTML5 seems to give publishers endless opportunities to satisfy these customers’ needs, at least at first glance. HTML5 enables developers like us to create a game once and release it straight away onto almost any type of device of platform – mobile, web, social or console. All players need is a connected device or web browser (which nearly everyone has) and they are ready to rumble and immediately join the action.

Another key belief is that publishers can easily distribute HTML5 games independently; the 30 per cent commission for platform holders seems to be holdover from the past. HTML5 makes the gaming world a perfect, open place for developers who can instantly get their creations in front of potential players with no barriers.

Does this sound too good to be true? Probably!

What Is HTML5?

We all know that HTML is the coding language for the visual aspects of the web. Since the original version of HTML was invented by Tim Berners-Lee at CERN over 20 years ago, the language has gone through many iterations and updates. By 1996, CSS 1.0 and JavaScript were added, which have also undergone a constant series of improvements. But almost a decade has passed since the current version, HTML 4.01, was updated. Let’s face it, in the context of the fast moving pace of the internet there hasn’t been an update in forever. This has slowly led to the feeling that HTML is far behind the times.

The most critical modern example is the inability to naturally integrate video into HTML. As a result, many companies have developed different methods and unique formats (ranging from WMV to MP4) to play back videos. It’s fair to say that all the external plug-ins (such as Adobe Flash) required to run these formats are both annoying and risky, since you are forced to find, trust, download, install and continuously update them.

HTML5 is able to deal directly with videos as well as making several other things possible that were not possible with the HTML language in the past. In the long term, this could lead to a more standardised and consistent web experience across all browsers and devices, which in turn makes life easier for both users and developers.

And here we go again: HTML5 seems to make the world perfect. Does this sound too good to be true again? Probably!

Today’s Reality At A Glance

The reality is currently a bit different.

The following points have one word in common and that one word is “yet.” HTML5 is going to play a big role in the future of the internet – especially games – but it is simply not ready to take on this role.

“GameDuell is spending merely 10 per cent of our mobile resources on HTML5, with 90 per cent of our efforts geared towards native app development”

At GameDuell, we don’t see HTML as a viable alternative to native development for iOS or Android apps yet, especially from a business perspective. After much research and experimentation, GameDuell has decided as a company that now is not the proper time to put all of our focus and energies into developing for HTML5. In fact, we are spending merely 10 per cent of our mobile resources on HTML5, with 90 per cent of our efforts geared towards native app development.

At this point, HTML5 serves more as an addition to native development instead of a replacement, allowing apps to take advantage of traffic that cannot easily be reached via traditional native applications.

HTML5 is not yet a true cross-platform technology that allows you to simply write a game once and run it instantly on any platform and device. While this new HTML iteration is designed to push the cross-platform experience to new levels, there are many hurdles to cross before an HTML5 project can run on individual platforms, making the work just as challenging.
Reaching Users Without A Proper Distribution Channel?

On the plus side, two of the world’s largest and most influential internet companies are dead serious about HTML5 and are serious about pushing the technology.

There is no doubt that Facebook believes in HTML5. Even two years ago, they were “excited” about HTML5, creating a dedicated blog and rallying their developers to “build the future with HTML5.” While Facebook passively waits for others to develop great browsers that can deal with any HTML5 code, Google has already decided that developing the best browser is the key to success, since browsers will be the future entertainment platform.

With the launch of Chrome OS and Chromebook, Google took direct action, showing its belief that the web is the future, with its goal being to have everything running in the cloud on a simple, clean browser. The big question here: if games and all other apps are running in a web browser and downloading from dedicated app distribution stores suddenly becomes redundant, how can publishers distribute their latest games and apps and reach a mass audience?

Google created its own Chrome Web Store for this purpose, which is a step in the right direction, but not every developer and publisher can build their own stores. Apple’s AppStore and Google Play make discovering and purchasing content pretty convenient, giving people a destination to find what they’re looking for. That’s why today’s mobile developers can’t afford to launch a game on HTML5 only – developers still have to go “native” as well, in order to aid in discovery.

Positive things have already happened: Facebook’s mobile platform began pushing the social discovery of apps created with HTML5. Industry blogs even commented that “Facebook could finally be a decent distribution solution for the long-tail of mobile app that don’t have a top 100 ranking.” Bigger, established game publishers can also leverage viral mobile web traffic. We receive a lot of this traffic to our mobile site directly though mobile web browsers, which is a great opportunity to reach additional users with HTML5 versions of GameDuell’s games.

A Fast-Moving Technology

HTML5 is making a lot of progress and in terms of browser compatibility, developers often seem to underestimate its capabilities. HTML5 games are not limited to Chrome alone; our first HTML5 game Solitaire Harmony, runs smoothly on almost all mobile browsers, including Safari, Opera and Silk. We have also learned that the technology works great for casual games (such as card games), and supports many unique hardware features, such as motion sensors that also work on native iOS and Android.
“Limited payment options affect monetisation negatively. There is currently no solution for quick payments through HTML5″
We are also able to do simple animations, like flipping and moving cards. However, we found that the way they flip is different on different browsers: on Android’s Chrome they turned around the vertical axis as desired, but on iPhone’s Safari browser they flipped horizontally. Well, we took a deep breath, did some extra coding and overcame the issue.

Since HTML5 requires a web browser, games usually cannot be fired up without an internet connection. Once the game is loaded it is possible to cache data, so that playing “offline” is an option, but in most cases if a player does not have a live internet connection they will not be able to access their game.

There’s also an issue with audio, which is becoming a major topic with game developers. Games without sound are usually no fun; therefore HTML5 must be able to handle all kinds of audio correctly and allow developers to work their magic. HTML5 sound works well in most browsers, but we have found limitations, especially where it comes to looping music. Another problem is that sound within an HTML5 application cannot be muted by the hardware volume buttons on the iPhone, forcing players to rely on onscreen software buttons. This will almost certainly be fixed in the near future, but for now it is an annoyance that can break user engagement with a game.

100 Devices, 100 Screen Sizes

While audio is certainly an issue, addressing different screen sizes and pixel shapes is much more pressing.

Imagine for a moment that you’re a developer, working on the next awesome game that will set the world on fire. You’ve begun developing your game in HTML5 for desktop browsers because you’ve been told that adapting it to mobile is easy. Your code can quickly be taken to a mobile device by simply scaling down your graphics with little to no hassle. Turns out this is mostly wishful thinking.

By going this route, you’ll end up with a game that looks terrible and requires a lot of extra work in order to make it run correctly. Even something as basic as navigation bars differ from device to device, meaning your on-screen display is going to change on each and every type of smartphone.

The next great graphics challenge is that a pixel is not simply a pixel anymore. Due to the variety of mobile devices in the market (especially when it comes to Android phones), we suddenly have to support many different physical displays with very different pixel resolutions and densities. To overcome this challenge, density-independent pixels (dips) were invented. Since this new type of pixels have to then be converted back to screen pixels again, complexity in the design process has increased massively. While in the past we had one simple “px” (pixel), in the HTML5 world of today we now need to deal with dpi, dip, dp, dps, sp and sip.

And that’s not even the end of it. A few weeks ago, GameDuell was approached by a partner with a plan to display HTML5 games on TVs. We quickly discovered that not only would we have to suddenly deal with thousands of new screen sizes, but also address an all new issue: controls. It’s hard enough to teach HTML5 touch gestures and drag-and-drop to new players, but how are we now supposed to get these gestures controls to work with a TV remote?

Well, every day brings challenges – and that’s what we somehow love about working with HTML5.

User Retention – A Nightmare Scenario?

How do people find a mobile game? And even more importantly, how do they come back to it again afterwards? Compared to web and social games, mobile faces huge challenges in this area and HTML5 doesn’t seem to make things any better.

“Smaller publishers focused on generating revenue must choose native apps over HTML5 development, as HTML5 is far from being on par with native apps”

Since HTML5 games run in a browser, your game is “gone” once the browser is closed. On iOS, developers can at least suggest players add a bookmark button to the home screen, but there’s nothing comparable on Android. This is a nightmare scenario for both players and developers.

The second big issue we recently faced while developing Solitaire Harmony for HTML5 was related to viral loops. Due to difficulties with Facebook Connect, social features like gifting and sending requests could only be used in limited ways. Proper retention tools and the support of a huge player like Facebook are still crucial in order to publish successful games.

Native Apps Or HTML5 – Or Both?

Lower retention rates means worse monetisation. Smaller publishers focused on generating revenue must choose native apps over HTML5 development, as HTML5 is far from being on par with native apps. If you are looking to chose between native or HTML5 development, you should absolutely go native.

Limited payment options affect monetisation negatively. There is currently no solution for quick payments through HTML5, unlike the ease of in-app purchases through iOS (and hopefully Android, someday) or Facebook. The harder it is for a user to pay for something, the less likely they are to do so. The other question is whether the 225 million customers that have already shared their credit card details with Apple will share those details again and again with other developers or social networks in order to make micropayments in HTML5 games that are not distributed via the App Store.

If payment providers and developers are able to figure out unique, secure and easy solutions to solve this issue, monetisation with HTML5 games might be, in the long term, much better than native apps, but we’re still a long way from that happening. By embracing the open web, publishers won’t have to pay a 30 per cent commission to a distribution partner any longer. But before we can get there, we’ll have to find all these potential customers and then convince them to use a different payment system. Suddenly that 30 per cent markup to Apple or Google doesn’t sound so bad.

HTML5 Remains An Adventure

At GameDuell, we currently view HTML5 development as an adventure and a learning process. On a positive note, this is also why we are optimistic about the future of HTML5. Over the last eight years, we’ve always managed to find solutions to the challenges that arise during the game development process. Until it’s ready for the masses, it will still need time to mature – currently HTML5 is a development dream that is too good to be true.

(source:gamesindustry)

微软日前正在Xbox360上测试IE9浏览器定制版本，而且这个版本的IE9还支持微软的Kinect技术。即将推出的Xbox版IE9基本上将完整的PC浏览器功能搬到了Xbox平台上，这也意味着用户可以直接在主机上浏览完整的互联网内容。

据外媒The Verge报道，微软日前正在Xbox360上测试IE9浏览器定制版本，而且这个版本的IE9还支持微软的Kinect技术。

到目前为止Xbox 360仅支持Bing语音搜索功能，但是搜索结果仅限媒体内容。而即将推出的Xbox版IE9基本上将完整的PC浏览器功能搬到了Xbox平台上，这也意味着用户可以直接在主机上浏览完整的互联网内容。

和PC版IE不同的是用户可以通过Kinect手势和语音控制功能来进行网络搜索和浏览，据称这款定制版IE9虽然并不会强制用户使用Kinect，但微软在各方面都为Kinect作了优化，也就是说将来用户用Kinect浏览网页肯定比手柄操作的感觉要好。

据报道，微软已经在Xbox上测试过了该IE的修正版本，估计在即将到来的E3游戏展上我们会看到Xbox版IE9的身影。

Rovio公司CEO迈克尔·赫德（Mikael Hed）在接受芬兰电台Yle的采访时称，这款游戏将主打教育元素，游戏的主角艾利克斯（Alex）是一个“有好奇心，热衷于发明的小男孩”。

赫德称，“质量方面的压力很大”，公司希望这款游戏能获得与愤怒的小鸟一样的成功。昨日Rovio刚刚确认买下了“凯西的精巧设计”（Casey’s Contraptions）的知识产权。

公司下一款游戏将被命名为“神奇的艾利克斯”（Amazing Alex），这款游戏讲述了一位喜欢发明机械装置的小男孩的故事。Rovio表示Amazing Alex要想获得与《愤怒的小鸟》一样的成功，高质量是必不可少的因素。《愤怒的小鸟》是历史上最成功的移动平台游戏，总下载量已经突破10亿次。

创建一个动画

生成序列图

生成序列图的设置

在游戏中动态地使用序列图

下一步做些什么

@kissyteam：《KF/Uploader使用指南》：http://t.cn/zO5C1iH KF/Uploader是基于kissy1.2的异步文件上传组件，支持ajax/flash/iframe三种上传方案，支持图片预览、支持拖拽上传、内置三套主题。

组件档案

• 名称：Uploader，属于kissy-form（KF）子组件
• 版本：V1.2（请勿使用v1.0和v1.1）
• 用途：异步文件上传，支持ajax/iframe/flash三种方案的切换
• 基于：KISSY1.2.0，不支持KISSY1.1.6！
• 作者：明河（剑平）、紫英、飞绿
• 源码地址：Gallery的form目录
• demo地址：V1.2demo
• 文档：V1.2文档

教程列表

• 组件配置方式和关键配置
• 关键点说明
• 组件设计
• 核心类API调用（未完）
• 如何制作属于自己的主题（上）
• 如何制作属于自己的主题（下）
• KF/Uploader使用和设计PPT
• KF/Uploader v1.2更新说明

关于KF（kissy-form）

KF是kissy的form相关的系列组件包，目前完成uploader、日后会更多的form组件发布，比如select、suggest、radio、checkbox、auth等。
团队成员：明河（剑平）、紫英、张挺、牧云、易敛、飞绿、伯方。
代码托管于KISSY Gallery，代码会定期发布到淘宝的CDN上面，方便用户快速加载form模块。

关于Uploader

网上已经有很多异步文件上传方案了，swfUpload，uploadify等都是非常优秀的方案，为什么我们还需要花大力气写一个呢？

• flash方案太重了，希望有个全兼容多方案的异步上传组件；
• 不少上传组件非开源，有授权问题；
• 业务需求，这也是写uploader的初衷，这个组件的雏形来源于明河在退款系统中的上传凭证；
• KISSY缺少好的uploader组件；
• 写一个能够快速切换主题的上传组件。（上传组件的定制性要求非常高）

Uploader的特性

• 支持ajax、flash、iframe三方案，兼容所有浏览器。
• 配置简单，支持伪属性配置（data-config=’{}’）和配置属性来配置
• ajax和flash上传方式，带有上传进度显示
• 队列上传，批量上传等待中的文件
• 支持中途取消上传
• 支持上传验证，整合kissy的validation组件
• 不错的扩展性，自由定制按钮和队列模板样式

Uploader快速使用

先来看个最简单的demo：
点此查看demo
务必从服务器端启动demo，处理上传的服务器端脚本为upload.php（php的代码请看这里）。

1、页面中引用kissy文件

（实际应用，请引用kissy-min.js）

2、创建一个上传按钮，写上Uploader组件配置

配置写在data-config属性内，为一个json字符串，要特别小心json格式必须符合规范，不然解析时会报错。

• type：上传方式，当为auto时，组件会根据浏览器选择使用ajax还是iframe
• serverConfig：服务器端配置，包括最重要的action（路径）配置
• name：文件上传域name名
• urlsInputName：用于存放服务器端返回的文件路径的input

V1.2起不再推荐手动配置type属性，IE降级处理优先使用flash方式（v1.2前IE使用iframe，存在各种蛋疼的兼容性问题。）。

如果你希望兼容旧的处理方式（IE下使用iframe），请配置“type” : ["ajax","iframe"]。

3、创建一个队列容器

（ps：队列容器主要用于主题中显示文件信息，不是必须的，有些uploader就不需要文件信息队列显示方式。）

4、配置下组件包引用路径

对上述配置不清楚的朋友，可以看loader模块。

特别留意：cdn上的文件是打包后的，如果你想要看源码状态的，请配置包到本地路径，比如：

charset（编码）必须是utf-8。

5、初始化组件

gallery/form/1.2/uploader/index是组件的入口js，上传组件的核心模块为gallery/form/1.0/uploader/base。

现在打开浏览器看看！

归属于kissy