IT瘾游戏推荐

GDC：2026年游戏业界52%人士认为AI产生负面影响

Sun, 01 Feb 2026 21:18:49 CST

世界游戏业界专业开发者论坛Game Developers Conference（GDC）的组织者、Informa Tech于1月29日发布了一项最新调查报告“2026 STATE OF THE GAME INDUSTRY”，邀请了2300位游戏业界人士调查对于当下最火的AI技术对于游戏业界的影响，已经有52%的游戏业界人士认为AI会产生负面影响。

·“2026 STATE OF THE GAME INDUSTRY”总计收到了游戏业界人士2300人以上的有效调查问卷，其中既有一线游戏开发者，也有市场、营销、投资者等游戏业界相关人士。

·听起来似乎只有半数的游戏业界人士对AI持有悲观态度，但是对比前几年的调查，就会发现近三年对AI持有悲观态度的业内人士直线上升，相较而言，仍然对AI能够帮助游戏业界良性发展抱有信心的人士正在极速减少。

·在具体的负面影响细节调查方面，占比最多的是艺术设计达到64%，游戏设计以及剧本创作占比63%，编程为59%，实际上这些也是赞同AI参与游戏创作的开发商大力支持的主要原因。

·使用的AI模型工具最多的仍然是老牌工具ChatGPT，占比74%，占据绝对优势，其他各大巨头的主推工具各有排名。

自 3DMGame

【独家专访】那位站上今晚苹果新品发布会舞台的华人，他的名字叫陈星汉

Wed, 13 Sep 2017 02:55:32 CST

北京时间 9 月 13 日凌晨 1 点，苹果新品发布会在 Apple Park 如期举行。而与以往不同的是，一位华人出现在了这次 Apple TV 的发布环节——陈星汉，并为 Apple TV 带来了自己的闭关之作《Sky》。 陈星汉曾开发过《花（Flower）》《旅途（Journey）》等诸多受世界关注的游戏，并在第 13 届国际游戏开发者大会上获得 6 项大奖的设计师。

在 2014 年 5 月份动点科技举行的 TNT 沙龙“陈星汉的游戏旅途”上，他接受了我们的专访，并谈到了中国手游与欧美国家的差距、国内手游的同质化和对手游、页游的发展趋势等。

“游戏与其说是软件媒体，还不如说是娱乐媒体，就是人饿了要吃饭喝水，但是如果人在情感上有饥渴怎么办？因为情感是有各种各样的，有欢乐、悲哀的，从古代原始人，到当代白领工作者，其实我们很多时候是特别缺乏一种情感，每个人都会崩溃。”

以下是动点编辑 Yanni 根据现场专访实录整理：

中国是“实用主义”，而国外更注重概念

近些年，手游一直是一片红海市场，越来越多的游戏涌入到各个应用平台，但是不难看出，塔防类、卡牌类、休闲类大同小异，陈星汉谈起国内手游同质化问题时一直在强调“ 国外在制作游戏时更注重概念 ”。

我们在学校受教育的时候老师都会说，你现在是这个行业的专家了，你应该去想想怎样拓宽这个行业；而在中国，知识产权方面没有很强调，只要做成事情就可以了。在国外，如果这个游戏和某一个游戏很相似，他们会觉得没意思，他们会花更多的时间和精力去创造更新的东西。而在国内，那个概念很成功了，我们就拿过来用。中国是实用主义，同类产品很多，在创意上没有区别的话，那么国内的竞争就在运营上。国内手游运营的激烈程度和团队的工作力度上都会比国外大很多。国外更注重概念上的获胜，他们的运营在国内眼中是不运营的。

好的项目很容易被抄走。为什么会这样呢？

中国公司一般不会注重 R&D，他们是拿来主义，把设计好的商务模型和设计模型改一改换肤，这样的团队本身自己的产品很容易被复制。

在中国，如果有了某个成功的案例，通过这个案例来减少风险成本，中国的公司会不遗余力的去做，而且市场足够大，我觉得这也是国情造成的。不像国外，你做了《炉石传说》，有人抄袭的话会被人唾弃。

我从小在上海长大，然后从 1990 年开始打游戏，一直打到 06 年研究生毕业，我现在又一直在做游戏，游戏是我生命中最重要的事情。我希望中国的市场能有更多创新的能量在，把情感，或者说正能量带入到游戏中。游戏并不是只有小学生、中学生可以玩，也并不是暴力、血腥的体现，我希望游戏是老少咸宜的，是让人能感受到希望的，所有人都能爱上游戏。

通过社交的模式让游戏联系的更紧密

在上一周的 iOS 免费游戏排行榜中，我们看到紧跟《炉石传说》之后的都是微信平台的游戏，那些游戏更为休闲化和平民化，但是由于社交网络的联系，让他们在某种关系和程度上对游戏有更好的促进作用。世界上还没有哪个产业能比移动游戏更加专注于数据分析，他们对用户在游戏中的每一个举动、每一次交流、每一个分享都会进行详细的检查。从公开的数据来看，2014 年第一季度，手机 QQ 及微信上智能手机游戏的组合总收入为 18 亿元，两个季度累加的总收入达到 24 亿元。

游戏社交是一个趋势，就算平台不做，开发商也会来做。比如美国最火的游戏《Game Of War》它现在已经排到第三名了，他们的 CEO 是个老外，在上海打了一年的征途，悟出点中国的道路，就回到国外用西方的方式把这个东西做出来。为什么这个游戏这么火？这个游戏其实和国内的业务没什么区别。这个游戏是 历史上第一个支持 Google Translate（谷歌翻译），就是说各个国家不同的人都是连接起来的，俄罗斯黑帮的人碰到阿拉伯的土豪，开始互相打仗和骂人，语言可以被翻译，有点像征途国战的概念，所以玩家特别肯花钱。就是这种社交的因素，跨国多语言性导致用户粘性特别高。我觉得这是未来的趋势—— 通过社区的形式让游戏的联系更强。

页游、端游都将移植到手游

手游崛起在人们日常生活中的碎片时间，它的载体携带更方便，操作更简单，容易被人理解。虽然页游每个月仍然有很多新版游戏在上线，但是质量越来越差。页游的用户一般就是小白用户和公务员，下午午饭后，公务员会到办公室开始搞“帮派战争“，让一小批玩家找到自己做老大的机会，对长期市场不利的运营模式。

最早傲视天地发明了新的商务盈利模式，七雄争霸（腾讯）、水浒、天龙八部，其实都是同一个模式只是不停的反复的刷，可能有人不喜欢三国，他喜欢武侠，就去玩了同一个模式下的不同时代背景的游戏，这都是不可持续的市场，页游不创新大家都会离开。页游之所以火是在智能手机普及之前，因为大家上班都可以上网页。可是现在手机是更大的一个市场，手机市场是一个社交网络、页游和端游三个不同方向同一争抢的地盘，所以手游上有很成功的页游移植，社交网络游戏的影子，端游也可是进军手游，所以手游市场是最难描述的市场。最近又通过社交出来很多全民游戏，其实说白了就是低门槛游戏，所以对手游很难概括。

关于电竞：在中国，商业化战队刚刚开始

陈星汉同样也是一个端游游戏的爱好者。在刚刚结束的英雄联盟（以下简称 LOL）S4 赛季，他认为中国和欧美国家、韩国职业电竞选手的特点是怎样的呢？

韩国的职业电竞选手的综合能力更强，因为韩国的电子竞技文化在很早就开始了。在洛杉矶的 LOL 直播现场有大约 2 万人参与，大部分都是男生，在韩国，很多女孩子也很关注。为什么这么多人喜欢体育明星？因为他们获得的回报会很多。一样去一个战队，你去韩国可能是赚钱最多的。所以金钱和社会价值上的鼓励，我相信韩国的职业选手会更加卖力，淘汰更加严格。但是在中国，商业化战队也就这几年才开始。近几年之内，除非是碰到天才战队和选手，不在乎钱，愿意把青春奉献给电子竞技的年轻人，那才可能打败国外一些很牛战队。

对于我来说，电子游戏应该不仅仅是一种艰难生活中的娱乐消遣，优质的游戏可以帮助玩家直面困境，甚至扩充思想。

本文【独家专访】那位站上今晚苹果新品发布会舞台的华人，他的名字叫陈星汉来自动点科技.

正在崩塌的手游渠道，手游正越来越像当年的端游？

Thu, 09 Feb 2017 17:37:00 CST

作为渠道鼎盛的标志，2013年7月，百度选择19亿美元收购了91手机助手，创造了当时中国互联网产业最大规模的并购记录。

这个并购案在当时一度遭到了360的狙击，360、百度两大渠道巨头都寄望于收购91来扩大自己在行业中的优势。

收购的效果立竿见影，根据数据调研机构EnfoDesk易观智库发布的《2013年第4季度中国移动应用分发市场监测报告》显示，截至2013年第4季度，百度系分发平台的市场份额达到了41.2%反超360，位居行业第一。另外，百度也成为了首个日均分发量1亿的应用渠道。

实际上，按照当时的价格来看，19亿美元是否虚高存在很大疑问，但紧随而来的渠道热，以及渠道所展现的价值，以及从2013年下半年开始的手游公司一个接连一个的以超高的价格并入上市公司，19亿美元着实是一个很划算的收购。

但在今天，这个当时创造了中国互联网产业并购史的收购，可能最终以被打包出售而告终，根据多家媒体的报告，百度游戏即将被整体出售。

从19亿美元的天价收购，再到今天所面临的即将被出售的命运，在百度游戏身上，实际上所折射的就是中国手游渠道的现状，从发展之初拥有着绝对话语权的分发渠道正在逐渐崩塌，展现在我们面前的是一个正越来越像当年端游发行模式的手游发行，官方下载。

在渠道圈这样一个疑问正在诞生，冬天已经来了，但冬天是否会过去?

野蛮的渠道，5/5分成起步

在很多场合，我都曾说过这样一个例子，2013年手游刚刚开始爆发，在当年的CJ上，某手游公司CEO兴致勃勃的从武汉到上海寻找机会，但原定4天的行程被缩短至2天，在他的总结中，手游渠道傲慢的态度和80%起步的分成比例令他望而却步也印象深刻。

在2013年，渠道和CP之间，5/5分成是起步，即便如此，这也局限于十分少数的几款当时月流水可以达到2000-3000万的现象级产品上。而更为普遍的分成模式是3/7分，渠道拿70%，剩下30%由CP和发行方分享。

在当年的一场论坛上，蓝港CEO王峰曾表示，三年内守住5/5分账就是手游的黄金分割线，可以让手游企业研发出更健康的产品，彼时蓝港旗下《王者之剑》目前月流水是2200万，可以算是顶级产品。

按理来说，游戏有着高度的内容导向，渠道本不应该在这场博弈当中占据多大的话语权。我们可以以影视来举例，在影视行业，向来只有视频网站、各大卫视争抢优质的内容，比如一部好莱坞大片，肯定是各大视频平台之间互相抬价争抢的，而不可能出现制片方委曲求全的要和某平台合作。

这就是因为内容导向的原因，用户更多的是因为要看这部电影才来到你的平台，而不是因为你这个视频平台给我推了什么电影，我就看什么电影。这也是至今为止，视频平台之间依旧在花高价争抢优质内容的原因。

同属内容性产品，手游却出现了截然相反的情况，其主要原因在于当时的手游产业属于发展的早期。

渠道霸权的原因：产品过剩、同质化严重、人口红利

“国内目前正在研发的手机游戏预计高达近5000款，进入测试的约有3000款，而国内手机玩家总数才一亿多人，平均每款手游能摊到的用户不足3万人”，在2013年的CJ论坛上，触控科技首席执行官陈昊芝表达了他对于手游产业的担忧。

小到4-5人，大到上百人，仅2013年一年，就有上千家手游创业公司诞生，有过这样一个笑话，一栋居民楼里，10户，9户是手游创业团队。

相较于端游、页游，手游在当时的轻资本备受青睐，一款普通的手游，从立项到研发，可能仅仅100万就足够。

这些创业团队，一部分是看到了手游的机会，从大公司拉上几个人跳出来创业，一部分是之前尽力了端游、页游但没有获得成功的连续创业者，还有一部分可能之前和游戏从无交集，只是懂一点编程代码就轻装上证。

如果说大量的创业者，海量的产品将渠道推到了一个强势的地位，那么更为严重的是这些产品80%，甚至90%以上存在一个问题，同质化。

其中最具代表性的就是卡牌，随着《大掌门》、《我叫MT》的成功，一夜之间，手游市场开始集体转移到卡牌上，这种结合了策略的休闲游戏，付费坑多，符合手机的碎片化，不需要复杂的操作，换皮就可用，对于手游研发商而言，简直不能再完美。

数据显示，在2013年当年，卡牌手游占据了手游市场65%的市场，在AppStore 2013年Top50榜单当中40%是卡牌。

同质化严重，换皮成风，直接决定了渠道的强势地位进一步加剧，成为了完完全全的霸权主义，渠道给不给量，成为一个产品是否获得成功最重要的因素。

当然，除了这些由CP自身原因导致的渠道霸权外，渠道自身也有原因，海量的“人口红利”。

根据《中国游戏产业报告》的数据，在2013年6月，中国手游用户的数量是1.7亿，到了2013年年底，这一数字突破了3亿，仅仅半年的时间，增长接近一倍。

相比于端游，手游的本质就是大众化，端游发展了20年，用户的数量也就超过1亿，但手游在短短的几年时间，就超过了端游的几倍。

大量的非游戏核心用户进入手游的世界，这部分用户对于如何挑选游戏本就没有目的，就如最初那一代的网民依赖hao123这样的网址大全，他们一开始也会顺着渠道的推荐走，那个时候的渠道，高峰的时候，每天增加数百万这样的用户，这些用户直接被渠道给高价卖给了一个个CP。

手里握着如此丰厚的资源，渠道的话语权自然加大。

霸权旁落，硬核并不是原因

但是，这样的情况却在2015年开始逐渐发生了一些变化，并在2016年加剧。

根据360的财报显示，2014年360的互联网增值服务营收(主要来自于游戏平台业务)同比增长141.9%为6.112亿美元。而到了2015年Q1互联网增值服务营收为1.337亿美元，同比增长7.1%，环比下滑20.1%，Q2(宣布私有化前最后可查数据)则是1.222亿美元，同比下滑16.4%，环比下滑8.6%。

可以看出，从2015年开始，保持高速增长的游戏业务增长开始放缓甚至出现倒退。渠道的霸权开始初次展现崩塌的苗头。

当然，有声音认为，导致类似百度、360这一类渠道走低的原因还有硬核联盟的出现，在手机分发的链条当中，终端>OS>ROM>应用商店>现象级App，如小米、华为们这些硬件手机直接从终端切入。

随着这几年手机厂商对于内容营收的重视，应用分发这一块正逐渐开始发力，2015年更是几家手机厂商牵头成立了硬核联盟，他们的出现，切分了很大一块属于百度们的市场，众多用户在跟换手机之后，会选择直接使用手机自带的商店进行下载。

也就是说，原本属于360、百度们的市场被小米、华为等开始蚕食，从而导致类似百度、360这样的渠道开始走弱，但整体的第三方分发渠道市场规模依旧十分可观。

但是，我们从一份数据当中却发现了问题，来自小米官方的数据：2015年1-6月开发者分成为5.8亿元，2016年1-6月，开发者分成为6亿。

可以看到，相比于2015年，2016年，小米在开发者分成的数据上并没有多大的增长，而且这个没有增长的背景还是小米从2015年6月的200亿次总下载激增到2016年6月的500亿次总下载的背景下。

从中可以看到，实际上无论是360、百度，还是小米、华为，实际上在应用分发这一层面的收入上都受到了影响，也就是说，整个第三方分发渠道都开始了急速的倒退，导致这一结果的原因和中国手游市场的发展分不开关系。

市场垄断、发力官服，渠道的未来堪忧

2016年，移动游戏以17.7%的同比增长，819.2亿元的营收，49.5%的市场占比完成了对端游的全面反超，结束了端游近20年的霸权。

看上去，一切都很美好，一个依旧在保持一定速度增长的巨大蛋糕，诱惑满满，但是真实的情况却截然相反，在2015年所呈现的寡头化趋势在这一年愈发的加剧。

公司层面，继2015年腾讯与网易两者吃掉中国手游市场接近55%的市场份额的背景下，在2016年上半年这两者占据了约65%市场份额，考虑到下半年的《阴阳师》，2016年这两大巨头有望吃下70%的市场份额，甚至更高，接近垄断。

产品层面，TOP10的手游产品营收达到357.6亿元，占据整体手游市场43.7%的市场份额，这10款产品当中，仅一款《问道》是非腾讯、网易系游戏。

这样的垄断所带来的是中小CP愈发艰难的境况，生存空间被无限挤压，但这仅仅是一方面，另外一方面就是渠道受到的巨大冲击。

当市场中的优质产品高度集中于腾讯、网易两大巨头，当巨人、西山居、完美等等当年端游时代的巨头选择和腾讯合作，对于渠道而言，他们的溢价权开始急速走低。

而走低的背后，是手游的内容属性开始放大，随着人口红利的消失，手游的用户无限逼近中国移动互联网整体的用户，渠道的新增用户增长开始放缓，日均分发量开始下滑，渠道某种时候所体现的类似上述所说的“hao123”的导航效果不再显著。

新用户的增长趋近于无，老用户开始升级，在选择产品时有了主观的选择性，更多的时候是通过用户之间的口碑传播，或者选择有品质保证的大厂出品。

手游厂商开始逐渐发力官服，区别于渠道服，官服能够享受到更加好的服务，相比于官服，渠道服的活跃度往往是开服的那一段时间，之后就开始逐渐转变为鬼服，另外在活动上，官服相比于渠道服也更多，最重要的是无论是在游戏的稳定、游戏的环境、游戏的更新速度，以及游戏账号的安全保障等等方面，官服都占据优势。

实际上，早在2013年，盛大的《百万亚瑟王》就曾由于种种原因，绕开渠道，用官服这种模式，在当时取得了十分不错的成绩，但后来由于环境不成熟，而后续乏力。

但现在，随着用户、市场逐渐开始走向成熟，这种方式被认为才是手游的未来，也就是从官方渠道下载，享受官方的服务，而非第三方的渠道服务，这就有点类似当年的端游，一切从官网渠道走。

在笔者查阅了几款热门的产品如《阴阳师》等，都发现一个问题，玩家对于官服的热衷程度远远高于渠道服，此前也曾发生过安锋渠道违反公平运营，而被整体封禁，而《诛仙手游》也曾发生过封禁50家渠道。

根据一些非官方的数据显示，《阴阳师》的玩家当中有50%在官服，另外50%在渠道服，而网易旗下另外一款游戏《迷你西游》的安卓渠道收入95%更是来自网易自身的官服渠道。

相比于渠道对于产品只认流水，KPI，显然，官方会看的更加长远，类似充值返利这样的在渠道当中盛行的模式，官方的态度一直是明确的打击，以确保游戏的可玩性和生命周期。

正如网易丁磊所说，或许渠道可以支撑二、三流的产品，但真正一流的产品对于渠道的依赖已经没有那么严重了。

网易、腾讯系这样的巨头完全不担心渠道是否会对产品进行倒流，他们的产品可以完成流量的自我转化，更多时候是渠道会求着这两大厂商的产品上线他们的渠道。

在笔者映像当中，最为深刻的就是2016年年初那会的《皇室战争》的上线，几乎所有第三方的渠道都在为一款产品做尽可能多的宣传，360为此拿出了S级别的资源，百度、UC九游等也纷纷如此，不惜一切代价。

当中的逻辑在于渠道开始变得极度依赖好的产品，因为只有这样才能留住用户，就如为何各大商场即便亏本也要引进一些厂家的原因。也就是说从最初的渠道导流，到依靠优质的产品来引流，或者保流，再通过其它产品变现。

这也是导致为何百度游戏空有十几亿流水，但却很难赚钱的主要原因，也是360财报当中有关游戏的营收自2015年连连下滑的原因。

真正高流水的顶级产品，渠道的溢价不高，所能分得的利润微乎其微，甚至是在赔本赚吆喝式的引入顶级产品，而一些可以获得高分成的产品在流水上却又差强人意。

这个时候，手游开始逐渐像影视产业，视频平台为了优质的影视作品一掷千金，为了吸引用户，留住用户。

2013年渠道的霸权就在眼前，仅仅3年时光，斗转星移，还原在我们面前的是一个正在逐渐崩塌的渠道现状。

百度游戏即将被打包出售只是其一，豌豆荚的坚持最终败给现实选择在去年年中2亿美元卖身阿里同样是一个很好的例证，另外从2015年开始，360选择从分发涉足独代发行，在2016接连发行了《幻城》、《迷城物语》、《圣斗士星矢：重生》、刀剑神域《黑衣剑士》、《大奇幻时代》是其三。

如今，留给渠道的疑问在于，在一个市场高度成熟，优质产品近乎垄断，大厂纷纷转向自身的官方渠道时，第三方的渠道是否还有必要存在?

当用户在选择产品时，第一选择大厂、大制作，第二直奔官网下载之时，第三方渠道看上去是没有了存在的必要，用户已经完成了自我的分层，优质用户进入优质渠道，轻度、休闲用户进入渠道服。

更多精彩内容，关注钛媒体微信号（ID：taimeiti），或者下载钛媒体App

App Annie：2015年移动游戏收入占移动应用市场总收入85%

Thu, 11 Feb 2016 19:13:14 CST

2016年2月11日，市场研究公司App Annie公布报告称，2015年移动游戏收入在整体移动应用市场总收入中所占比例达到了85%左右，全球移动游戏收入达348亿美元。

这项数据是App Annie针对所有移动应用未来增长趋势而编制的一份广泛报告的部分内容，该报告预计到2020年时整体应用经济规模将从今天的510亿美元增长至1010亿美元。报告还称，2016年移动游戏收入将达415亿美元，到2020年则将达到746亿美元。如果将所有板块中的全部游戏相关收入都加到一起，那么人们就会发现，游戏市场的全球规模已经达到了令人瞠目结舌的极高水平。

报告预测，游戏应用的增长将来自于成熟市场强劲的商业化进程，尤其是中国的一、二线城市以及日本和韩国等市场的增长。

值得指出的是，其他一些预测来源对于游戏应用的前景则有着不同的展望。投资机构Digi-Capital的科技顾问预测，到2020年游戏软件行业的规模与2016年的900亿美元相比将增长22%，达1150亿美元。Digi-Capital称，游戏行业正在继续进行一场大规模的转型；随着各个板块的“潮涨潮落”，市场领导者正致力于巩固自身地位。现在的增长率是健康的，但已经不像过去几年时间里那样高了，原因是整体行业已变得更加成熟。

与此同时，市场研究公司EEDAR估测称，2015年游戏机软件和硬件市场的总规模为440亿美元。另一家研究公司Jon Peddie Research则预测，2016年全球个人电脑（PC）游戏硬件销售额将从2015年的246亿美元增长至261亿美元，到2018年则将增长至300亿美元。

另外，“开放游戏联盟”（Open Gaming Alliance）预测，到2018年时个人电脑游戏软件行业的规模将扩大至350亿美元，相比之下2014年为260亿美元。

您可能也喜欢的文章：
App Annie：新型应用市场展望（附报告）	App Annie：顶层发行商数量减少，收入增加	App Annie：2014年6月中国移动游戏应用指数排名	App Annie：2015 年全球移动应用市场回顾（附下载）	App Annie Japan：2014年日本和海外的移动APP、游戏动向
无觅

为何说大数据精准广告并不靠谱？

Tue, 01 Dec 2015 11:46:00 CST

一、大数据精准广告内涵

大数据目前已经成为整个IT界(包含Internet Technology 以及Information Technology)最热的词汇之一，似乎任何一个话题，只要提到大数据，瞬间变得高大上。一夜之间，大数据已经代替主观的理性思考，成为智慧洞察的代名词。

但是当我们走过对大数据的顶礼膜拜阶段，揭开大数据实际应用的面纱，反而逐渐对充斥着话语世界的大数据进行反思。因为大数据在经济发展中的巨大意义并不代表其能取代一切对于社会问题的理性思考，科学发展的逻辑不能被湮没在海量数据中。著名经济学家路德维希·冯·米塞斯曾提醒过：“就今日言，有很多人忙碌于资料之无益累积，以致对问题之说明与解决，丧失了其对特殊的经济意义的了解。

以大数据的广告应用为例，精准广告投放应该是大数据最早的也是最容易产生直接收益的应用，如今少有广告公司没有宣称自己是大数据科技公司。大数据精准广告的核心内涵是什么？一言以蔽之，那就是程序化定向投放。其中定向是核心，程序化是手段。

以微信朋友圈为例，不定向区域，年初的公开价格CPM(每千次曝光成本，朋友圈广告价格远超一般媒体)40元，定向核心城市140元，定向重点城市90元，如果叠加定向性别，附加10%，再叠加H5外链(流量引导效果更好)，再附加20%。就像进口化妆品一样，先按一定比例征收关税，后按含税价格再征收增值税，再按含税价格征收消费税。

对于微信来说，客户地域、性别虽然也需要数据分析解读，但确认相对比较容易。对于其它数据公司来说，地域依然可以通过IP或手机终端GPS获取，但性别更可能就是一个数据分析出的可能属性。当然大数据并不仅仅分析如此简单的标签，对于媒体联盟而言，媒体选择项目众多，还会分析客户媒体偏好标签，还有时间段、人群属性、设备类型、偏好类型等多种定向组合方式。

好了，上面对于精准广告有了一个粗浅的介绍。那么大数据精准广告能带来什么样的价值？通常如下的故事是大数据广告公司经常提及的。

假如一个网站的广告位，每小时有1万人来浏览，则一小时曝光量为1万，之前的CPM为5元，那么一个手机广告主投放一小时广告，成本50元。这是传统广告投放的结果。现在有个大数据公司，来帮助该广告媒体更好的运营。该公司宣称它能够精准识别浏览客户的属性，告诉手机广告主，虽然1万人浏览该广告位，但真正适合投放手机的只有6千人次，剩下4千人次的曝光为无效曝光，因为剩下的人群只对服装感兴趣。

大数据公司建议广告主按照程序化投放，过滤掉不适合投放手机的4千人，仅对适合投放手机的6千人付费，假如单价不变，那么在保证相同效果的前提下，成本降低至30元。剩下的4千人大数据公司将其销售给服装广告主，成本为20元。由此，在相同的效果情况下，大数据广告大幅降低广告主的成本。当然事实上，由于RTB(实时竞价)机制的存在，当价格(效果相同)低到一定程度，不同手机广告主的相互竞价，使得真实价格一般高于30元，但肯定介于30元到原有预期成本50元之间，由此形成多方共同获益的理想局面。

这样的案例看上去Perfect，无懈可击。因为它解决了传统广告的低效问题，比如看起来有用，但又说不清楚到底有用在哪里，这个正是各公司财务总监所深恶痛绝的。是的，通过大数据广告，让一切花在广告上的钱更有依据，可以在线评估一条广告到底造成多少的印象(Impressions)，甚至多少点击，多少因此而下载使用，多少因此产生交易。

有问题吗？没问题。有问题吗？你什么意思，难道你要怀疑真理？

二、大数据精准广告没有看上去那么美好

本着证伪的原则，真理只有被证明为谬误的时候(理解其应用的局限及条件)，才算真理。因此我们必须先回答一个问题，广告是用来做什么的？

按照以前的共识，广告被视为品牌用来向那些无法面对面沟通的消费者去传达品牌的特性。因此广告虽然对销售有促进作用，但通常时候，广告的内容并不直接说服消费者去购买，就如中国移动曾经的获奖广告“沟通从心开始”一样。2010年出版的《品牌如何增长》(How Brands Grow)一书(说明，笔者未读过，希望将来能读到)，作者南澳大利亚大学教授拜伦在书中指出，广告要达到最好的效果，往往不需要去说服或灌输，只要让人在购买的时候回想起品牌的名字就可以了。市场研究机构Milward Brown创始人高登(Gordon Brown)就指出，广告的功能就是让一个摆在货架上的品牌变得“有趣”。

好吧，再回到大数据精准广告案例，其中一个最为关键的问题在于，大数据如何分析出这6千个浏览用户适合投放手机广告？对于这个问题，广告公司早有准备，给出如下的种种答案。

第一，从历史记录中寻找曾经使用过同类产品的客户进行匹配。通常使用的算法叫“协同过滤”，即由某些经验的相关性，找到潜在的适合用户。比如你玩过某款游戏，因此可认为你对该类型的其它游戏也有相同的需求。笔者并不否认该算法对某些领域确实有作用，比如游戏付费用户基本就是之前重度游戏使用用户。

但是抛开这些特殊领域，该算法内涵思想“品牌依靠忠诚的消费者发展壮大”与拜伦的理论完全矛盾。拜伦通过对销售数据进行统计学分析，他指出在所有成功的的品牌当中，大量的销售来自“轻顾客”(Light buyer)：也就是购买产品相对不那么频繁的顾客。可口可乐的生意并非依靠每天都喝可乐的人，而是数百万每年喝一次或两次的顾客。这种消费者模式在各个品牌、商品品类国家和时期都适用。无论是牙刷还是电脑，法国汽车或是澳大利亚银行，品牌依靠的是大规模人口——换句话说，大众——那些偶尔购买他们的人。

这个理论意义十分深远。这意味着你永远无法通过精准营销现有顾客来增加品牌的市场份额。而对现有顾客的精准营销，正是数字媒体所擅长的。

本着批判的精神来看待新出现未经检验的思想，笔者希望引用一下广东移动最近公布的用户换机特征数据。广东移动对旗下用户的终端迁移分析表明，使用苹果的用户升级终端，继续使用苹果手机的占比64%，忠诚度最高。但除苹果以外，其余忠诚度表现最好的华为、小米手机，更换4G后持续使用同品牌的占比不到30%。

这说明，你向苹果4或5用户推广苹果6是可行的，果粉效应推翻拜伦的理论，证实在部分领域依靠忠诚的消费者发展壮大是可行的。但除此以外，你向任何一个当前品牌的用户推广同品牌的手机终端都是不合时宜的。

因此，希望通过历史的电商数据分析推断用户下一步可能需要是无效的。就如向曾经购买过服装的用户推广服装，或许不如推广一卷纸或一桶油更为有效。

相反，成功的品牌需要找到一种方式来到达目标市场之外的群体。品牌的广告一定要用某种方式获得这部分人的兴趣——只有这样，当他们在准备购买的时候，该品牌才能自动出现在消费者的脑海中。

第二，如果“协同过滤”存在局限，广告公司会告诉你还有第二种算法，并不基于客户的历史行为记录，而是客户本身特征相似性，来找到与种子客户最为相似的客户群体。简称“Lookalike”。先需要广告主提供本则广告起到作用的典型用户，以手机为例，受广告影响感兴趣点击浏览或预购某手机的用户，大约几百或几千个。大数据公司通过Lookalike算法(专业的术语更可能是稀疏矩阵)，寻找与这几百/千个用户高度相似的其它数十万/百万客户群进行投放。

这类算法真正考验大数据平台的计算能力，因为并不是经验性的协同过滤，而是利用数十数百甚至上千个变量进行回归计算。最后按照相似性的概率打分，按照由高到低选择合适的用户群。

该模型的内涵其实很简单，就是广告要传达给应该传达的客户。比如奶粉广告目标用户就是养育0-3岁孩子的父母。如果知道要到达用户的具体身份，一切问题迎刃而解。但是对于网站或APP应用来说，并不清楚用户身份，唯一清楚的是客户的历史行为数据。而且由于数据本身的分割，有的专注于运营商，有的专注于APP联盟采集，有的专注于电商，有的专注于银行，要从分割的数据中推断出客户的身份信息，Lookalike就是不可避免的手段。

唯一的问题是，如果由几百个种子用户推断出新的几百个目标用户，准确性可能高达9成，但如果如某广告公司宣称，对康师傅辣味面进行移动DSP投放时，根据历史投放数据分析挖掘，形成样本库，再通过Lookalike技术进行人群放大，找到与目标受众相似度最高的潜在客户，扩展人群1367万，实际投放受众ID2089万。广告效果投放是最大化了，那么效果呢？在此，请允许我杜撰一个数字，很可能点击率由0.2%上升至0.3%，精准度提升50%。有意义吗？或许有，但绝对没有想象的那么明显。

第三，如果你们持续怀疑我们算法的有效性，那么我们可以就效果来谈合作，你们可以按照点击量(CPC)或者激活量(CPA)付费，如果达不到既定效果，我们会补量。这是大数据广告的终极武器。

终极武器一出，意味着广告的投放彻底沦陷为做点击、做激活的渠道，广告的“沟通消费者”初衷早被抛弃得一干二净。

通常一般消费决策遵行S(Solution)、I(Information)、V(Value)、A(Access)规则，意思是当用户产生一个需求，内心先就满足这个需求形成一个解决方案。比如说3G手机不好用，速度很慢覆盖不好，需要换一个4G终端就成为一个Solution。那么4G终端有哪些，重点考虑那些终端？消费者还是搜集信息，并非从网上搜索，而是根据以往的经历、品牌效应、周边朋友口碑自动回想那些品牌、哪些款式。传统广告的最重要功效应该就是这个阶段，当用户需要的时候，自动进入到用户视线。然后从多维度比较选择，确定首选购买品牌。最后就是去哪儿买，搜索哪儿有促销活动，哪里优惠力度最大。

根据SIVA模型，真正的以效果为导向的广告本质解决的是Access问题，最后的临门一脚。在这方面，搜索广告是真正的效果导向广告，比如淘宝的每一款商品后面都有超过1万家商户提供，到底用户去哪里购买，得付钱打广告，这就是效果广告。曾有报告对比过，搜索广告点击率高达40%以上。想一想百度、阿里靠什么为生，临门一脚的广告价格自然高到没边，据说一些医院购买百度性病、人流之类的搜索广告，单次流量价格高达数十或数百元。

搜索广告只有少数垄断接入公司才有的生意，大部分广告仍为展示类广告。如果展示类广告也朝效果类靠拢，从商业规律上属于本末倒置。

最后结果是，一方面，广告的内容充满人性的贪婪(优惠／便宜)与色欲(大胸美女)，被改造得不伦不类，上过一次当后，在沟通消费者方面反而起到负面作用。另一方面，广告公司沦落为做流量、做点击的公司，与北京望京、中关村著名的刷流量一条街没有本质的差异，最后谁真正点击了这些有效流量？曾有大数据公司分析过某款高端理财软件的阶段性用户群，与刷机、贪图小便宜的极低端用户高度相似。

三、多用靠谱的身份识别可能更有利于提升广告效果

写了这么多，大数据精准广告一无是处吗？不，怀疑真理是为了更好的应用真理。大数据广告的核心“程序化”与“定向投放”没有错，这代表移动互联网发展的趋势，也与满足特定市场、特定用户群的商品或服务广告传播需求完全匹配。问题在于目前的大数据实际能力与宣称的雄心还有巨大的差距。也就是说没有看上去的那么好。

所以，我们更应该回归广告的本来目的——更好的沟通消费者，来看待精准投放，而不是迷信大数据精准投放这样的噱头。那么什么最重要？显然不是不靠谱的协同过滤规则，也不是根本不知道原因的Lookalike，既然最重要的就是到达目标消费者，那么靠谱的身份识别应该就是精准广告的核心。

什么是靠谱的身份识别？对微信而言，判断重点活动城市是靠谱的，分析性别也相对靠谱，但如果微信告诉你说能够通过社交判断该用户是中产白领还是乡村农民，那一定是不靠谱的。因为朋友圈里宣称正在法国酒庄旅游的优雅女人或许正在出门买油条豆浆。

有时候用户使用的媒体本身就透露客户的身份特征。比如经常使用理财软件的在支付能力上较为靠谱，而使用孕宝APP的80%以上应该就是准妈妈，经常使用蜜芽的一定是宝宝出生不久的妈妈。有大数据公司给出过案例，对媒体本身进行定向和综合分析定向的效果相差无几，这就说明媒体定向是有效的，但是其它需求定向都等同于随机选择。

由于大数据本身就是不关注因果，只关注相关性，如果经过大数据洞察证实的协同规则，也可以算作靠谱的规则。比如游戏付费用户群基本上可以确定为一两千万ID的重度使用用户。

而要准确识别客户身份，多数据源的汇集与综合不可避免，围绕客户身份的各种洞察、相关性分析也是能力提升的必修功课，这或许更应该是大数据广告公司应持续修炼的核心能力。

所有游戏开发者都应该知道的一些参数

Mon, 28 Sep 2015 22:30:41 CST

我们会觉得手机游戏分析很复杂。当提到参数时。我们需要追踪许许多多的数字。从较为简单的层面看来，存在像下载量，游戏 session 和 DAU 等参数。这些数字多是相对直接的，且能够衡量一些具体行动。而像用户流失率，每付费用户平均收益（ARPPU）和 DAU/MAU 等较复杂参数就不是那么好理解，并且它们也会引出更多问题。如：

“在我考虑一个流失用户前我是否应该先等等看？”

“有效的 ARPPU 是怎样的？”

我们甚至还未提到像市场细分，漏斗和自定义事件等更高级的分析概念。现在我们将只是专注于参数并着眼于这些数字能够告诉你有关游戏的神秘内容。尽管关于游戏分析并不存在完全对策，但是还是存在一些能够帮助你更好地完善自己的手机游戏的有效参数。

每日活跃用户（DAU）

让我们从最基础的开始。DAU 是指在任何一天开始玩你的至少一个游戏回合的用户数。从本身看来，DAU 和其它高级别参数并不能提供给你有关应用表现的相关内容。然而了解这些简单的参数对于任何分析讨论来说都是一个很好的起点。

让我们举个例子来说。例如一款拥有 1 万名忠实用户的硬核游戏。这些用户每天都会玩几次游戏并且都会积极地在游戏中获取赢利。让我们将其与那些拥有 100 万 DAU 但却没有赢利机制的通讯类应用相比较。还有一种应用是运行着用户获取活动但却具有糟糕用户留存的应用。今天它们可能拥有 50 万的 DAU，但是明天可能会降到 10 万。DAU 指数只是一种瞬时的数据，其周围的环境同样也很重要。

session

每次当任何用户（不只是特别的用户）打开你的应用，这便算是一个 session。与 DAU 相似的是，总的 session 数需要一些环境的支持才能构成一个有帮助的数值。例如每 DAU 的平均 session 能够告诉你游戏的用户粘性。

一款应用的类型将会影响它的 session/DAU，就像一些游戏风格拥有更频繁的 session。然而如果用户每天会回到游戏中 5 至 10 次，那么你便可以大胆地说他们喜欢你的游戏。而如果用户每天只会打开游戏1，2 次，那么游戏便很难长久地留住他们的注意力。

DAU/MAU

日活跃用户与月活跃用户间的比例能够告诉你一款应用的用户留存与用户粘性。这一参数能够告诉你用户登录应用的频率。我们可以使用一些例子而更好地讨论这一参数。

让我们假设一款应用拥有 10 万 MAU 以及平均 1.5 万 DAU。所以 DAU/MAU 比例便是 15%。这意味着这个月平均用户每天登录率为 15%。

因为这是一个比例，所以 DAU/MAU 参数只能是 0 至 1 之间的数值。如果数值越接近1，这便意味着用户每天打开应用的次数越多。像 Facebook 等著名的社交网络应用便拥有高达 50% 的 DAU/MAU 比例。但大多数成功游戏的 DAU/MAU 比例只有 20% 左右。

用户留存

用户留存是免费游戏中最重要的参数。成功的免费游戏总是能够与用户维持长久的关系。喜欢拥有更多体验的用户总是愿意为具有竞争性的优势买单。一款想要拥有强大用户留存的游戏需要花更多时间去创造这样的关系。

为了计算用户留存值，你应该从用户下载你的应用那天开始将其划分成不同群组。他们下载应用的那一天算为第 0 天。如果用户隔天打开你的应用（第 1 天），你便可以将其标记为留存。如果他们并未打开应用，他们便是未留存。这种计算方法适合用于计算用户下载完应用后每一天的用户流失情况。而较常出现的用户留存天数是 1 天，3 天，7 天和 30 天。

Skærmbillede (from gamedev)

转换率

让我们转向所有人都很喜欢的一个主题：钱！上述参数都是专注于衡量你与用户之间的关系。他们回到你的应用的频率是怎样的？而对于许多独立开发者而言最重要的参数还是他们的游戏能否赚钱。

转换率能够衡量在所有用户中特定时期内购买了游戏内容的特殊用户的比例。你也可以借此衡量免费游戏中的广告转换率。

让用户在本来能够免费体验的游戏中付钱是一件很困难的事。但与许多其它产业一样，重复购买者也能在免费游戏中创造大量的收益。你可以通过提供给用户具有惊人价值的虚拟道具而促成他们的首次转换。

ARPDAU

每付费用户平均收益（ARPPU）能够衡量那些已经在游戏中完成一次购买的用户子集。基于不同游戏类型，这一参数也会有所不同。就像硬核游戏更倾向于拥有更高的 ARPPU 等参数，但是它们却缺少像休闲游戏所拥有的大众吸引力。

用户流失

用户流失大致上与用户留存相反。有多少下载了你的游戏但却未继续游戏的玩家？在订阅式业务模式中流失参数是很重要的，而当将它与免费游戏联系在一起时便会出现一些细微的差别。

这里的主要考虑因素是用户的游戏风格。基于订阅服务，用户流失非恶即善。不管用户是否是付费用户。在一款免费游戏中，有些用户一天可能会玩多次游戏，而一些更休闲的玩家可能一或两周才会登录游戏一次。为了面对这些玩家间的差异，我们将用户流失限定在那些 28 天内未完游戏的玩家们。

游戏内部的参数

除了理解用户粘性，用户留存以及盈利外，我们还必须衡量并平衡游戏经济。如果赚取虚拟货币太过简单的话，用户也就没有获得盈利的理由了。但是用户仍然需要拥有足够的货币去享受并探索游戏。以下是一些能够帮助玩家找到货币的参数。

资源，槽和流

资源是用户能够赚取虚拟货币的地方。在 GameAnalytics 的控制面板上，资源参数能够衡量用户已经挣得的货币数。这同时也包含作为设计师的你提供给他们的任何货币。

槽与资源相反。在你的游戏中存在一个用户能够消费他们珍贵的货币的地方。而不管是资源还是槽都是关于升水（硬）货币和第二（软）货币。在分析过程中你应该有效区分这些不同类型的货币。

结合资源和槽你便能够获得流。流是指你的玩家所消耗和挣得的货币的总平衡。通常情况下流应该保持稳定，就像如下图表那样。

Skærmbillede (from gamedev)

如果图表像指数曲线那样倾斜向上，这便表示你的玩家基础拥有太多货币并不需要盈利。而如果图表向零倾斜，那就表示你的玩家在游戏中缺少足够的资源。

开始，失败和完成

最后，我们将着眼于一些进程参数。不管用户是否开始一个全新的关卡，许多游戏类型都拥有一个关卡组件。开始能够衡量玩家开始一个全新关卡的次数。

其次是失败。失败总是会在玩家开始一个关卡但却未完成该关卡的时候出现。

而就像你所猜想的那样，完成能够计算用户完成一个特点关卡的次数。尝试所有的这三种参数能够帮助你更好地分析游戏关卡。

Skærmbillede (from gamedev)

你所设置的阻碍是否基于适当的难度？用户是否会出乎意外地被困在一些特定的关卡中？哪个关卡是用户觉得最有趣并最常重复的？开始，失败和完成参数便能够帮助你回答这些问题。

尽管关于游戏分析并不存在任何魔法配方，但是上述参数却能够帮助你在分析世界中迈开脚步。手机游戏分析中最重要的一部分便是开始并为你的游戏确定一个基准。一旦你理解用户的表现，你便能够衡量像游戏更新或者用户获取策略的改变所具有的影响。

【译文】Top 10：HTML5、JavaScript 3D游戏引擎和框架

Wed, 24 Jun 2015 12:13:19 CST

由于很多人都在用JavaScript、HTML5和WebGL技术创建基于浏览器的3D游戏，所有JavaScript 3D游戏引擎是一个人们主题。基于浏览器的游戏最棒的地方是平台独立，它们能在iOS、Android、Windows或其他任何平台上运行。

有很多的JavaScript能够用于创建基于浏览器、使用HTML5和WebGL的3D游戏。然后，选择一个合适的游戏引擎是一个不小的挑战，它有时能帮你完成项目或突破项目瓶颈。

为了让你的选择变的容易，我们已经通过分析大多数JavaScript 3D游戏引擎在今天的市场并列出了十大游戏引擎来帮助您用JavaScript创建非常棒的HTML5,WebGL游戏。

1. Babylon.js

毫无疑问，Babylon.JS是最好的JavaScript3D游戏引擎，它能创建可以出售的专业级游戏。
Babylon.JS是David Catuhe对3D游戏引擎热爱的结果，他在用DirectX, OpenGL, 和Silverlight创建3D游戏引擎方面是经验丰富，并最终自己完成了一个游戏引擎。
Babylon.js的一些核心功能包含了场景图与灯光、摄像机、材料和网格、碰撞引擎、物理引擎、音频引擎和优化引擎。
这是一个 Babylon.js试验场，你可以拿你手边的游戏来试试这个游戏引擎。

2.Three.js

Three.js是另一个广泛应用并且功能强大的JavaScript 3D库，从创建简单的3D动画到创建交互的3D游戏，它都能实现。
Threejs带来的不仅是支持WebGL渲染，也支持SVG、Canvas和CSS3D渲染。然而，从游戏的角度来看，你可以只关注Threejs的WebGL渲染。
获取Three.js 3D引擎的源代码— github

3. Turbulenz

Turbulenz是最好的游戏引擎之一，在2009年，当HTML5和WebGL还在酝酿时，它已经被推出。直到2013年，Turbulenz才基于MIT协议拥抱开源。
Turbulenz包含了很多功能，例如2d物理、3d物理、声音、视频和其他服务,如排行榜、multichat,支付和用户数据。
了解更多： biz.turbulenz.com
获取源代码： turbulenz_engine

4. Famo.us

在HTML5 3D发展的市场中，Famo.us占据了非常重要的地位，并且它是最好的JavaScript 3D开源框架之一。对于famo.us，最好的事情就是包装了3D布局引擎，其完全继承了3D物理驱动的动画引擎。
了解更多— famo.us/docs
获取源代码— famous

5. PlayCanvas.js

PlayCanvas是一个基于 WebGL游戏引擎的企业级开源JavaScript框架，它有许多的开发工具能帮你快速创建3D游戏。PlayCanvas.js由一个专业社区创建，最初并不是开源的，但现在你可以在github上fork PlayCanvas.js，然后在你的下一个3D游戏项目中免费使用。
它还提供了能在浏览器中云心的云编辑器，开始使用PalyCanvas和导航到编辑器的URL一样容易。
了解更多— playcanvas.com
获取源代码— playcanvas/engine

6. Goo Engine

来自于GOO技术家族，Goo引擎有一组功能强大的JavaScript API，可通过使用HTML5和WebGL创建任何3D事物。有一个在线的编辑器goocreate，可以运行在Goo引擎上，并封装了一些功能，例如视觉三维编辑器,材质编辑器、脚本和容易发布选项等。
你可以通过支付一些相关的许可费用，在浏览器中使用在线编辑器。
尽管编辑器需要一些费用，但是Goo引擎是绝对免费的，你可以下载它并在你的3D项目中使用。
了解更多—- labs.gooengine.com
获取源代码— code.gooengine.com

7. CooperLicht

对于创建基于浏览器的游戏，CopperLIcht是最出色的3D引擎之一，也是CopperCube 3D游戏编辑器的后端引擎。
CopperCube是一个支持创建3D游戏和动画所需要的所有功能的编辑器，但是，它并不开源，需要一些相关的许可费用。
了解更多— ambiera.com/copperlicht

8. Voxel.JS

Voxel.Js是开源的，基于JavaScript的一个3D游戏引擎，自从它发布以来，社区成长非常快。如果你喜欢模块化方法，Voxel是一个不错的选择。
Voxel-engine是创建3D游戏的核心模块，其它模块可以根据需要插入。到目前为止，已经有超过200个扩展在npm上发布。
了解更多— maxogden/voxel-engine

9. Blend4Web

在2014年，Blend4Web作为开源的3D框架而发布，它高度集成了Triumph的3D内容创建工具“Blender”，并且本地支持Blender的节点材料、粒子系统、bullet物理引擎和其他功能。
获取源代码— blend4web.com/en/downloads

10. Enchant.js

Enchant.js是一个模块化的、面向对象的JavaScript框架，可用HTML5创建简单的APP和游戏。它是基于MIT协议开源的，因此开源免费使用。3D动画和游戏开源使用额外的插件（基于WebGL）创建。
获取源代码– wise9/enchant.js

本文根据@Nicolas Bevacqua的《best-3d-javascript-game-engines-frameworks-webgl-html5》所译，整个译文带有我自己的理解与思想，如果译得不好或有不对之处还请同行朋友指点。如需转载此译文，需注明英文出处： http://noeticforce.com/best-3d-javascript-game-engines-frameworks-webgl-html5

淡忘~浅思猜你喜欢
怎么对HTML 5的特性做检测？	HTML 5：绘制旋转的太极图	【译】利用HTML 5中的Menu和Menuitem元素快速创建菜单	初识HTML 5：关于它的三个三	HTML 5 API的”前生今世”
无觅

转载请注明：淡忘~浅思 » 【译文】Top 10：HTML5、JavaScript 3D游戏引擎和框架

移动游戏流失用户预测

Sat, 13 Jun 2015 02:13:51 CST

随着游戏市场竞争的日趋激烈，越来越多的游戏运营服务选择借助大数据挖掘出更多更细的用户群来进行精细化，个性化运营，从而更好的抓住用户，获得更大的收益。在游戏运营中，无论是流失挽留，还是拉新，以及付费用户预测都是游戏运营的重要内容。

本文将着重介绍手游用户的流失预测。对于游戏运营者，如果能够尽早的发现可能流失的用户，尽早的有针对性的对这些用户进行适当的干预，从而最大限度的延长用户在游戏中的停留时间，使得游戏运营者获得更大的收益。

本文中介绍的手游流失预测主要依托于腾讯信鸽这个平台，为这个平台提供精准定位即将流失用户的功能。腾讯信鸽是专业的移动应用推送平台，支持百亿级的通知/消息秒级触达移动用户。开发者可以方便地通过嵌入SDK，通过API调用或者Web端可视化操作，实现对特定用户发送通知/消息，提升用户活跃度，挽回潜在流失用户，并实时查看推送效果。我们在这三面都有深入研究，取得了不错的效果。

需求的挑战

1. 海量的用户行为

目前该套流失预测系统，每天最高时承接着480亿条上报的用户行为记录。

2. 海量的用户

在已经接入的游戏中，每天活跃着一亿左右的用户。

3.模型的通用性

流失预测的实际应用中，不仅仅包含了公司内的游戏，还有公司外的游戏，以及各种各样的应用。每个应用上报的自定义事件更是各不相同，但算法还要统一接入。

4.应用接入压力

目前实际已经介入100多款公司内游戏应用，几乎囊括了公司内大部分主力手机游戏，包括《天天炫斗》，《天天德州》等。

鉴于上述的挑战性，结合了腾讯大数据精准推荐平台以“数据+算法+系统”的3方面打法，我们针对手游也总结了一套通用的业务流失预测模型。

系统–TRC平台

TRC的全称是Tencent Real-time Computing，是大数据精准推荐平台专为海量数据实时处理而构建的提供基础计算能力的服务平台，从全流程的实时计算体系的角度看，整个TRC由核心的平台支撑层和扩展的平台应用层构成。

平台支撑层主要包括实时数据接入、实时数据处理、实时数据存储；平台应用层主要包括实时算法预测，实时模型训练，实时效果统计，实时系统监控实时数据展示。总体结构如所示：

TRC平台经过两年多的现网运营，已经逐步成熟稳定，该平台每天支撑公司2,000多亿实时数据接入，每天26,000多亿次实时计算，每天5,000多亿次数据访问，已经在广点通广告推荐，电商物品推荐，视频推荐，新闻推荐，微信业务性能监控并实时统计等产品中大规模使用。

数据

在机器学习，算法建模中，数据是输入，也是起点。数据的质量的高低，优劣，将直接影响着最终的算法效果。对于数据的研究和分析，往往耗费了研究者大量的时间和精力。

在流失预测模型运用到的数据中，存在着优势和劣势。

优势是数据量大，每天高达百亿级别的用户行为记录，日活跃一亿左右用户。并且有着丰富的用户行为。比如，登录，打怪，升级，加血，得分，领取金币等，还有着更为丰富的各个游戏，应用的自定义事件。

劣势也非常明显。虽然行为丰富，但是每个应用上报的具体数据内容无法规范统一，特别是自定义事件更无法控制，同时，还要达到无论是公司内部手游，外部手游，还是各类应用都要模型通用，只能从这众多丰富的数据中抽取它们共性的且有效的特征。

在本算法中，考虑到，通用性，有效性，并且易拓展性，具体抽取的特征有：登录天数，登录频次，最后登录时间，登录时长，等级等特征。

算法

在本次流失预测的建模中，采用了LR模型。在这里简单介绍一下LR模型。Logistic regression （逻辑回归）是当前业界比较常用的机器学习方法，用于估计某种事物的可能性。比如某用户购买某商品的可能性，某病人患有某种疾病的可能性，以及某广告被用户点击的可能性等。

Logistic回归为概率型回归模型，是研究分类观察结果y与一些影响因素x（单变量，多变量都可以）之间关系的一种分析方法。

在流失预测模型中，具体输入的用户特征为登录天数，登录频次，最后登录时间，登录时长，目前等级等特征，输出为用户的流失可能性。同时，通过算法的结果的准确率，和召回率来评价算法效果。

流失预测的整体流程如所示，从公司内外部游戏以及各类应用中抽取各类用户，日常的登录天数，登录频次，最后登录时间等特征，以及最后的流失状况，来训练LR模型。然后根据每天用户相应特征，使用训练好的模型来进行预测，得到最可能流失的用户。

算法效果

基于玩家的在线时长，使用频率等特征，建立流失用户预测模型，精准预测潜在流失用户。在公司外游戏《美人国》的ABTest中，预测覆盖率超过85%，准确率超过91%。利用信鸽对该用户群推送针对性的营销活动，回流率比随机推送提升120%。

在腾讯内部XX游戏的ABTest中，我们的算法的预测覆盖率达到79.847%，准确率达到85.646%。利用信鸽对该用户群推送针对性的营销活动，回流率比随机推送提升326%。通过实践证明：充分利用大数据的优势，帮助游戏大幅提升玩家留存率，同时减少对玩家的骚扰，保障用户体验。

游戏市场的竞争日趋激烈，新游戏产品增速逐渐放缓，越来越多的游戏运营开始借助于大数据，机器学习，来挖掘出更多更细的用户群，从而更有针对性的进行运营活动，能够帮助游戏大幅提升玩家留存率，减少对玩家的骚扰，保障良好的用户体验。

via：腾讯信鸽

您可能也喜欢的文章：
ESA：三分之一的美国用户在移动设备上玩游戏	腾讯移动游戏用户	Flurry：2011年美国移动用户有47%的时间花在游戏应用上	新闻晨报：2013年上海移动游戏用户达1874万人 4年增长9倍有余	CESA：2014年日本高粘度智能移动终端游戏用户达2672万人
无觅

如何让玩家相信游戏是公平的

Mon, 10 Feb 2014 11:28:49 CST

去赌场参观过的同学应该都见过那种押大小的骰子游戏。庄家投掷三枚骰子，把骰盅盖住，玩家可以押大或小。开盅后，如果发现三个数字之和大于等于 11 就算大，小于等于 10 就算小。如果你猜对了，庄家就 1 赔 1 算给你筹码；否则输掉筹码。另外，还可以以不同赔率压数字，或压三个相同。

为了保障庄家利益，三个相同的数字算不大不小。从概率上讲，这让长时间内庄家必胜。概率分析见这里。

如果把这个游戏搬到网络上如何呢？（注意：网上赌博在很多国家是被禁止的，这里只做技术分析而已）

如何让玩家相信庄家没有作弊，真的产生了随机的骰子呢？

记得网易泡泡曾经在聊天室中做过一个简单的赌大小的文字游戏。我一同学兴致勃勃的玩过，他告诉我系统一定作弊过的。他写了个程序监控每局游戏开盅前的下注情况，到最后一秒再下住，永远下注少的一边（也就是跟庄），只花了一天时间就刷了无数泡泡币。

其实这只是游戏实现者的贪心和无知而已。其实这个游戏的规则保证了庄家利益，庄家没有必要作弊。但有些游戏设计者就是脑子转不过弯来，的确考虑过作弊。不是连六合彩这种极大化庄家利益的游戏规则都有流言暴出庄家作弊么？

那么，是不是网络版的赌大小一定得不到玩家信任呢？

其实有一个简单的方法可以向玩家证明骰子的随机性：

每局游戏前，先随机三个 1-6 的数字，并同时生成三个足够长（比如 80 字符, 长度在屏幕方便显示的范围即可）的文本随机串，把数字附在随机串的两端。比如随机出 2,4,5 这三个数字，就同时生成形如 2xxxxxxxxxxxxxxx2 , 4xxxxxxxxxxxxxxx4, 5xxxxxxxxxxxxxxx5 (xxxx 每次随机) 的字符串。计算这三个字符串的 md5 值，并事先通过网络展示给玩家。
玩家收到三个秘密串后开始下注。下注时间有限，只有几分钟的时间。由于 md5 的不可逆性，在这么短时间内，不可能知道串的原文。注：网络上所谓的 md5 破解，都是基于收集有意义的字符串的 md5 值构成海量的数据库比对查找的，并非对 md5 结果做逆运算。纯随机串的 md5 值不可能在很短时间求逆。
下注时间过了后，系统通过网络公布事先的三个随机数字构成的随机串，也就相当于开盅。这时候，玩家应该认赌服输了。如果他认为系统作弊，可以自行校验系统公布的串的 md5 值是否和事先公开的值相等。

如此便可证明，骰子是在玩家下注前就确定下来的，而不是根据玩家下注的行为更改让庄家获利。

没错，现在有数学证明可以在有限时间构造出另一个符合规则的串有相同的 md5 值。但那也需要相当的计算能力。如果这个网上赌场开的时间足够长，是没有那么多计算能力支撑长期的作弊的。之所以不必选用可能更安全的同类算法，是因为 md5 的普及率和认知程度最高，计算工具也随手可得而已。

如果想进一步提高信任度，让玩家相信没有提前计算出 md5 碰撞值，可以在随机的 xxxxx 中进一步加上上一局游戏的骰子 md5 值，让每次随机量都是和上一次相关的。甚至可以加上上一局游戏参与玩家的赌注金额。这样几乎不可能提交计算某一次游戏的随机串的 md5 碰撞。

关于 MD5 的碰撞构造，多个 md5 chunk 比单个 chunk 要容易的多。单 chunk 的碰撞构造在 2012 年的这篇 paper Single-block collision attack on MD5 中提到的方法的计算复杂度在 2 的 50 次方 MD5 运算量级。不是现在普通的计算机计算能力所能承受的。

虽然不是所有玩家都可以理解这个规则，但规则容易直接在游戏中公示。服务器记录所有历史的数据供玩家备查。还是很容易取得玩家群体的信任的。

开源项目CodeCombat：玩游戏就能学会编程

Tue, 11 Mar 2014 21:54:56 CST

CodeCombat是一个通过玩游戏来学习编程的网站，也是GitHub上最大的开源CoffeeScript（一种脚本语言，类似JavaScript）项目，有上千程序员和玩家为其编写程序、测试游戏。到目前为止，已经翻译成17种国外语言。最近，该网站将所有源代码提交到GitHub上，实现了全面开源。

官方称，他们网站的任务就是教会人们如何编程，游戏覆盖编程菜鸟到大神各个阶段，总共超过9千关。人们不需要任何编程知识即可了解程序的运行逻辑，并编出实用的代码。

看起来像是塔防游戏——《王城保卫战》，但却是一款即时战略游戏。

每关都会有对话讲解如何操作（遗憾没有中文）

左侧是游戏界面，右侧是代码界面，通过在右侧输入关键语句代码，控制左侧角色的移动和攻击等动作。

前几关非常简单，几行“上下左右”和“攻击”的代码即可完成通关。

每关结束后都有个回顾，告诉你在上一关学到了什么。

当输入错误，比如大小写错误，在代码下方会提示具体的出错信息，玩家可以据此Debug。

第二关中，你要先去右边吃蘑菇变强，再去击杀怪物。（点击图片查看具体代码，其实向右移动一步即可迟到蘑菇，代码中是两步）

第三关，在击杀第一个怪物后，角色的血也不多了，所以要先去下方喝药瓶。

下去喝药瓶，输入代码按回车，角色就会照做。

第四关

前N关都是编程中最基本的顺序语句，随着关数的提升，像“if…else，then”等判断、循环语句也会逐渐加入，可玩性越来越高。玩家在不知不觉也就具备了编程思维。

网站地址： http://codecombat.com/

摩托罗拉千元机Moto G实际使用速度竟然比Galaxy S4还快？！

Tue, 19 Nov 2013 17:42:32 CST

据摩托罗拉移动技术亚太区PR经理@司轩军透露，在摩托罗拉Moto G的巴西发布会上，摩托罗拉官方PPT号称，售价不到1100元的Moto G速度竟然比三星顶级旗舰手机Galaxy S4快！我们来看看是怎么一回事。
摩托罗拉千元机Moto G实际使用速度竟然比Galaxy S4还快？！
据称，运行最纯粹原生安卓系统、不添加任何皮肤和UI插件的MOTO G，启动速度比普通的三星Galaxy S4快5.3秒，接听电话快1.2秒，拨打电话快1.1秒，启动浏览器快0.5秒，回到Home主页快0.5秒。
当然，这里的前提是Moto G运行原生系统，并且不添加任何皮肤和UI插件的状态下。

Oculus Rift ：开拓虚拟现实新时代

Fri, 24 Jan 2014 09:03:50 CST

Oculus Rift 是一款激动人心的设备。它不仅仅有改变视频游戏界的潜力，而且有可能打开虚拟现实的新时代，使人们以新的方式进行各种交互，玩游戏、在线教育，甚至畅游互联网，都会有一种完全不同的面貌。这令人兴奋，同时也有一丝隐隐的不安。全球最顶尖的游戏公司之一 Valve 已经表示了对 Oculus Rift 的支持，而它看重的不仅仅是游戏方面，而且包括它在内容交互方面的巨大潜力。

虚拟现实技术并不是首次出现，但是过去技术不够发达，无法提供好的体验，逐渐沉寂了下来。Oculus Rift 的出现，再次引发了人们的热情。许多开发者都在积极探索它的各种可能性。最近，卫报对几位开发者进行了采访。

开发者 Daniel Ernst 曾制作过 Rift 平台的游戏演示，现在在开发一款冒险类的游戏。在他看来，虚拟现实游戏中，细节是最关键的部分。“在传统的游戏中，场景中的微小细节并不重要。你无需去注意书架上摆放图书的名称，或者桌子上的一张纸写了什么。在你和场景之间总是有距离。在 Oculus Rift 上，你没有这种距离。东西可能在你面前几英寸，如果纹理模糊或者像素化，就会破坏到沉浸式的体验。在 3D 世界中模拟物品之前，你必须去做些测量。你甚至会注意到，电话是否增大了几英寸。”

有趣的是，这种沉浸式的体验，与主流游戏的一些设计是对立的。在射击游戏中，玩家处于不断的运动之中，因为我们对所处空间没有物理感。在虚拟现实世界中，我们可能花上更多的世界去探索。“我们发现，大多数的玩家在虚拟现实中的行为不同，” 冰岛游戏公司 Aldin Dynamics 的联合创始人 Hrafn Thorri Thorisson 说，“当你处于虚拟世界，而非观看普通显示器的时候，会有一种强烈的冲动去探索和观察。”

Bossa Studio 曾开发过一款很成功的外科医生模拟游戏，如今，Henrique Olifier 负责把游戏移植到 Oculus Rift。在他看来，虚拟现实游戏在交互上有独特的规则，“例如，你不能在虚拟现实游戏中使用抽象的界面，信息必须在世界本身展现。你需要避免一些不是由玩家激发的动作，比如摄像头的摆动，因为那样会给人带来不适。你必须抛弃不自然的动作，比如向后跑或者横向扫射——第一人称射击游戏的标志性动作。现在还没有虚拟现实游戏开发方面的手册，因此，在我们创造出色游戏之前，还有很多的东西要学习。”

如果虚拟现实技术只是用于游戏中，或许将会沦为小众产品，但是，它在其他领域的潜力同样值得注意。我们或许会看到一些在线商店开始使用虚拟现实技术。“我们和一些品牌接触，提到把虚拟现实作为购物体验的一部分，”Opposable Games 的 Ben Trewhella 说，“用户不再去看浏览器上一格格的物品，而是走进虚拟商店，与正常购物的时候一样浏览商品。要做到这一点，需要做许多基础工作，但是我相信，这种技术能够很快融入到在线的时尚商店中。”

Urban Logic 公司的 Brad Jeffrey 看好虚拟现实在互动教育上的潜力。“学生们可以在某种情节中体验自己所学的东西，或者看到一些现实中都难以观察到的 3D 展示。想象一下，在旋转的氢原子中行走，或者访问重要的历史场景再现。这比我在学校体验的任何事情都吸引人。”

游戏设计师 Sawkins 谈到，有些人在考虑用 Oculus Rift 帮助残疾孩子，让他们也能获得新奇的体验，比如攀登喜马拉雅山。“这是一个非常出色的想法，而且我真诚地希望它能够实现。我告诉他们，要思考的更远一些。你可以把人们带到马里亚纳海沟的底部，飞跃大峡谷，访问阿波罗 11 号登月地点，访问火星——可能性是无穷无尽的。Scott Adams 曾经写到，‘全息甲板’将是人类最后一项发明。我开始觉得他可能是正确的。”

一开始的时候，虚拟现实会是铁杆玩家们的钟爱，使用在动作游戏和恐怖游戏中，但在未来的某一天，它或许会完全改写人机交互的界面。William Gibson 曾把互联网想象为一个虚拟空间，可以亲身进行探索的地方，Oculus Rift 或许能够实现他的想象。“长久以来，我都在等待互联网变得更加空间化”，德国游戏工作室 Duangle 的 Leonard Ritter 说，“我想象着，网络服务器上放置着各种空间而不是站点，这些不相干的空间组成了一个奇特的混合体。人们访问它们的工具，将是虚拟现实技术中对浏览器的替代品。《第二人生》是一次漂亮的演示，展示了这样的空间应该是怎样的，但那不是一个去中心化的地方。我想要看到这一切的实现。”

图片来自 businessinsider

积木

May the road rise up to meet you. May the wind always be at your back. May the sun shine warm upon your face, and rains fall soft upon your fields.

邮箱 Twitter 新浪微博 Google+

#欢迎关注爱范儿认证微信公众号：AppSolution（微信号：appsolution），发现新酷精华应用。

爱范儿 · Beats of Bits | 原文链接 · 查看评论 · 新浪微博 · 微信订阅 · 加入爱范社区！

Pixel light 中的场景管理

Mon, 14 Jan 2013 17:48:39 CST

这几天无意中发现一款开源的 3d engine ，名为 pixel light 。文档虽然不多，但写的很漂亮。从源码仓库 clone 了一份，读了几天，感觉设计上有许多可圈可点的地方，颇为有趣。今天简略写一篇 blog 和大家分享。

ps. 在官方主页上，pixel light 是基于 OpenGL 的，但实际上，它将渲染层剥离的很好。如果你取的是源代码，而不是下载的 SDK 的话，会发现它也支持了 Direct3D 。另，从 2013 年开始，这个项目将 License 改为了 MIT ，而不是之前的 LGPL 。对于商业游戏开发来说，GPL 的确不是个很好的选择。

这款引擎开发历史并不短（从 2002 年开始），但公开时间较晚（2010 年），远不如 OGRE 等引擎有名。暂时我也没有看到有什么成熟的游戏项目正在使用。对于没有太多项目推动的引擎项目，可靠性和完备性是存疑的。不推荐马上在商业游戏项目中使用。但是，他的构架设计和源代码绝对有学习价值。

对于 3d 游戏这种技术演化迅速，需求多变的领域。我的个人看法是，越晚起步的引擎有更少的历史包袱，通常会比历史悠久的 engine 更清爽一些（虽然历史悠久的 engine 可能要结实一点）。

这次仅谈谈 pixel light 中的场景管理部分。

Pixel Light 中和 3d 渲染有关的类分落在 PLRenderer PLMesh PLScene 三个模块中。从名字上就可以了解，PLRenderer 主要承担系统 API 的接口粘合层；而 PLMesh 负责单个模块的渲染，包括和模块相关的骨骼动画的数据维护；而 PLScene 则负责把多个模块联系起来。

还有一些底层辅助模块，比如 PLMath 进行数学运算，PLGraphics 处理图片。上层的图形界面由 PLGui 承担，物理系统则是 PLPhysics 。

其中最难设计的莫过于场景管理。到底哪些东西是属于它的管理范畴，该如何组织，都是个难题。

Pixel light 中，和绝大多数 3d engine 的场景管理方式一样，所有的物件都是以场景节点 scene node 的形式存在于若干个场景树中。它没有给出所谓世界坐标空间，因为现在很多游戏的场景都做的非常巨大，需要动态组建。

scene node 都是场景树上的叶结点，只有 scene container 才可以组合其它 scene node 。这点和其它一些 engine 的设计有些许不同。对于场景元素，比如 mesh ， light 等等，是从 scene node 对象继承下来的类，而不是附着（ attach ）在 scene node 上。这决定了，scene container 节点一定是一个纯粹的容器，一切可能参与渲染的实际元素都处于叶节点上。

Scene container 类的公开方法中，只有 Create 方法，而不能把已存在的 scene node 挂接到容器中。也就是说，你无法把一个 scene node 从容器中取出来，然后放到另一个容器中。这在一定程度上简化了 scene node 的生命期管理。也不太会在 scene node 间发生不合法的引用关系。

场景树在一定程度上描述了空间层次关系，在渲染流程中，每个 scene container 会影响子节点的空间状态（位置、旋转、缩放）。同时，也影响渲染行为，比如，SCRenderToTexture 就是一种特殊的容器，放在这个容器中的元素都会被渲染到一张贴图上。

游戏中对可渲染物件的空间管理，从性能因素考虑，仅仅依靠场景树的层次来管理是远远不够的。当我们需要和 3d 场景中的物件交互，从镜头中选取某个物件。渲染场景时，需要剔除不可见的物件。这些，依赖简单的 scene node 的层次管理是很低效的。Pixel light 引入了 Scene Hierarchy 来用不同的算法管理空间层次。每个容器可以根据需要有不同种类的 Hierarchy （简单的链表结构，或是复杂的 K-D 树）。

那么，针对 scene container 的处理过程，Pixel light 把它们称之为 Scene Query 。从字面上的理解，就是对一个 Scene （以某个 scene container 为根）所有节点的选取过程。Scene Query 的基类仅仅定义了对 scene container 一种操作方式，对其中符合要求的节点唯一的发出一个 touched 的信号。从这个意义来说，渲染本身也含有一个 query 过程。遍历一个 container ，touch 可视节点。这些被实现在 SQCull 类中。

容器的存在本身是由于 Query 的需求存在（Container 是 Query 操作的对象），其中 scene renderer 也是一种 query 。和直觉不一样，我们通常不会利用 scene node 的树层次关系来组织可渲染物件的空间关系。例如，一块面包放在桌子上，我们不必让面包挂在桌子上。面包和桌子都属于同一个容器。如果它们真的有从属关系的话，也仅存在于场景编辑器中。同样，即使是做第一人称视角的游戏，摄像机对象也不需要在 scene node 的层次是归属于主角模型。它应该和主角模型在同一个 scene container 中。

那么，总存在有一些需求，某些 scene node 的空间关系和另一个 node 有关。一个节点动了，另一个应该跟着移动，等等。这些相互关系甚至很难用树结构去表达。在 Pixel light 中，解决这一问题的方法是叫做 scene node modifier 的东西。每个节点可以有多个 modifier ，这些 modifier 会根据需要改变 node 的状态。modifier 可以利用物理系统作用于结点，可以让模型播放动画，也可以容一个结点随另一个运动。

比如让摄像机跟随一个节点，只需要在跟随节点上添加一个 SNMAnchor ，然后设置它的 AttachedNode 属性为摄像机节点。这样当跟随节点的坐标变化时，会自动修改摄像机的坐标。SNMAnchor 只能让同一个容器内的两个 scene node 相互起作用，也不能产生有循环引用的关系。这一切基于 Event 机制起作用的，在 Pixel light 里 Event 并没有放在一个消息队列中，而是在 Signal 发生时，Event 立刻传递到 Slot 中产生一次函数调用。

如果想把一把剑挂接在人物模型的手上，同样可以利用 SNMAnchor 。除了设置 AttachedNode 属性外，还需要设置 SkeletonJoint 属性为骨骼数据中的手这个关节。这一切通过名字字符串来耦合。

手游圈2012年终总结之91无线胡泽民：Android与iOS差距减小

Tue, 25 Dec 2012 16:51:17 CST

转眼间已经由2012年中到了年终，年中的时候触控的陈昊芝曾在CGDC中的演讲就提到在今年Q3,Android平台有望超越iOS，而到了年终，日前在第七届移动游戏产业高峰论坛上，91无线CEO胡泽民则对今年移动游戏的变化发表了总结演讲。虽然两个不同时间，站在不同角度的业者做出的数据分析出入颇大，但对趋势变化还是有不少相似之处，究竟从一个游戏平台的角度又是怎么看这两年移动游戏圈的，看看就知道了。

12年总结：

11月91平台游戏类月收入超过3500万，是去年同期的10倍。
11年Q4到12年Q3，91游戏应用的数量由7万上升到17万。而开发的数量增长则超过300%。
终端的数量增长依然很快，10年是1800万，11年时5200万，12年估计是2.6亿，增速由3倍提到了5倍。
终端性能走高端趋势，大屏幕、1G至1.5G的终端的增长速度在12年增长明显加快。
WIFI使用率明显提高，11年的8%在12年增长到40%
玩家平均每次游戏时间在1-10分钟的占80%，但一天能玩十几次。中午和下午四点以后最多人玩。
Android的付费增长迅速，11年是iOS的25%-33%，现在则是60%-70%。
格斗游戏增速快，但是量不高，玩家黏度差，休闲游戏下载稳定，量也高，棋牌和益智玩家黏度最好。
Android手机的游戏平均量是6款，iOS手机则是11款，差距在逐渐缩短。
Android设备预置的游戏启动次数低至一两次的游戏占70%，每天打开5次以上的占8%
玩家地域分布接近传统MRPG，以广东、江浙、上海、北京为主，广东最多，按顺序减少。

13年展望：

预计移动终端数量最少到3.6—4亿。
3D游戏会爆发,LBS的创意游戏值得考虑。
三国题材已经过多，期待新题材游戏，例如武侠小说（小编心中默念+10086）。
第一人称射击FPS类值得关注，期待第一个手机上的穿越火线出现。
跨平台、社交主题依然是热点。

由超好玩特约编辑@某路痴整理。

（若无特别注明，雷锋网文章皆为原创，转载请注明出处)
原文链接: http://www.leiphone.com/91mobile-2012final.html

Sgot @雷锋网

爱ACG，爱趣闻八卦，更爱八卦美女，唯独不爱节操。科技以人为本，人为乐趣而活，因为，科技是为了搞出乐趣而存在的。

JavaScript 游戏中的面向对象的设计

Tue, 25 Dec 2012 11:52:35 CST

来源： IBM developerworks

简介： 从程序角度考虑，许多 JavaScript 都基于循环和大量的 if/else 语句。在本文中，我们可了解一种更聪明的做法 — 在 JavaScript 游戏中使用面向对象来设计。本文将概述原型继承和使用 JavaScript 实现基本的面向对象的编程 (OOP)。学习如何在 JavaScript 中使用基于经典继承的库从 OOP 中获得更多的好处。本文还将介绍架构式设计模式，来展示了如何使用游戏循环、状态机和事件冒泡 (event bubbling) 示例来编写更整洁的代码。

在本文中，您将了解 JavaScript 中的 OOP，来探索原型继承模型和经典继承模型。举例说明游戏中能够从 OOP 设计的结构和可维护性中获得极大利益的模式。我们的最终目标是让每一块代码都成为人类可读的代码，并代表一种想法和一个目的，这些代码的结合超越了指令和算法的集合，成为一个精致的艺术品。

JavaScript 中的 OPP 的概述

OOP 的目标就是提供数据抽象、模块化、封装、多态性和继承。通过 OOP，您可以在代码编写中抽象化代码的理念，从而提供优雅、可重用和可读的代码，但这会消耗文件计数、行计数和性能（如果管理不善）。

过去，游戏开发人员往往会避开纯 OOP 方式，以便充分利用 CPU 周期的性能。很多 JavaScript 游戏教程采用的都是非 OOP 方式，希望能够提供一个快速演示，而不是提供一种坚实的基础。与其他游戏的开发人员相比，JavaScript 开发人员面临不同的问题：内存是非手动管理的，且 JavaScript 文件在全局的上下文环境中执行，这样一来，无头绪的代码、命名空间的冲突和迷宫式的 if/else 语句可能会导致可维护性的噩梦。为了从 JavaScript 游戏的开发中获得最大的益处，请遵循 OOP 的最佳实践，显著提高未来的可维护性、开发进度和游戏的表现能力。

原型继承

与使用经典继承的语言不同，在 JavaScript 中，没有内置的类结构。函数是 JavaScript 世界的一级公民，并且，与所有用户定义的对象类似，它们也有原型。用 new 关键字调用函数实际上会创建该函数的一个原型对象副本，并使用该对象作为该函数中的关键字 this的上下文。 清单 1 给出了一个例子。

清单 1. 用原型构建一个对象

// constructor function
function MyExample() {
  // property of an instance when used with the 'new' keyword
  this.isTrue = true;
};

MyExample.prototype.getTrue = function() {
  return this.isTrue;
}

MyExample();
// here, MyExample was called in the global context, 
// so the window object now has an isTrue property—this is NOT a good practice

MyExample.getTrue;
// this is undefined—the getTrue method is a part of the MyExample prototype, 
// not the function itself

var example = new MyExample();
// example is now an object whose prototype is MyExample.prototype

example.getTrue; // evaluates to a function
example.getTrue(); // evaluates to true because isTrue is a property of the 
                   // example instance

依照惯例，代表某个类的函数应该以大写字母开头，这表示它是一个构造函数。该名称应该能够代表它所创建的数据结构。

创建类实例的秘诀在于综合新的关键字和原型对象。原型对象可以同时拥有方法和属性，如 清单 2 所示。

清单 2. 通过原型化的简单继承

// Base class
function Character() {};

Character.prototype.health = 100;

Character.prototype.getHealth = function() {
  return this.health;
}

// Inherited classes

function Player() {
  this.health = 200;
}

Player.prototype = new Character;

function Monster() {}

Monster.prototype = new Character;

var player1 = new Player();

var monster1 = new Monster();

player1.getHealth(); // 200- assigned in constructor

monster1.getHealth(); // 100- inherited from the prototype object

为一个子类分配一个父类需要调用 new 并将结果分配给子类的 prototype 属性，如 清单 3 所示。因此，明智的做法是保持构造函数尽可能的简洁和无副作用，除非您想要传递类定义中的默认值。

如果您已经开始尝试在 JavaScript 中定义类和继承，那么您可能已经意识到该语言与经典 OOP 语言的一个重要区别：如果已经覆盖这些方法，那么没有 super 或 parent 属性可用来访问父对象的方法。对此有一个简单的解决方案，但该解决方案违背了 “不要重复自己 (DRY)” 原则，而且很有可能是如今有很多库试图模仿经典继承的最重要的原因。

清单 3. 从子类调用父方法

function ParentClass() {
  this.color = 'red';
  this.shape = 'square';
}

function ChildClass() {
  ParentClass.call(this);  // use 'call' or 'apply' and pass in the child 
                           // class's context
  this.shape = 'circle';
}

ChildClass.prototype = new ParentClass(); // ChildClass inherits from ParentClass

ChildClass.prototype.getColor = function() {
  return this.color; // returns "red" from the inherited property
};

在 清单 3 中， color 和 shape 属性值都不在原型中，它们在 ParentClass 构造函数中赋值。 ChildClass 的新实例将会为其形状属性赋值两次：一次作为 ParentClass 构造函数中的 “squre”，一次作为 ChildClass 构造函数中的 “circle”。将类似这些赋值的逻辑移动到原型将会减少副作用，让代码变得更容易维护。

在原型继承模型中，可以使用 JavaScript 的 call 或 apply 方法来运行具有不同上下文的函数。虽然这种做法十分有效，可以替代其他语言的 super 或 parent，但它带来了新的问题。如果需要通过更改某个类的名称、它的父类或父类的名称来重构这个类，那么现在您的文本文件中的很多地方都有了这个 ParentClass 。随着您的类越来越复杂，这类问题也会不断增长。更好的一个解决方案是让您的类扩展一个基类，使代码减少重复，尤其在重新创建经典继承时。

经典继承

虽然原型继承对于 OOP 是完全可行的，但它无法满足优秀编程的某些目标。比如如下这些问题：

● 它不是 DRY 的。类名称和原型随处重复，让读和重构变得更为困难。

● 构造函数在原型化期间调用。一旦开始子类化，就将不能使用构造函数中的一些逻辑。

● 没有为强封装提供真正的支持。

● 没有为静态类成员提供真正的支持。

很多 JavaScript 库试图实现更经典的 OOP 语法来解决上述问题。其中一个更容易使用的库是 Dean Edward 的 Base.js（请参阅参考资料），它提供了下列有用特性：

● 所有原型化都是用对象组合（可以在一条语句中定义类和子类）完成的。

● 用一个特殊的构造函数为将在创建新的类实例时运行的逻辑提供一个安全之所。

● 它提供了静态类成员支持。

● 它对强封装的贡献止步于让类定义保持在一条语句内（精神封装，而非代码封装）。

其他库可以提供对公共和私有方法和属性（封装）的更严格支持，Base.js 提供了一个简洁、易用、易记的语法。

清单 4 给出了对 Base.js 和经典继承的简介。该示例用一个更为具体的 RobotEnemy 类扩展了抽象 Enemy 类的特性。

清单 4. 对 Base.js 和经典继承的简介

// create an abstract, basic class for all enemies
// the object used in the .extend() method is the prototype
var Enemy = Base.extend({
    health: 0,
    damage: 0,
    isEnemy: true,

    constructor: function() {
        // this is called every time you use "new"
    },

    attack: function(player) {
        player.hit(this.damage); // "this" is your enemy!
    }
});

// create a robot class that uses Enemy as its parent
// 
var RobotEnemy = Enemy.extend({
    health: 100,
    damage: 10,

    // because a constructor isn't listed here, 
    // Base.js automatically uses the Enemy constructor for us

    attack: function(player) {
        // you can call methods from the parent class using this.base
        // by not having to refer to the parent class
        // or use call / apply, refactoring is easier
        // in this example, the player will be hit
        this.base(player); 

        // even though you used the parent class's "attack" 
        // method, you can still have logic specific to your robot class
        this.health += 10;
    }
});

游戏设计中的 OOP 模式

基本的游戏引擎不可避免地依赖于两个函数： update 和 render。 render 方法通常会根据 setInterval 或 polyfill 进行 requestAnimationFrame，比如 Paul Irish 使用的这个（请参阅参考资料）。使用 requestAnimationFrame 的好处是仅在需要的时候调用它。它按照客户监视器的刷新频率运行（对于台式机，通常是一秒 60 次），此外，在大多数浏览器中，通常根本不会运行它，除非游戏所在的选项卡是活动的。它的优势包括：

● 在用户没有盯着游戏时减少客户机上的工作量

● 节省移动设备上的用电。

● 如果更新循环与呈现循环有关联，那么可以有效地暂停游戏。

出于这些原因，与 setInterval 相比， requestAnimationFrame 一直被认为是 “客户友好” 的 “好公民”。

将 update 循环与 render 循环捆绑在一起会带来新的问题：要保持游戏动作和动画的速度相同，而不管呈现循环的运行速度是每秒 15 帧还是 60 帧。这里要掌握的技巧是在游戏中建立一个时间单位，称为 滴答 (tick)，并传递自上次更新后过去的时间量。然后，就可以将这个时间量转换成滴答数量，而模型、物理引擎和其他依赖于时间的游戏逻辑可以做出相应的调整。比如，一个中毒的玩家可能会在每个滴答接受 10 次损害，共持续 10 个滴答。如果呈现循环运行太快，那么玩家在某个更新调用上可能不会接受损害。但是，如果垃圾回收在最后一个导致过去 1 个半滴答的呈现循环上生效，那么您的逻辑可能会导致 15 次损害。

另一个方式是将模型更新从视图循环中分离出来。在包含很多动画或对象或是绘制占用了大量资源的游戏中，更新循环与 render 循环的耦合会导致游戏完全慢下来。在这种情况下， update 方法能够以设置好的间隔运行（使用 setInterval），而不管 requestAnimationFrame 处理程序何时会触发，以及多久会触发一次。在这些循环中花费的时间实际上都花费在了呈现步骤中，所以，如果只有 25 帧被绘制到屏幕上，那么游戏会继续以设置好的速度运行。在这两种情况下，您可能都会想要计算更新周期之间的时间差；如果一秒更新 60 次，那么完成函数更新最多有 16ms 的时间。如果运行此操作的时间更长（或如果运行了浏览器的垃圾回收），那么游戏还是会慢下来。 清单 5 显示了一个示例。

清单 5. 带有 render 和 update 循环的基本应用程序类

// requestAnim shim layer by Paul Irish
    window.requestAnimFrame = (function(){
      return  window.requestAnimationFrame       || 
              window.webkitRequestAnimationFrame || 
              window.mozRequestAnimationFrame    || 
              window.oRequestAnimationFrame      || 
              window.msRequestAnimationFrame     || 
              function(/* function */ callback, /* DOMElement */ element){
                window.setTimeout(callback, 1000 / 60);
              };
    })();

var Engine = Base.extend({
    stateMachine: null,  // state machine that handles state transitions
    viewStack: null,     // array collection of view layers, 
                         // perhaps including sub-view classes
    entities: null,      // array collection of active entities within the system
                         // characters, 
    constructor: function() {
        this.viewStack = []; // don't forget that arrays shouldn't be prototype 
		                     // properties as they're copied by reference
        this.entities = [];

        // set up your state machine here, along with the current state
        // this will be expanded upon in the next section

        // start rendering your views
        this.render();
       // start updating any entities that may exist
       setInterval(this.update.bind(this), Engine.UPDATE_INTERVAL);
    },

    render: function() {
        requestAnimFrame(this.render.bind(this));
        for (var i = 0, len = this.viewStack.length; i < len; i++) {
            // delegate rendering logic to each view layer
            (this.viewStack[i]).render();
        }
    },

    update: function() {
        for (var i = 0, len = this.entities.length; i < len; i++) {
            // delegate update logic to each entity
            (this.entities[i]).update();
        }
    }
}, 

// Syntax for Class "Static" properties in Base.js. Pass in as an optional
// second argument to.extend()
{
    UPDATE_INTERVAL: 1000 / 16
});

如果您对 JavaScript 中 this 的上下文不是很熟悉，请注意 .bind(this) 被使用了两次：一次是在 setInterval 调用中的匿名函数上，另一次是在 requestAnimFrame 调用中的 this.render.bind() 上。 setInterval 和 requestAnimFrame 都是函数，而非方法；它们属于这个全局窗口对象，不属于某个类或身份。因此，为了让此引擎的呈现和更新方法的 this 引用我们的 Engine 类的实例，调用 .bind(object) 会迫使此函数中的 this 与正常情况表现不同。如果您支持的是 Internet Explorer 8 或其更早版本，则需要添加一个 polyfill，将它用于绑定。

状态机

状态机模式已被广泛采用，但人们并不怎么认可它。它是 OOP（从执行抽象代码的概念）背后的原理的扩展。比如，一个游戏可能具有以下状态：

● 预加载

● 开始屏幕

● 活动游戏

● 选项菜单

● 游戏接受（赢、输或继续）

这些状态中没有关注其他状态的可执行代码。您的预加载代码不会知晓何时打开 Options 菜单。指令式（过程式）编程可能会建议组合使用 if 或 switch 条件语句，从而获得顺序正确的应用程序逻辑，但它们并不代表代码的概念，这使得它们变得很难维护。如果增加条件状态，比如游戏中菜单，等级间转变等特性，那么会让条件语句变得更难维护。

相反，您可以考虑使用 清单 6 中的示例。

清单 6. 简化的状态机

// State Machine
var StateMachine = Base.extend({
    states: null, // this will be an array, but avoid arrays on prototypes.
                  // as they're shared across all instances!
    currentState: null, // may or may not be set in constructor
    constructor: function(options) {
        options = options || {}; // optionally include states or contextual awareness

        this.currentState = null;
        this.states = {};

        if (options.states) {
            this.states = options.states;
        }

        if (options.currentState) {
            this.transition(options.currentState);
        }
    },

    addState: function(name, stateInstance) {
        this.states[name] = stateInstance;
    },

    // This is the most important function—it allows programmatically driven
    // changes in state, such as calling myStateMachine.transition("gameOver")
    transition: function(nextState) {
        if (this.currentState) {
            // leave the current state—transition out, unload assets, views, so on
            this.currentState.onLeave();
        }
        // change the reference to the desired state
        this.currentState = this.states[nextState];
        // enter the new state, swap in views, 
        // setup event handlers, animated transitions
        this.currentState.onEnter();
    }
});

// Abstract single state
var State = Base.extend({
    name: '',       // unique identifier used for transitions
    context: null,  // state identity context- determining state transition logic

    constructor: function(context) {
        this.context = context;
    },

    onEnter: function() {
        // abstract

        // use for transition effects
    },

    onLeave: function() {
        // abstract

        // use for transition effects and/or
        // memory management- call a destructor method to clean up object
        // references that the garbage collector might not think are ready, 
        // such as cyclical references between objects and arrays that 
        // contain the objects
    }
});

您可能无需为应用程序创建状态机的特定子类，但确实需要为每个应用程序状态创建 State 的子类。通过将转变逻辑分离到不同的对象，您应该：

● 使用构造函数作为立即开始预加载资产的机会。

● 向游戏添加新的状态，比如在出现游戏结束屏幕之前出现的一个继续屏幕，无需尝试找出某个单片的 if/else 或 switch 结构中的哪个条件语句中的哪个全局变量受到了影响。

● 如果是基于从服务器加载的数据创建状态，那么可以动态地定义转换逻辑。

您的主要应用程序类不应关注状态中的逻辑，而且您的状态也不应太多关注主应用程序类中的内容。例如，预加载状态可能负责基于构建在页面标记中的资产来实例化某个视图，并查询某个资产管理器中的最小的游戏资产（电影片断、图像和声音）。虽然该状态初始化了预加载视图类，但它无需考虑视图。在本例中，此理念（此状态所代表的对象）在责任上限于定义它对应用程序意味着处于一种预加载数据状态。

请记住状态机模式并不限于游戏逻辑状态。各视图也会因为从其代表逻辑中删除状态逻辑而获益，尤其在管理子视图或结合责任链模式处理用户交互事件时。

责任链：在画布上模拟事件冒泡

可以将 HTML5 canvas 元素视为一个允许您操纵各像素的图像元素。如果有一个区域，您在该区域中绘制了一些草、一些战利品以及站在这些上面的一个人物，那么该画布并不了解用户在画布上单击了什么。如果您绘制了一个菜单，画布也不会知道哪个特定的区域代表的是一个按钮，而附加到事件的惟一 DOM 元素就是画布本身。为了让游戏变得可玩，游戏引擎需要翻译当用户在画布上单击时会发生什么。

责任链设计模式旨在将事件的发送者（DOM 元素）与接受者分离开来，以便更多的对象有机会处理事件（视图和模型）。典型的实现，比如 Web 页，可能会让视图或模型实现一个处理程序界面，然后将所有的鼠标事件指派到某个场景图，这有助于找到被单击的相关的“事物”并在截取画面时让每一个事物都有机会。更简单的方法是让此画布本身托管在运行时定义的处理程序链，如清单 7 所示。

清单 7. 使用责任链模式处理事件冒泡

var ChainOfResponsibility = Base.extend({
        context: null,      // relevant context- view, application state, so on
        handlers: null,     // array of responsibility handlers
        canPropagate: true, // whether or not 

        constructor: function(context, arrHandlers) {
            this.context = context;
            if (arrHandlers) {
                this.handlers = arrHandlers;
            } else {
                this.handlers = [];
            }
        },

        execute: function(data) 
            for (var i = 0, len = this.handlers.length; i < len; i++) {
                if (this.canPropagate) {
                    // give a handler a chance to claim responsibility
                    (this.handlers[i]).execute(this, data);
                } else {
                    // an event has claimed responsibility, no need to continue
                    break;
                } 
            }
            // reset state after event has been handled
            this.canPropagate = true;
        },

        // this is the method a handler can call to claim responsibility
        // and prevent other handlers from acting on the event
        stopPropagation: function() {
            this.canPropagate = false;
        },

        addHandler: function(handler) {
            this.handlers.push(handler);
        }
});

var ResponsibilityHandler = Base.extend({
    execute: function(chain, data) {

        // use chain to call chain.stopPropegation() if this handler claims
        // responsibility, or to get access to the chain's context member property
        // if this event handler doesn't need to claim responsibility, simply
        // return; and the next handler will execute
    }
});

ChainOfResponsibility 类没有子类化也能很好地工作，这是因为所有特定于应用程序的逻辑都会包含在 ResponsibilityHandler 子类中。在各实现之间惟一有所改变的是传入了一个适当的上下文，比如它代表的视图。例如，有一个选项菜单，在打开它时，仍会显示处于暂停状态的游戏，如清单 8 所示。如果用户单击菜单中的某个按钮，背景中的人物不应对此单击操作有任何反应。

清单 8. 选项菜单关闭处理程序

var OptionsMenuCloseHandler = ResponsibilityHandler.extend({
    execute: function(chain, eventData) {
        if (chain.context.isPointInBackground(eventData)) {
            // the user clicked the transparent background of our menu
            chain.context.close(); // delegate changing state to the view
            chain.stopPropegation(); // the view has closed, the event has been handled
        }
    }
});

// OptionMenuState
// Our main view class has its own states, each of which handles
// which chains of responsibility are active at any time as well
// as visual transitions

// Class definition...
constructor: function() {
    // ...
    this.chain = new ChainOfResponsibility(
        this.optionsMenuView, // the chain's context for handling responsibility
        [
            new OptionsMenuCloseHandler(), // concrete implementation of 
			                               // a ResponsibilityHandler
            // ...other responsibility handlers...
        ]
    );
}

// ...
onEnter: function() {
    // change the view's chain of responsibility
    // guarantees only the relevant code can execute
    // other states will have different chains to handle clicks on the same view
    this.context.setClickHandlerChain(this.chain);
}
// ...

在 清单 8 中， view 类包含针对一组状态的一个引用，并且每个状态决定了对象将会负责单击事件的处理。这样一来，视图的逻辑限于此视图身份所代表的逻辑：显示此选项菜单。如果更新游戏，以包含更多的按钮、更漂亮的效果或新视图的转换，那么这里提供了一个独立对象，它能够处理每个新特性，无需更改、中断或重写现有逻辑。通过巧妙组合 mousedown、mousemove、mouseup 和 click 事件的责任链，并管理从菜单到人物的所有事情，能够以高度结构化、有组织的方式处理拖放库存屏幕，不会增加代码的复杂性。

结束语

设计模式和 OOP 本身是很中立的概念，将这二者捆绑使用会带来一些问题，而不是解决问题。本文提供了 JavaScript 中的 OOP 概述，探讨了原型继承模型和典型继承模型。我们了解了游戏中一些常见模式，这些模式能够从 OOP 设计（基本的游戏循环、状态机和事件冒泡）的结构和易维护性模式中获得极大的利益。本文只是对常见问题的解决方案进行了简要介绍。通过实践，您会熟练掌握如何编写具有表现力强的代码，并会最终减少在编写代码上花费的时间，增加创作的时间。

10款超炫HTML5游戏附游戏源码

Thu, 01 May 2014 09:24:08 CST

五一小长假开始了，小编为各位宅在家里的朋友分享10款超炫 HTML5游戏，让我们在不仅获得快乐的同时又可以学到新鲜的HTML5知识，一起来看看吧。

1、HTML5版切水果游戏 HTML5游戏极品

这是一款由百度JS小组提供的 HTML5版切水果游戏，记得切水果游戏当年非常火，今天我找到了一款基于HTML5实现的网页版切水果游戏。虽然和原版的切水果游戏相比功能不怎么完善，但是该HTML5切水果游戏也算有声有色，画面也十分华丽。

在线演示源码下载

2、HTML5中国象棋游戏自定义象棋难度

棋类游戏在桌面游戏中已经非常成熟，中国象棋的版本也非常多。今天这款基于 HTML5技术的中国象棋游戏非常有特色，我们不仅可以选择中国象棋的游戏难度，而且可以切换棋盘的样式。程序写累了，喝上一杯咖啡，和电脑对弈几把吧，相信这HTML5中国象棋游戏的实现算法你比较清楚，可以打开源码来研究一下这款HTML5中国象棋游戏。

在线演示源码下载

3、奇葩版Flappy Bird,HTML5 Flappy Text游戏

前段时间Flappy Bird游戏那是相当的火，有无数年轻人为之疯狂，我们也在 html5tricks网站上分享过一款简易的HTML5版Flappy Bird。今天我们要分享一款奇葩版的Flappy Bird—— HTML5 Flappy Text游戏，用若干个字母来代替bird，每触碰一个障碍，字母就会少一个。一起来玩玩吧。

在线演示源码下载

4、HTML5五子棋游戏画面超酷可设置难度

前几天我向大家分享过一款 HTML5中国象棋游戏，效果令人惊叹，小编的实力很难胜过电脑。今天我要向大家分享一款 HTML5五子棋游戏，不仅游戏画面非常华丽，而且可以自己设置难度，并且可以选择人机对战还是人人对战，这款HTML5五子棋游戏绝对称得上HTML5游戏中的极品。

在线演示源码下载

5、HTML5跳伞游戏看谁先安全降落地面

今天我再来分享一款有趣的 HTML5游戏，HTML5跳伞游戏，是一款非常不错的HTML5休闲小游戏，主要应用了HTML5的重力感应效果。游戏一共四个玩家，主要是比谁先安全降落地面，绿色信号灯亮时，按下“X”键开始降落，然后再按“X”键打开降落伞进行安全降落，你需要控制好时机来按下“X”键和对手们比谁先安全降落。大家也可以在下面下载源代码学习分享。

在线演示源码下载

6、HTML5版Flappy Bird游戏仅65行Javascript代码

Flappy Bird相信大家都很熟悉了，2014年最热门的手机游戏之一。Flappy Bird这款游戏是一位来自越南河内的独立游戏开发者阮哈东开发，形式简易但难度极高的休闲游戏，很容易让人上瘾。今天我们用 HTML5来重写这款Flappy Bird游戏，值得注意的是，利用Phaser框架，只需65行Javascript代码即可实现HTML5版的Flappy Bird游戏。 按空格键控制小鸟，试试看吧。

在线演示源码下载

7、HTML5吃豆人游戏PCMAN

今天又要介绍一款不错的 HTML5游戏，HTML5吃豆人游戏，画面上有一个吃豆人和一群怪物，你需要控制吃豆人移动吃掉路上的小豆子，一旦吃豆人遇到怪物被吃掉的时候，你就GAME OVER了。这款HTML5游戏还有一点没完善，就是吃豆人碰到怪物的时候不能被怪物吃掉，有兴趣的同学可以继续把它完善。HTML5游戏开发不仅需要技术，也需要创意。

在线演示源码下载

8、HTML5太空战机游戏有声有色

这又是一款制作精良的 HTML5游戏，该HTML5游戏的主角是一架英勇威武的太空战机，进入游戏后按”Z”键发射子弹，消灭敌机。该HTML5战机游戏的特点是：1、游戏画面非常华丽逼真，并且加入声音元素，让游戏更加迷人；2、游戏元素很多，敌机类型和发射子弹类型也很多，让玩家不会枯燥。

在线演示源码下载

9、HTML5重力感应游戏甩甩领导的头像

快过年了，工资没涨多少吧，年终奖没发吧，恨领导吧。现在利用这款 HTML5重力感应游戏来尽情甩领导的头像吧。制作一些你憎恨的领导们的头像图片，利用该HTML5重力感应游戏插件来拖动鼠标甩动这些头像，叫你不加工资…叫你不加工资…

在线演示源码下载

10、HTML5超级玛丽游戏重体验 HTML5游戏经典

还记得小时候一起玩过的超级玛丽冒险游戏吗？是的，那是我们小时候很火的一款游戏，今天老外利用 HTML5技术让超级玛丽可以在网页上跑了，HTML5版的超级玛丽虽然没有原版的功能强大，但是如果你有兴趣，完全可以把它写完善了。HTML5真的很强大，HTML5游戏方面更是犀利。

在线演示源码下载

以上就是10款超炫HTML5游戏及源码，祝大家五一快乐。

聊聊用户访谈

Mon, 12 May 2014 20:40:55 CST

访谈的目的

我觉得靠用户访谈想要得到什么结论是比较难的，原因很多：

你能采访到的用户都是活跃用户，而大部分沉默用户才是用户的主流，以偏概全是有问题的
用户会撒谎，他说这个东西卖太贵了，是为了让你降价。其他问题也有类似的情况
当用户还没有体验过一个东西的时候，他是无法确定自己想要什么的。

所以我觉得访谈最主要的目的是去了解玩家是怎么思考的。

质量的重要性远远大于数量！

100个很肤浅的用户访谈不如10个很深入的用户访谈。

一些小技巧

访谈的技术含量并不高，重点在于是否能打开玩家的话闸子，得到更多有价值的信息。

开放型问题和封闭型问题结合
开放型的好处在于玩家有发挥的余地，能说的玩家能说出很多相关不相关的东西。

然而大部分的用户相对都不太能说，就需要用封闭型的问题来引导，让玩家清楚问题的方向。2种问题结合起来问，才能照顾到所有类型的玩家。
不要死板，顺着玩家走，让他聊high
不要按着问题列表一个一个问，玩家很多时候会跑题，没有关系！让他跑！跑题都说明玩家对这个比较关心，所以会跑过去，如果你打住了很可能就忽略了一个发现重要问题的机会。

此外，顺着玩家走有助于玩家打开话匣子，聊开心了他们才会说出更多该说不该说的东西。
多追问原因
最头疼的就是遇到一问一堆，玩家2个字就打发了。这个时候千万不要气馁，多追问原因，多多少少都会告诉你他们是怎么想的。这个也是访谈中最重要的部分——了解玩家的想法。
总结玩家的话，再次确认
有时候玩家扯了一大堆的东西，或者压根就是语无伦次说些看不明白的东西。

不要猜玩家的意思！你再总结一下，跟玩家再次确认一下，就怕玩家没说明白，我们也没理解明白，就这么糊里糊涂的给总结了。

技术宅打造全能美剧播放器

Sat, 12 Apr 2014 12:06:48 CST

1:前言

看到有同仁发《权力的游戏》自动追剧脚本,老衲也来凑个热闹…

移动端最好的播放器非云播君莫属了,极速而方便,高清而无码,可惜最近资源被和谐,每次有美剧更新需要用浏览器手工添加播放源或者pc端添加,很是麻烦的说。于是就简单diy了下云播1.9 for Android ,使其支持自定义搜索引擎(比如人人影视,xxx资源站等),并且修复了原来搜索结果列表页标题的bug,为了迎接Game of Thrones Season 4 的回归,特记录下修改过程。

2:添加yyets.com搜索引擎

反编译搜索引擎代码
com\xunlei\cloud\action\search\AdviseEngine.java 89 行

try
    {
      str = SearchAdviceEngineListResp.getDomainName(paramString);
      if (str.equalsIgnoreCase("btdigg.org"))
      {
        localAdviseEngine.url_pattern = "http://btdigg.org/search?q={searchTerms}&p={page}";
        localAdviseEngine.multi_page = true;
        localAdviseEngine.page_start_point = 0;
        return localAdviseEngine;
      }
      if (str.equalsIgnoreCase("so.com"))
      {
        localAdviseEngine.url_pattern = "http://www.so.com/s?q={searchTerms}+site%3Abtdigg.org&pn={page}";
        localAdviseEngine.multi_page = true;
        localAdviseEngine.page_start_point = 1;
        return localAdviseEngine;
      }
    }
    catch (URISyntaxException localURISyntaxException)
    {
      localURISyntaxException.printStackTrace();
      return localAdviseEngine;
    }
    if (str.equalsIgnoreCase("torrentkitty.com"))
    {
      localAdviseEngine.url_pattern = "http://www.torrentkitty.com/search/{searchTerms}/{page}";
      localAdviseEngine.multi_page = true;
      localAdviseEngine.page_start_point = 1;
      return localAdviseEngine;
    }
    if (str.equalsIgnoreCase("kuaichuanmirror.com"))
    {
      localAdviseEngine.url_pattern = "http://www.kuaichuanmirror.com/search/{searchTerms}/";
      localAdviseEngine.multi_page = false;
      localAdviseEngine.page_start_point = 1;
    }

挖槽竟然内置四大毛片搜索引擎 !!!
随便改掉一个即可
由于内置引擎只识别磁力链接需要一个脚本文件来做中转(代码见最后链接)
输出格式为

magnet:?xt=urn:btih:hash1&title1</br>
magnet:?xt=urn:btih:hash2&title2</br>

修改 smali\com\xunlei\cloud\action\search\AdviseEngine.smali 239 行

.line 127 
:cond_1 
const-string v2, "yyets.com" 
invoke-virtual {v0, v2}, Ljava/lang/String;->equalsIgnoreCase(Ljava/lang/String;)Z 
move-result v2 
if-eqz v2, :cond_2 
.line 128 
const-string v0, "http://www.ttst.com/y2c.php?keyword={searchTerms}&page={page}" 
iput-object v0, v1, Lcom/xunlei/cloud/action/search/AdviseEngine;->url_pattern:Ljava/lang/String;
.line 129 
const/4 v0, 0x1

3:修正标题bug

云播在使用第三方搜索引擎时,发现结果列表页面的标题全部是随机的字符串

查看对应的dalvik代码
smali\com\xunlei\cloud\action\search\AdviseEngine.smali 990行

const-string v0, "magnet:\\?xt=urn:btih:([A-Za-z\\d]{32,})&?"      //批量正则   遍历结果数组
  .....
 invoke-static {v0, v1}, Ljava/util/regex/Pattern;->compile(Ljava/lang/String;I)Ljava/util/regex/Pattern;
 .....
 invoke-virtual {v5}, Ljava/util/regex/Matcher;->find()Z
move-result-object v0
 .line 88
 invoke-virtual {v0}, Ljava/lang/String;->length()I
move-result v1
add-int/lit8 v1, v1, -0x1
 invoke-virtual {v0, v1}, Ljava/lang/String;->charAt(I)C 
move-result v1
.line 89
const/16 v6, 0x26
if-ne v1, v6, :cond_4
.line 90
invoke-virtual {v0}, Ljava/lang/String;->length()I
move-result v1
add-int/lit8 v1, v1, -0x1
invoke-virtual {v0, v3, v1}, Ljava/lang/String;->substring(II)Ljava/lang/String;
 move-result-object v0
    move-object v1, v0
    .line 92
    :goto_1
    const/16 v0, 0x14
    invoke-virtual {v1}, Ljava/lang/String;->length()I
    move-result v6
    invoke-virtual {v1, v0, v6}, Ljava/lang/String;->substring(II)Ljava/lang/String;
    move-result-object v0
    .line 93
    invoke-static
 {v0, v2}, 
Lcom/xunlei/cloud/action/search/g;->a(Ljava/lang/String;I)Ljava/lang/String;
 // str2.substring(20, str2.length())
    move-result-object v6
 ......
.line 105 
iput-object v6, v0, Lcom/xunlei/cloud/action/search/SnifferData;->title:Ljava/lang/String;
.line 106 
 iput-object v1, v0, Lcom/xunlei/cloud/action/search/SnifferData;->url:Ljava/lang/String;
.line 107 
 iput-object v6, v0, Lcom/xunlei/cloud/action/search/SnifferData;->hash:Ljava/lang/String;

可以看到,标题被直接赋值给 magnet 的 hash 了 …..
修改为

ArrayList localArrayList = new ArrayList();
  Matcher localMatcher = Pattern.compile(".*?</br>", 2).matcher(   //中转脚本每行用</br> 分割
    paramString);
  if (!localMatcher.find()) {
   return;
  }
  String str1;
  str1 = localMatcher.group();
  for (String str2 = str1.substring(0, 60);; str2 = str1) {
   String str3 = str2.substring(20, 60);
   String str4 = str1.substring(61, str1.length() - 5);
   SnifferData localSnifferData = new SnifferData();
   localSnifferData.title = str4;
   localSnifferData.url = str2;
   localSnifferData.hash = str3;
   localArrayList.add(localSnifferData);
   break;
  }

对应的dalvik 代码(具体见后面链接)

locals 15 //15个寄存器
const-string v0, ".*?</br>"
const/4 v10, 0x0
const/16 v11, 0x3c // 60
const/16 v12, 0x3d //61
const/4 v1, 0x2
invoke-static {v0, v1}, Ljava/util/regex/Pattern;->compile(Ljava/lang/String;I)Ljava/util/regex/Pattern;
move-result-object v0
invoke-virtual {v0, v10, v11}, Ljava/lang/String;->substring(II)Ljava/lang/String;
                                                                                                              
move-result-object v8
move-object v1, v8
                                                                                                              
.line 92
:goto_1
move-object v9, v0     // copy 一份v0   magnet:?xt=urn:btih:hash&title
const/16 v0, 0x14
                                                                                                              
invoke-virtual {v1}, Ljava/lang/String;->length()I
                                                                                                              
........
new-instance v0, Lcom/xunlei/cloud/action/search/SnifferData;
invoke-direct {v0}, Lcom/xunlei/cloud/action/search/SnifferData;-><init>()V
invoke-virtual {v9}, Ljava/lang/String;->length()I
move-result v13
add-int/lit8 v13, v13, -0x5
invoke-virtual {v9, v12, v13}, Ljava/lang/String;->substring(II)Ljava/lang/String;
move-result-object v14
.line 105
iput-object v14, v0, Lcom/xunlei/cloud/action/search/SnifferData;->title:Ljava/lang/String;
                                                                                                              
.line 106
iput-object v1, v0, Lcom/xunlei/cloud/action/search/SnifferData;->url:Ljava/lang/String;
                                                                                                              
.line 107
iput-object v6, v0, Lcom/xunlei/cloud/action/search/SnifferData;->hash:Ljava/lang/String;

4:回编译错误处理

java -jar apktool.jar b CloudPlay_ybappgw c1.apk
libpng error: Not a PNG file
ERROR: Failure processing PNG image F:\Pentest\Ya 
Tools\pendroid\apktool1.5.2\CloudPlay_ybappgw\res\drawable-hdpi\local_list_view_item_color.png

不是真正的png文件看了下文件头 bmp… 改过来继续

ERROR: 9-patch image F:\Pentest\Ya 
Tools\pendroid\apktool1.5.2\CloudPlay_ybappgw\res\drawable-hdpi\progressbar_local_item.9.png
malformed.

把三个文件全部改成普通 png格式 progressbar_local_item.9.png => progressbar_local_item.png

apktool b CloudPlay_ybappgw c1.apk
I: Checking whether sources has changed...
I: Smaling...
I: Checking whether resources has changed...
I: Building apk file...

成功编译成apk 文件

5:测试结果

签名安装到手机

java -jar signapk.jar testkey.x509.pem testkey.pk8 c1.apk c1_s.apk
adb install -r c1_s.apk

截图

6:链接

中转脚本: https://github.com/yaseng/pentest/blob/master/project/diy_cloudplay/y2c.php
g.smali : https://github.com/yaseng/pentest/blob/master/project/diy_cloudplay/g.smali
smali 语法 : https://code.google.com/p/smali/w/list
Av Top 10: http://movie.douban.com/doulist/3822549

Patrick Wyatt：魔兽争霸的制作过程（1）

Wed, 14 Nov 2012 09:51:58 CST

英文原文： Patrick Wyatt，编译： CSDN

摘要：说到DOS下的RTS（Real-Time Strategy）游戏，不得不提起Warcraft！它被认为是现代RTS的鼻祖之一，本文由魔兽之父Patrick Wyatt亲自操刀，重现当年Warcraft开发的日子，并阐述Warcraft开发所遵守的理念。

导读：回到那个PC游戏还是运行在DOS系统的时代，DOOM、极品飞车和波斯王子等游戏影响了一代人，当然也有国产的仙剑奇侠传等经典之作流传下来。但是说到DOS下的RTS（Real-Time Strategy）游戏，不得不提起Warcraft！它被认为是现代RTS的鼻祖之一（虽然魔兽之父Patrick Wyatt更推崇Dune2才是现代RTS的始祖），本文由Patrick亲自操刀，重现当年Warcraft开发的日子，并阐述Warcraft开发所遵循的理念。

我是项目组长！

虽然我已经参与开发过很多PC、Mac游戏甚至为超级任天堂和世嘉开发过7个电视游戏。但是一直以来都是以一个初学者的身份参与这些项目，或者只是简单地将游戏移植到其它平台。

我主要参与两项工作：以制作人（作者注：游戏行业术语，通常是指项目管理员、设计师、传道人和 cat herder）的身份领导开发团队以及作为首席程序员来编写主要代码。相比于现在两百来人的大团队，以前只有一二十人的小团队更让我放心。

Warcraft的起源

我所在创业公司——当时叫做Silicon & Synapse，后来因为我们狂暴的开发方式改名为Blizzard（暴雪公司）——的开发人员在休息时间玩了很多优秀的游戏，正是从那些游戏中碰撞出创造Warcraft的火花！

我们开发Warcraft的灵感来自于Westwood Studio（西木工作室）的Dune（沙丘）2。虽然颇有争议，但Dune2通常被认为是第一个现代实时战略游戏（RTS），有一个滚动的世界地图、实时的单位建设和运动以及个体单位战斗。它和现代RTS比如星际争霸2相比，除了规模和图形效果外并没有什么实际区别。

它和它的前身Dune1——一个非常有价值的游戏——共享了一些相同的元素，但Dune1的半实时单位战斗被包裹在了冒险游戏里，Dune2则摒弃了之前的角色扮演的路线，专注于RTS架构：开采资源、建立基地、开采更多的资源、建立军队并且最终找到并消灭敌人。

和其他Blizzard的员工一样，我最终也沉迷于Dune2，并且已有空闲时间就研究三个种族的优劣，一起在公司里讨论游戏风格、展示和战略。

虽然这款游戏很有趣，但它有几个很明显的缺陷急待修复。最明显的是当我和朋友只能一起和计算机战斗，很明显这种游戏更适合多人对战。不同于回合制游戏，实时战斗需要允许多人同时下命令、迅速做出反应并且支持长远的战略计划。

带着这一非凡的思想，Warcraft的设计变得简单多了，只需要评估技术要求、建立计划和员工开销即可。回到Blizzard后，我们经常在午餐时间在餐巾上制定计划，我们把它叫做“今日事物计划”，这也是我们的标准操作方法。

初步发展

在开发的初级阶段，我们甚至缺少艺术家团队，在我不得不需要一两个艺术家帮忙之前，我一直在使用Dune2的屏幕截图，艺术家总是没有时间分心，我们一直时间紧迫。

我早期的游戏引擎开发的努力包括一个基于拼图的滚动地图渲染器、一个用来绘制游戏单位和其他位图的图元渲染器、一个图元排序器来保证游戏单位动起来还有一个时间调度器来传递鼠标和键盘事件、一个游戏调度器来控制单位动作以及大量的用户界面代码来控制应用程序的行为。随着项目最初几个礼拜工作的完工，它已经可以当做单人游戏“玩”了，尽管还没有实现后来的单位建设等功能，在早期阶段需要输入命令来在屏幕上制造单位。

之后每天我都在改进之前的工作。没有任何时间表和里程碑，也没有项目外部驱动器，我可以随心所欲地决定接下来建设什么特性，这让我非常有动力。我非常享受这样的开发，就像毒品一样让我入迷，即使现在，我进入游戏产业22年之后，我仍然喜欢编程的创造性。

第一个特色：多单位选择

最令我自豪的特色就在于单位选择，和Dune2不一样，开始多单位战斗不再需要疯狂地点击鼠标，玩家可以在其中多选单位来加速战斗部署，能够明显地提升游戏战斗。

在进入游戏产业之前，我曾经接触过几个低端计算机辅助设计（CAD）程序，比如MacDraw和MacDraft来为我父亲的酒窖商务设计酒窖设计，使用拖拽来选择长方形区域显得非常自然，这要比使用命令来操作单位方便多了。

我相信Warcraft指第一个使用这种操作模式的，当我第一次实现这一特色功能，从此可以同时选择和控制大量单位，选择单位的数目并没有限制。

但同时选择和控制100个单位也暴露出它致命的缺点——我的简单路计算法。当我得到了基本的算法成功后，我仍然花了数小时来选择单位并把它们派遣到地图的各个角落，而不是编写更多的代码，这是我在编程生涯中最伟大的创造！

后来在和团队成员对此讨论设计问题后，我们决定允许玩家一次最多仅可选择4个单位，以保证玩家注重战略部署而不是简单的拖动一群暴民打一次性群架。后来，我们在Warcraft II里把这个限制增加到9。命令与征服，Dune2的精神继承者，并没有在单位选择的数量上加限制，这也是个很值得思考和讨论的设计分歧。

这一阶段的Warcraft，除了多单位控制之外，简直就是Dune2的“阉割版”，就像我保护性地开玩笑道：Warcraft本来就是受Dune2的启发而制作，但他们是完全不同的游戏——我们的雷达地图在屏幕的右上角，而他们的在右下角。

团队的建立

1994年早期，我加入了由Ron Millar, Sam Didier, Stu Rose, Bob Fitch, Jesse McReynolds, Mike Morhaime, Mickey Nielsen等人组成的团队，他们中许多人在我们公司被Davidson & Associates于1994年2月收购后开始加入游戏的开发。

Warcraft的艺术

Allen Adham希望能够得到Warhammer（战锤）世界观的授权，借助品牌知名度来增加销量。Warhammer是Warcraft艺术形式的灵感来源之一，除了很少有事务团队的参与之外，几乎开发团队的所有人员都参与了“我们的世界”的设计。我们有和DC Comics共事“超人的死亡与归来”以及“正义联盟特遣部队”的糟糕经历，我们希望在自己的游戏中避免类似这样的问题。

现在想想，Blizzard没有去控制Warcraft世界观的知识产权真是不可思议——这很不像暴雪在现在游戏产业中主导者所做的事。

Warcraft推出多年以后，我的父亲在从亚洲之旅回来的途中给我带来了一个礼物：一套Warhammer骷髅战车和战马的微缩模型，附带着一句话：“我在旅行的途中发现了这个东西跟你的游戏很像，我觉得你可以让法律部门去联系他们，因为他们在抄袭你。”(⊙o⊙)…

游戏开发过程中的阻力

在早期开发过程中我们遇到了一件有趣的事，在我在创建一个能够通过调制解调器或者局域网玩的游戏时，发现公司竟然没有一个办公室局域网！我们使用控制台标题，可以很方便地使用软盘传输，所以局域网并不是必须的，尽管它能简化备份。

所以在我开始与其他艺术家、程序员合作的时候，我们使用了“sneaker network”——在办公室之间传递软盘来提交代码和插图。

Bob Fitch是这个项目的第二个程序员，我和他经常互相传递软盘来合并代码变化，但是经常会因此产生错误。我们跟踪合并步骤，发现经常是在合并新代码的时候重写了修复bug的代码，于是我们又不得不回忆一遍之前是怎么修复这个bug的。

这种事经常发生，因为我们开发的疯狂以及我们缺少处理代码合并的步骤，只是通过记忆来判断自己曾对哪些文件做过更改。很幸运的是，我是代码合并系统的中心，所以我做的更改很少会丢失。现在我们有很多源代码控制工具，而那时候我们都不知道它是什么。

随着程序员、设计师和艺术家的大量增加，我们也发现了我们的工作的大的阻碍——游戏最初被设计在DOS “Real Mode”下开发，这意味着只有640K内存可以使用，操作系统本身就用了近120K，你能想想当时的计算机有多恶心吗？

随着艺术团队开始创建游戏单元、背景和用户界面,我们迅速烧掉了所有的内存，并开始寻找替代品。第一个尝试是EMS“paged memory”，超越640K内存障碍映射和存储数据。

老程序员会告诉你EMS的故事，就像老人们说他们曾经为了爬山上学不得不光着脚穿越雪地一样，但是EMS实际上比这更可怕。

在所有的情况下EMS都没有成功，但幸运的是有更好的解决方案。一个叫Watcom和公司发布了一个C编译器，包括一个DOS-mode的扩展器，允许写在保护模式下，通过进入线性32-bit内存——这一现在的程序员在写32-bit（甚至64-bit）应用时认为是理所当然的东西。但是它需要花一两天来更新源代码，DOS-mode扩展器运行地很完美，我们又可以在更大的内存环境下工作了！

下篇预告

下一篇文章里，我将要说说Stu Rose和设计师团队、第一个多人模式的Warcraft游戏、那个差点让多人模式流产的bug以及Bill Roper是如何让Warcraft变得这么酷的、把游戏装进软盘、Westwood Studio对我们的游戏的反应以及18年前我们这些开发人员所学到的宝贵的东西。

游戏设计师的职责

Fri, 07 Dec 2012 10:30:30 CST

文/Michael E. Moore

许多人认为设计师的主要职责是提出游戏的故事情节，但这其实只是他们工作的一部分。许多游戏题材（体育游戏、模拟游戏、益智游戏等）并没有中心故事，设计师要做相当多的工作才能查明怎样使所有的玩法元素形成一个有凝聚力的整体。对于非故事类的游戏来说，开发游戏玩法元素所花的时间可能与为大型角色扮演游戏开发中心故事所花的时间一样漫长。下面就来了解一下游戏设计师的主要职责。

游戏设计师职责1：思考和确定理念

设计师最重要并且最令人愉悦的任务之一是提出游戏思想，然后扩展它以确定玩家的哪些所作所为是有趣的。虽然一些设计师更喜欢独自提出他们的思想，但是许多人更喜欢与他人合作。坐下来与每一个人自由地闲谈，大声探讨各种思想，同时设计师掌控讨论的方向，并在一张白板上草草记下各种思想，这将使人感到非常愉快。然后，设计师将记下关于各种建议的笔记，并把它们分发给参与者进行评论。各种思想的相互影响可以产生一些有趣的、具有创意的建议。

然后设计师必须接纳所有的思想，并为游戏提出一个具体的中心理念。许多公司使用了一个流程，其中任何人都可以提出原始的思想，并把它写在一篇短文档（即意向书）中，以呈递给管理层和创意人员。意向书必须阐明游戏的精髓，并且解释它为什么是新的以及为什么玩起来很有趣。它应该给阅读者留下不可磨灭的印象，因此应该尽可能充满创意地编写它。它应该定义游戏题材，描述虚拟的场景（如果必要的话），然后谈论游戏玩法的一两个最有趣的方面。它打算作为一种推销工具，使管理层（尤其是市场和销售方面的管理人员）有兴趣制作游戏。理想情况下，应该在第一个段落中用包含20个或更少单词的句子概括出游戏的中心理念。这个句子是游戏的高级理念（high concept），并且是市场部推销游戏理念的有用工具。

如果管理层决定某种思想很好，那么他们就会让设计师在游戏提案中更详细地充实它。良好的游戏思想可以毫不费力地得到，并且其中许多思想被提交给管理层，但是最终被搁置在一边。对于呈递的每10种思想，只有一两种被认为值得在它上面做更多的工作。

游戏设计师职责2：游戏提案

游戏提案详细描述了基本理念，并且比较详细地介绍了主要的游戏玩法特性。它仍然是一篇相对较短的文档，不应该过于详细地介绍每种特性。其思想是通过说明将如何玩游戏以及游戏世界会是什么样子来吸引管理层，并且它应该其显示理念值得进一步开发。设计师通常与素描艺术家合作，提出关于角色、有趣的世界位置和物体的思想，但是在这个阶段不太适合做出实际的深入设计。同样，提案也可以用作推销理念的一种市场营销工具，并且最重要的特性之一是市场营销分析，其中设计师与市场部一道演示的新游戏将填补市场中的现有空缺，或者可以在与类似产品的竞争中成功胜出。总之，提案可能包括6~10页。如果它太长，管理层可能不会研究它；如果它太短，则将不能足够详细地包含所有有趣的元素。

设计师在把游戏提案展示给管理层之前，要花大约一两个月的时间来充实它。除了理念艺术家提供的帮助之外，设计师通常会独自负责文档。有时，一系列故事板就是有用的工具，允许管理层和市场营销人员设想游戏动作或游戏世界的场景（参见图1）。强烈建议设计师询问公司的技术主管关于理念的可行性的建议。

在预制作期间，艺术人员有时会创建故事板，定义动作序列的工作方式或者设想关卡的布局。这个故事板是由艺术家Ed Williamson创建的，他曾与本书的作者在一款赛车游戏上合作过。

同样，如果管理层认为思想值得追求，他们将要求设计师把理念扩展为完整的游戏设计文档。不过，对于每5个或6个游戏提案，将只有一个可能获得进一步开发的绿灯。

游戏设计师职责3：游戏设计文档

游戏设计师设计流程的最后一步是游戏设计文档。它可能是一个非常大的文档，因为设计师尝试极其详细地解释游戏玩法元素如何交互以及游戏世界和角色看起来是什么样子的。起初，该文档可能给人的感觉是主要基于推测，因为直到创建了原型之后，设计师才知道游戏世界里事物的实际行为方式。因此，设计文档是“活的”事物，将会随着时间的推移而不断发展和演进。

每家公司都有其构造文档的方法。下面给出了作者多年来反复使用的结构，其思想是把一篇文档分成几大块内容，使得团队中的其余人不必同时吸收整篇文档。他们可以主要关注他们感兴趣的领域，然后可以根据自己的意愿阅读游戏的其他部分。

序言。专门为管理层编写的。它首先将解释游戏的高级理念（通常是从游戏提案中直接提取的），并且给出游戏中的玩法示例，使得读者可以设想所发生的事情。它还包括关于游戏题材、虚拟世界（如果必要）、目标平台和受众的基本信息，并且会非常粗略地估计预算和时间表。本节应该比较短，大约包含4~6页。
游戏机制。专门针对编程团队。该部分内容将详细讨论游戏玩法的每个元素，并且根据需要配有合适的图表和表格。除了解释所有的一切（运动、战斗、资源管理、魔法等）如何工作之外，它还包括设计师对每个屏幕的用户界面的建议，并且描述了所有的控制功能。到本节末尾，程序员应该非常了解游戏引擎需要什么，以及为了使设计像所想的那样工作他们首先需要测试什么。
游戏图形。专门针对艺术团队。设计师尝试包括艺术家将必须创作的所有材料——角色、环境和物品。应该具有关于每个角色、角色可以执行的动作（参考游戏机制的内容以了解更多的详细信息）以及所需的任何特殊的视觉效果的物理描述。环境和物品也要详细描述。注意，关于游戏世界里物体的初始思想可以在开发期间改变，但是为艺术家提供一个起始位置很重要，以后随着时间的推移，当执行更改时可以更新文档，并且完成最终的艺术资产。到本节末尾，艺术团队应该非常清楚他们将必须创建什么。
附录。该部分可以包括其他尚未描述的任何内容。它包括游戏的音频需求、所有的图表、表格、用户界面屏幕示意图以及设计师可能提出的其他任何内容。当游戏进入开发阶段时，随着其他元素（完成的关卡地图、对话、流程图、故事板等）的添加，该部分可能变成内容最多的一部分。

游戏设计文档在预制作和开发期间会经历两个阶段。第一个阶段是游戏设计文档的理念构想，其中将指定游戏玩法的元素和艺术要求，如上所述。设计师可能不得不多次修改理念文档，直到管理层对所有的细节都得到了充分解释而感到满意为止。第二个阶段是制作版本（称为“圣经”，因为它将充当涉足这个项目的每一个人的参考工具），它用于在整个制作阶段中跟踪对原始设计的更改。这个版本包括对原始设计所做更改的频繁更新以及在制作阶段创建的一些材料——例如，最终的关卡地图、对话、利用脚本语言创建的脚本、错误报告更新，甚至包括游戏中的所有资产的目录清单。到游戏完成时，游戏设计文档的制作版本可能长达数百页。对于承担创建插件模块或续集任务的团队（或者外部开发人员），以后可以证明它将是极其宝贵的资源。

游戏设计师职责4：将游戏原型化

对于复杂的游戏，设计师在决定使用那些游戏玩法元素之前通常需要先试验它们。一种试验方式是创建一些简单的原型，包括纸质原型和电子原型。原型是游戏系统的抽象，可以给设计师提供关于系统工作状况的反馈。例如，角色扮演游戏的设计师可能对不同寻常的战斗系统有想法，并且创建一个可用于测试系统的简单的纸质原型，以及在涉及其他任何团队之前修改它的工作方式。纸质原型可用于试验系统的战斗决议、资源管理、技术树演化和谜题解答。它们对于充实关卡的结构以及确定把事物放在游戏场地中的什么位置也非常有用。设计师不需要牵涉到处理其他项目的其他员工，而只会让他们参与测试，并获取关于系统工作状况的反馈。

与纸质原型可能同样有用的是，任何最终的设计决策都不太可能在游戏引擎启动并运行之前做出。一旦资产变得可用并且引擎像预期的那样工作，那么在纸上看起来很好的设计可能发生根本性的改变。如果可能，设计师应该要求将电子形式的交互式原型作为技术审核的一部分。这种原型可能仍然非常简单，使用现有的游戏引擎和艺术（参见图2）。一旦游戏出现在屏幕上，甚至是以最初级的形式，它的外观和感觉也可能与设计师脑海中所想的差别很大。物体的比例可能需要改变，从而强制设计师重新权衡用于解析游戏动作的值。如果将会出现游戏的多玩家版本，具有用于早期测试的电子版本可以证明是飞来鸿运。通过与程序员和艺术家合作，设计师可以具有一种非常有用的工具，可以以最低的成本测试游戏的多个版本。

这是MEDS Games的第一人称射击游戏《Zombie Swarm》的交互式原型。这个原型可以让团队检查游戏场地上物体的比例以及测试简单的游戏玩法

使用原型的全部思想是：在其他团队开始创建游戏的最终资产之前明确事物的工作方式。如果让艺术家在艺术资产中投入大量的时间，而只是为了查明它们出现在游戏中的效果不佳，那么将没有比这更糟糕的事情了。同样，程序员憎恨重写代码，因为设计师在不断地改变他们的主意。简单的原型可以帮助设计师确定和权衡赋予游戏物体的值，并且保证游戏机制像文档中所描述的那样工作。

游戏设计师职责5：资产创建

一旦整个团队准备好制作游戏，设计团队要么加入进来创建资产，要么监督其他团队成员的工作。依赖于要开发的游戏的类型，用于制作资产的工具可能非常简单，足以让设计师使用它们，或者它们可能如此复杂，以致只有技术高超的团队成员才可以自信、轻松地使用它们。有时，公司将构建像地图编辑器和脚本语言这样的工具供设计师使用。在这种情况下，在测试员递送他们的建议和错误报告时，设计师可以直接构建资产以及测试和权衡它们。在其他时间，公司不太喜欢花时间为设计师构建工具，而是选择依靠商业产品。例如，大多数设计师不擅长使用像Autodesk的3ds Max或Maya这样复杂的3D建模应用程序，因此他们将难以利用这些应用程序构建环境。作为替代，将创建环境的工作留给艺术家去做，他们与设计师合作来确定关卡的布局。关卡的纸质原型可以帮助艺术家形象地表示设计师头脑中所想的事情，从而使关卡创建要快得多。

设计师还与编程团队和艺术团队合作，以确保多种游戏系统像计划的那样工作，以及角色像构想的那样移动和行动。设计师根据需要更改图表中的数据，修改赋予物体的值和属性，直到平衡和完成了游戏系统为止。与此同时，他们将在图形用户界面上与艺术家和程序员合作，使得玩家看一眼就能理解每个屏幕上展示的所有信息，并且他们还有助于充实控制模式，直到玩家觉得它很直观并且容易理解为止。

游戏设计师职责6：测试和调试

设计师最重要的工作之一是持续不断地测试游戏，以确保值经过了权衡，并且逻辑或所讲的故事中没有漏洞。在关卡完成时，将把它们提供给测试员，以检查游戏玩法的值和游戏元素中的问题。设计团队必须坚持不懈地调整游戏物体的值，直到新手和经验丰富的玩家都可以享受游戏体验为止。当开发工作逐步放松下来时，设计师还必须当心在制作的后期阶段所做的任何更改不会使前面完成的资产失衡。

从Alpha阶段及以后开始用一种新的眼光查看产品总是一个好主意。完成的关卡倾向于更难以测试，因为过于熟悉它们的测试员会抱怨说它们的难度不够。让一组新玩家查看游戏以便评估整个产品中的动作协调情况是很重要的。

随着游戏到达Beta阶段，可能调拨一些设计师开始从事下一个项目。最后一轮调试专门用于修正代码和最终艺术的问题，此时通常不再需要设计师（除非有数据库方面的问题或者需要衔接松散的故事线索）。项目的结束通常意味着设计师可以享受一个心安理得的假期，以使他们能够重新充电，充满创意地着手处理下一个项目。然后，他们将再次开始这个流程——提出思想、把它们呈递给管理层，并用文档记录游戏玩法。

作者Michael E. Moore，资深游戏设计师和游戏开发工程师，在游戏领域探索和实践了25年，经验和经历十分丰富，享有盛誉。几乎参与过所有类型游戏的开发和设计的各个环节，从角色扮演游戏到冒险游戏，从棋盘游戏到战争游戏，从益智游戏到虚幻动作类游戏，开发大量经典的游戏作品，对游戏设计有深刻的洞察和理解。曾担任过多本杂志的总编辑，以及迪吉彭理工学院游戏软件设计和制作系教授。他还是一位经验丰富的技术作家，除了撰写过大量游戏手册外，还参与撰写了《Introductionto the Game Industry》和《Game Development Essentials: Game IndustryCareer Guide》等著作。

本文节选自《游戏设计师修炼之道：数据驱动的游戏设计》一书。本书由Michael E. Moore著，傅鑫等译，机械工业出版社出版。

实例分析赛车游戏的赛道设计原则

Fri, 28 Oct 2011 16:52:38 CST

作者：Luke McMillan

（本文以《头文字D》、《Maximum Tune》和《GT赛车》为例，详述赛车游戏的跑道设计原则）。

游戏是一种“授权”模拟，即赋予玩家权利去完成或做到某些在现实生活通常（或合法情况下）不允许的事。赛车游戏，特别是冒险赛车游戏，就是绝佳例子。赛车游戏不要求玩家都达到驾驶F1的水平，否则99.9999%的玩家都只能靠边站了。

能不能在现实生活中玩赛车，资金是一个大问题——你不仅需要买一辆好车，还得支付所有与“合法”赛车相关的费用。除了资金，最难克服的阻碍就是年龄和许可证——多少未成年人想开快车，但现实不允许啊！

冒险赛车游戏运应而生。设计良好的赛车游戏不仅向非赛车手的玩家“授权”，更重要的是，给予其非凡的体验。

去过游戏机厅的人会发现，有两款游戏霸占了街机市场，其玩家通常不是赛车手，却开着马力超过820的车像怪物一样狂飙。

让业余玩家也能够自如地驾驶极限赛车的是两种东西：赛车动力系统和跑道设计。本文将着重讲解赛道设计的原则，并利用这些原则分析《头文字D4》中的秋名湖环道和《Maximum Tune 3》中的阪神快线。

五大基本指标

在讲解设计赛道的原则以前，我们有必要先了解一下跑道的五大基本指标，这是支撑赛道设计的基础，且适用于许多不同的场景。这五大指标如下：

1、赛车线路

2、弯心（弯道内侧顶点）

3、赛道宽度

4、夹角（车轮面与垂直面的夹角）

5、高度变量

接下来我将分别讲解以上指标。

弯心&赛车线路

在赛道设计中，最重要的指标是弯心和赛车线路。在理解两者的作用以前，我们先粗略地了解一下赛车及其动力系统。下图是汽车工程师学会（SAE）的汽车标准模型，所有赛车游戏都会用到图中的轴线。图1采用的是标准的SAE坐标系。

图1:SAE坐标系(from gamaustra)

其中，纵轴线(Longitudinal)上的力直接影响赛车的加速和刹车。左右摇摆(Yaw)和横轴向(Lateral)的力对驾驶和重量转移的影响最大。在赛车游戏中，为了产生最大的速度，我们希望玩家尽可能地采用纵向力。而刹车和横向力不仅会使赛车减速，还会使赛力更难控制。把这两点记下了，我们就可以进一步了解弯心和赛车线路的概念了。

本文所提到的指标都是以对赛车的影响为基础，而不是对玩家的作用。赛道总是直接影响赛车，而对玩家的作用只是间接的。这是即使是在相同的赛道上驾驶不同的赛车，玩家的体验也总是不同的。

从某种意义上说，赛车是一种转换器，是玩家与赛道设计之间的必要中介。赛车的动力本身就是一个太广泛的主题，在此我就不多加讨论了。只看SAE标准轴线系统，我们就已经能够明白这五大指标是怎么回事了。

图02：弯心和赛车线路(from gamasutra)

赛道上的所有转角都有一个最佳切入点、最佳弯心和最佳切出点。弯心是赛道边缘的一个目标点，如果玩家希望以最短的距离通过拐角，就务必通过这个点；同时，玩家还必须尽可能减少施加于赛车上的横向力。

在某些情况下，弯心就代表了通过拐角的最短路线，但这要求赛车承受更多的横向力。最佳弯心使玩家能够在使用更多的纵向力的同时，不必增加多余的横向运动。

图03(from gamasutra)

通过分析转角的最短线路和最大化利用路面，可以确定切入点、切出点和弯心所在。路面区域为什么重要？原因是，如果路面够宽，玩家就可以少用横向力（游戏邦注：横向力总是影响加速和操作）。

我们再回头看图3，图中的绿线代表线路——或最者说是通过拐角的最佳线路。路面越宽，所需的横向力越少。总地来说，冒险赛车游戏的玩家总是找机会增加纵向力。

如果把这两条指标单独列出来讲，恐怕有困难，因为二者是互生关系。赛车手会根据自己对赛车和弯心的理解，在自己的脑中想象出一条赛车线路。而对于设计师，他们的头脑当中出现的可能是赛车线路也可能是赛道，这取决于设计的方法。

无论设计师采用什么方式设计赛道，理想的赛车线路都应该至少保证赛车受到横向力的影响。

图04(from gamasutra)

图05(from gamasutra)

图4表示的是一条简单的赛道曲线。根据这条曲线，设计师还需要考虑弯心位置、然后制作正式赛道。而图5表示的是另一种相反的赛道设计方法。设计师先计划弯心，然后决定理想线路。无论采用哪种方法，结果都是如图6所示的小型赛车风格的布局。

图06(from gamasutra)

从图6中，我们大抵能看出最终赛道的样子，但这绝不代表有了以上知识我们就能够设计出理想的赛道了。接下来还要处理转角的难度。转角的难度由赛车线路和弯心共同决定。

图07(from gamasutra)

图08(from gamasutra)

切入点、弯心和切出点这三者构成的夹角越小或三者之间的距离越短，转角的难度越大。请对比图7和图8。

大转角可以同时拥有数个弯心，但切入点和切出点却总是各有一个。玩家必须把切入点和切出点当作一个记住赛圈的“标点”。

进一步地说，通过这种方法，赛道设计师可以想出一个组合了直段赛道和转角和赛圈。

根据所使用的赛车动力系统的类型，直段和转角相组合有利于实现游戏的平衡，即给予不同属性的赛车以相同的赶超机会。

图09(from gamasutra)

具有多个弯心的转角叫作“复合转角”（如图9所示）。确定复合转角的转角的方法也相似，即弯心之间的距离越短或校正线路的可用路面（由三点之间的夹角可推断）越小，难度越大。

请务必注意，不同的赛车游戏会有不同类型的赛车动力，这会极大地影响使用弯心的方法——这部分内容将在分析案例时详述。

理解弯心及其对赛车线路的影响是赛道设计中最困难的部分。难怪赛车游戏这么让人伤脑筋了。

我这么说的意思是，玩家必须以最少的操作量、刹车和加速动作来解决空间问题。我们已经讨论过赛车的动力，游戏中采用的动力系统的类型会严重影响设计师对弯心和线路的设计。

赛道宽度

赛道宽度是一个比较常识性的指标，相对容易理解和执行。根据经验，路面越宽，转角的难度越小，因为弯心之间的夹角更大，赛道的整体难度也降低了（可返回看图3）。

一个被普遍承认的设计原则是，在第三人称游戏中，场景应该按大约33%的比例放大。所以，赛车游戏及其赛道亦是如此。原因是，这样做可以给镜头腾出移动空间，同时给予玩家赶超对手的时机。

图10(from gamasutra)

设计赛道的规模时，每条车道的宽度应该是赛车的1.6倍，这样才能2条车道就能容纳3辆车并行，同时保持分离的距离最小（如图10所示）。此外，路肩的宽应该保持在赛车的50%至75%（如图11所示）。

如此设计，玩家就可以冒险争取战略上的有利位置——特别是在转角时，横向力会影响赛车的质量，从而阻碍玩家向有利位置转移。赛道的截面越宽，犯错的可能越大。转角越钝，有经验的玩家就能运用更多的纵向力，从而使线路行驶更加顺畅。

图11(from gamaustra)

夹角

路面夹角与路面的倾斜有关，还会影响滚动倾侧角（影响赛车拐弯的能力，即过度转向和转向不足，如图12所示）。所谓“过度转向”与“转向不足”是描述赛车的动力的术语，而“内夹角”和“外夹角”则与赛道的设计有关（如图13所示）。

图12(from gamasutra)

Figure13-Part1(from gamasutra)

Figure13-Part2(from gamasutra)

电子游戏《Daytona USA》大量使用内夹角转向，这个闻名的设计实现了不可能的转角切入点和切出点速度，这样，业余玩家只需要一点点操作就能完成高难度的转角。另一方面，像《GT赛车》这种更贴近现实的游戏会综合运用内夹角和外夹角，以测试玩家和他们所选择的赛车的极限。这种模式基本上需要玩家进行大量练习实践，所以不太适合游戏厅环境。

理想地说，所有街机风格的赛车游戏中的转角都应该是内夹角，因为这样才能在游戏中加入一些大胆又冒险的转弯。因为赛车游戏所吸引的特定玩家群体，这个考虑是比较合理的。

高度变量

高度变量在赛道设计中有两个突出目的。第一是，创造一种非对称的平衡，即赛道对一种赛车有利，对另一种赛车不利；第二个是，让玩家产生紧张、放松的情绪，和让玩家有机会“展望未来”。第二个目的本身就是一个主题，我在以前的文章中已经详细地探讨过了。简要地总结这两个目的，前者可以这样理解，因为各种赛车的不同质量和动力，高度变量对玩家可能有利也可能有弊。

一般来说，我们可以把后者当作是赛道设计和关卡设计中的纯情绪成分。视线限制会让玩家产生焦虑感，因为他们不能估计前面的路况。当视线延长时，玩家会感到自己更有能力，因为他们能够轻易地预测下一步行动。

从情绪的角度来看，只要合理地使用，高度变量就能给赛道增加乐趣。高度变量还可以给玩家带来“展望时刻”，从而给环境和体验增加额外的兴奋点。

这些展望时刻通常在玩家上坡时强行限制玩家的视线一段时间。

一旦玩家达到稳定水平，开始下坡时，他们的视线就比上山时增加了许多，这样他们就能看到赛圈的全景和关卡设计。

综合指标

既然我们已经理解了以上五大指标，现在我们可以将其运用到案例研究了。不过，因为赛车的动力系统所起的作用太大了，所以有必要先区分《头文字D》和《Maximum Tune 》这两款游戏中各自使用的赛车动力。前者使用了一个叫作“赛道线路惩罚”的系统，后者以“Scandinavian Flick”为驾驶特色。

Scandinavian Flick

图14是Scandinavian Flick的模式图。玩家通过最佳切入点后转向最佳弯心。

一旦赛车的重量开始向这个点转移，玩家就可以逆转舵，驶向最佳切出点，最终克服赛车的惯性，在不同的点之间实现赛车质量的转移。在这一过程中，玩家要兼顾纵向力、横向力和左右摇摆。Scandinavian Flick有别于其他纯粹“抓地”式的驾驶的特点在于，过度使用纵向力。

我在文章前半部分提过，横向力起的是消极作用。然而，《Maximum Tune》的赛车动力偏就设计成了不得不用上小部分横向力才能跑出理想线路。

图14(from gamasutra)

在《Maximum Tune》中，赛车在转向中速度会减少，但通过逆转舵可恢复。这意味着，玩家得在逆转舵上花更多的时间——结果，在这款游戏中通过转角的弯心，不足50%能称得上最佳。

这就是《Maximum Tune》处理横向力的方法之一。把弯心位置提前意味着大多数时候，过转角时使用的纵向力比横向力多。至于如何把弯心位置提前，那就是让转角切出点比切入点宽。

错失弯心

《Maximum Tune 》和《头文字D》都将错失弯心作为惩罚玩家的方法和赶超对手的时机。图15表现的是一名玩家错失最佳弯心。为了保持赛车线路（影响了过转角的最大速度），玩家必须进一步调整，这样就牺牲了赛车的速度。

一旦赛车运动起来，玩家就不喜欢被意料之外的力量所干扰。然而每校正一次，就有一股意料之外的力施加到赛车上，这样就导致了赛车的减速和不稳定。在所有赛车游戏中，玩家总是希望得到比较高的转角切出速度。研究后面的案例时我将进一步拓展这个话题。

图15(from gamasutra)

线路式惩罚

《头文字D》采用的赛车动力系统组合了擅长打滑和抓地的赛车的特点，这样就在赛车之间产生了一种非对称关系——赛车不需要造形上的对称，因为玩家和赛道的组合关系总是会产生不对称性。

有些人可能更倾向于使用Scandinavian Flick，而另一些人更偏向纯粹的刹车、线路式赛车、采用最有效的线路过转角。这种非对称关系决定了《头文字D》的主要机制就是线路式惩罚。

图16反映了两辆赛车通过相同转角的模式图。银色赛车走的是一条相对安全的线路，但这么做也更容易被超车，不过看结果，这条线路还是比较有效的。而红色赛车则撞上最佳弯心，从而获得更高的转角切出速度。根据赛车的CX值（游戏邦注：测量赛车发生碰撞时承受的能量值），红色赛车在《头文字D》中比较有优势，因为它的质量足以将银色赛车挤出最佳线路。

图16(from gamasutra)

在这两款游戏中，玩家都需要权衡过转角的方法。图17表现的是玩家采取比较安全的过转角策略，从而为调整赛车的两边腾出更大的空间。尽管这么做比较不容易撞上路面上的护栏（撞上了就势必影响速度），但也损害了线路的效力，导致在最佳线路上被超越。

图17(from gamasutra)

如图18所示，选择风险最大的过转角线路，玩家如能切中最佳弯心，则获利最大，否则失利也最大（因为没有足够的校正空间）。

一般来说，在游戏中，如果赛车相撞，被施加的惯力不如撞上路障的大。也就是说，宁可撞上其他赛车也别撞上路障，若是撞上其他车，玩家基本上还是有能力让赛车保持较高的稳定性。赛车稳定了，加速也更快，过转角也自然更顺利，因为没有其他力对赛车的动力系统产生影响。

图18(from gamasutra)

《头文字D》vs. 《Maximum Tune》

到目前为止，我们已经知道了这两款游戏分别采用了不同的赛力动力系统和赛道设计。然而，对于非赛车手的玩家而言，二者都能带给玩家非常high的体验。玩家玩这两游戏的具体体验和情绪感受会有所不同，但通过分析二者的赛道设计案例，我们可以总结出一些实用的设计原则。

《Maximum Tune》的赛道设计及赛车动力系统的特征：

赛道较宽，采用四人制比赛

速度更快，转角比较缓和

游戏过程中有NPC赛车参与

领先的玩家可以采取不同的线路

棘手的转向比较少

《头文字D》的赛道设计及赛车动力系统的特征：

联网二人制比赛，对手为AI或其他玩家，强调对手竞争

狭窄赛道上的赛车速度较慢

线路性惩罚

无交通障碍

《Maximum Tune 3》之阪神快线

阪神快线是《Maximum Tune 3》中一条受欢迎的赛道，在设计上与《Daytona USA》中赛道有许多相似之处，特别是起点线圈。这条线路比较宽，有许多完全内夹角的转角。正如《头文字D》中的秋名湖环道，阪神快线是现实快车道（位于日本大阪）的美化版。

因为《Maximum Tune》的场景引用自日本系列漫画《Wangan Midnight》的非法高速赛车，所以本作强调高速穿过正常车流时的紧张快感。

前面提到，《Maximum Tune》将其最佳弯心位置移前，因此玩家可以获得更大的出转角速度，而实现的方法就是让切出口比切入口更宽。从情绪的角度看，这听起来可能有些无聊。然而，本作的设计师又想出了更高明的点子来美化玩家的活动，让玩家的感觉比事实上更好。这就是“针线”理论。

《Maximum Tune》之针线理论

阪神快线就是一个针线理论的缩影版。简而言之，所谓的“针线转角”就是由一个非常宽的切入点、一个弯心（只有一个）和一个“感觉上”非常狭窄的切出点组成的。（图19）

图19(from gamasutra)

针线转角在激发玩家的情绪上意义重大，往往让玩家在成功通过转角后产生一种掌握的快感。与游戏中的其他元素一样，针线转角为的就是展现玩家看起来比实际上更好的一面，特别是在游戏机厅那种时不时有人过来瞄一下的环境。

图20揭露了这种撑握感和成就感的真相。当玩家正确地碰上最佳转角切入点时，赛车仍然偏向一边地驶过“针线”点，这样赛车就离路障更接近了。镜头的定位是有目的的，可以准确地捕捉这个不可思议的一瞬间——在现实生活中，这往往导致灾难，特别是按游戏赛车的速度行驶时。

图20(from gamasutra)

在采用针线转角时，原设计可以先忽略狭窄的切出点。看图20，移掉路障，我们就可以看穿这个设计的方法学。在图21中，你可以发现，转角的切出点显著地比切入点来得宽，这意味着最佳弯心可以比转角来得早。路障的造成的另一个幻觉是，玩家需要美化自己的活动，需要让自己觉得无所不能。

图21(from gamasutra)

《头文字D》之非对称平衡

《头文字D》采用的是多重赛车动力系统，这意味着要在实现平衡的同时给予玩家非凡的体验，赛道设计尤其重要。秋名湖赛道是现实的秋名湖公路（位于日本群马县）的美化版。图22是该赛圈的平面图。尽管两端都可以作为该赛道的起点，但通常把起点线设在海拔最高的那个扇区，然后往下依次通过十个扇区。

图22(from gamasutra)

玩家一开始所选择的赛车类型会极大地影响其最适合赛道类型。

重型车如Nissan GTR在上山方面比较有优势，因为马力比较大。小型车如本田AE86则更擅长下山，因为质量轻，且能够在转角切出时执行转向过度。

秋名湖环道综合利用转角，巧妙地实现了玩法和逼迫对手之间的平衡。秋名湖环道在第八扇区采用独特的水平扇区。如果你对本作熟悉，你应该知道如图23所示的三个连贯的转角。

路标对速度感觉的作用极大，下面的图片标示了这些路标，用来表现其向玩家传递的紧迫感。

图23(from gamasutra)

在对这个特别的转角做出解释以前，有许多指标要考虑到。在《头文字D》（以及大多数其他赛车游戏），角度递减的复合转角对轻型赛车更有利，而遇上角度递增的复合转角时，重型、大马力的赛车更具优势。（如图24和25所示）

图24(from gamasutra)

图25(from gamasutra)

还有一个复合转角的组成部分应该考虑到，那就是弯心之间的校正距离。在很大程度上，这个难度指标可以用弯心指标中的角度外推法来解释。然而，图26表明，难度指示与弯心之间的距离有关。

图26(from gamasutra)

这些校正点之间的距离为什么这么重要？这是因为赛车动力和牛顿第一定律——匀速运动中的物体将保持运动状态不变除非受到外力作用。图27结合了赛车动力、弯心之间的距离和牛顿第一定律。《头文字D》中采用的重量转移对不同的赛车所起的作用也不同。

图27（from gamasutra)

《ID4》 vs. 《MT3》 vs. 《GT5》之直道的运用

我们目前还没谈到的就是直道的运用。无论是什么形式的赛车，直道都是必须的，但是如果直道太长了，就会对非赛车手的玩家产生消极影响。

第一眼看来，直道好像很有趣：在直道上，玩家想怎么开风门都行。如果直道用得不好，特别是在街机游戏中，大问题就来了。现实中的直道运用和街机游戏中的直道运用，要搞清二者之间的差别，有必要先分析这三款游戏的统计曲线图。

三款游戏的统计曲线图(from gamasutra)

以上三条曲线代表有经验的玩家分别操作大功率赛车跑《MT3》中的阪神快线、《ID4》中的秋明湖环道和《GT5》中的试验山。《MT3》和《ID4》均存在最低标准差，而《GT5》的最快速度和最慢速度之间存在最高的偏差。

图中记录了赛车在5秒间隔内的速度，比较了当前速度样本和最后一个样本。1表示赛车自最后一个样本起没有改变速度。正值表示速度增加，负值表示速度减少。

这个图表从更现实的角度反映了赛车游戏，如《GT》，直道可以让赛车获得的速度远远大于最佳转角切入速度，这就要求玩家在进入转角切入点时，必须经过一段刹车的时间。一方面迫使玩家必须学习这个过程，另一方面增加了赛道设计的困难。

掌机和电脑游戏在难度方面有特权。在掌机上，业余玩家每次玩都不花钱，因此在练习和识记方面多花时间也不成问题——犯错也不怕，另外，玩家连机对战时可以自己挑选时间。

街机游戏却必须照顾玩家的情绪，因为玩家每次玩都是在别人的眼皮底下进行的。尽管直道在所有形式的赛道设计中都有所运用，但为了业余玩家也能过瘾，直道绝不能让赛车的速度大大高过转角切入点的速度。因为直道会让转角难度增大，所以在这个棘手的转角出现以前，应该有许多更简单的转角作为过渡，以便玩家提前消耗过快的速度。

总结

本文的初衷是，探讨用什么方式让非赛车手玩家获得过瘾的赛车体验。《头文字D》和《Maximum Tune》都是非常优秀的游戏范例。通过对二者的分析，我们可以在五大基本指标的基础上归纳出以下原则：

1、在运用直道时，必须保证赛车的速度不超过最佳转角切入点速度。尽可能保证少用刹车。

2、转角必须渐渐缩紧，以确保玩家能够接近最佳转角切入点。

3、赛车速度的标准差应该相当小，理想值是保持在在+0.3或-0.3的范围以内。

4、用路标来制造速度感，这是必须的。

5、针线转角应该用来彰显美化玩家的技术。

6、街机赛车游戏的所有转角都应该是内夹角式的。

7、高度变量应该总是运用到赛道设计中，给玩家带来多样的情绪感受。但高度上的速度改变应该禁止。

8、用直线作为“标点”。用路标或标志性特征区分转角。

还有其他实用的元素比为本文力所不及。我们应该清楚地区分实际上的难度和感观上的难度。比较一下《头文字D》和《GT》中的速度改变，前者非常擅长给玩家制造感观上的难度，但在赛道设计上不如后者出彩。

此外，另一个要处理的大问题是赛车的动力。请务必注意到，不同的赛车动力并不会损害五大指标，相反地，赛车会给玩家带来相当不同的体验，特别是在制造难度方面。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

A Rational Approach To Racing Game Track Design

by Luke McMillan

[In this extensive article, Gamasutra takes an in-depth look at racing game track design, comparing two arcade titles -- Initial D and Maximum Tune -- and contrasting them, at important points, against the approach used in the Gran Turismo series.]

Games are about empowerment — being able to achieve and do things that you can’t ordinarily (or legally) achieve in real life. Car racing games, especially arcade racing games, are the perfect example of this. Reaching the level of skill required to drive in F1 will be out of reach of 99.9999 percent of the population.

Financial overhead also plays a significant role in being able to drive your car on a race track in real life — not only do you need a competent car, but you also need to pay all of the fees associated with “legal” racing. The most prohibitive factor though is age and licensing laws — every teenage boy wants to drive a high-powered car, but that just isn’t going to happen in reality.
This is where the humble arcade racer comes in. A well-designed arcade racer gives non-drivers an empowering, and most importantly, accessible experience.

But how do game designers make driving “on the limit” accessible, fun, and most importantly, empowering for non-drivers? The answer to this lies in analyzing the track design of two contemporary arcade hits: Initial D: Arcade Stage and Maximum Tune.

Anyone who has visited an arcade recently would have noticed that these two games dominate the arcade market, and are nearly always played by non-drivers piloting 820-plus horsepower monsters like pros.

There are two sides to this sudden and god-like ability for non-drivers to handle these uber-cars: vehicle dynamics and track design. This article focuses on establishing a set of rational metrics for track design and then applying these metrics to the analysis of the Mt. Akina track from Initial D: Arcade Stage 4 and the Hanshin Express Line from Maximum Tune 3.

Five Essential Metrics

In order to take a rational approach to track design, it is essential that we have a set of metrics. These metrics underpin all elements of track design and can be employed in a number of different scenarios. The five metrics of rational track design are;

Metric 1: Race Line

Metric 2: Clipping points (and related metrics)

Metric 3: Track Width

Metric 4: Camber

Metric 5: Height Variation

Before analyzing how the case studies provide an empowering experience for non-drivers, it is essential that that these metrics are explained both individually and in relation to each other.

Clipping Points & The Race Line

The most essential metrics for rational track design are clipping point and the race line. However, to understand how these two metrics work, it is important to talk about the vehicle and its system of dynamics. Using the existing Society of Automotive Engineers’ standard model, a vehicle has a pre-defined set of axes which are used in all racing games. Figure 1 is an example of the standardized SAE coordinate system.

The longitudinal axis is most directly affected by acceleration and braking. The yaw and lateral axis is most directly impacted by steering and subsequent weight transition. In a racing game, we want the player to apply as much longitudinal force as possible, as this will always result in a high speed. Application of brakes and lateral force will not only slow the vehicle down but also make it less predictable. With this in mind, we can now move onto the concept of clipping points and race line.

The metrics presented in this article are all based on the effect on the vehicle, not the end user. The track will always directly impact the vehicle, but only indirectly impact the driver. The reason for this is due to the fact that driving different vehicles on the exact same road will yield different experiences for the end user.

The vehicle is a translator of sorts, and is the essential middle man between the player and the track design. As vehicle dynamics is such a broad topic in itself, it will be discussed a future article, however the SAE standard axis system is comprehensive enough to be able to understand and apply the five metrics of rational track design.

Metric 1 and 2: Clipping Points & The Race Line

Figure 2
Every corner in a race track will have an ideal entry point, an ideal clipping point, and then an ideal exit point. The clipping point is a target on the roads edge that the player must aim for in order to maximize the chances of taking the shortest possible route through a corner, whilst at the same time placing the least amount of lateral force onto the vehicle (Figure 1).
In some cases, a clipping point might represent the shortest possible route through a corner; however, it may require the use of too much lateral force on the vehicle. These ideal points enable the player to apply as much longitudinal force onto the vehicle as possible (acceleration) without compromising this force with the addition of any unnecessary lateral movement.

Entry, exit, and clipping points are derived partly from creating the shortest possible route through a corner and also from using the most surface area of the road. The reason surface area is important is, if a road is wider, it means that less lateral force needs to be applied to the vehicle (remembering that lateral forces compromise acceleration and also make the car less predictable).

Jumping ahead slightly, Figure 3 has a dotted green line used to denote the race line — or most optimal route through the corner. The wider the road is, the straighter the race line becomes and less speed-compromising lateral force needs to be applied. In all cases, opportunities to increase longitudinal force are most sought after by players in any arcade racer.

It is difficult to talk about these two metrics in isolation, as they are a product of each other. For a driver, they will create a race line in their mind based on an understanding of their vehicle and the clipping points. From a designer’s perspective, the race line may supersede the track layout depending on the approach taken.

No matter what approach of these approaches is used in the design of tracks, the ideal race line should result in the least amount of lateral force being applied on the vehicle. To demonstrate these two approaches, we can refer to figures Figure 4 and Figure 5 respectively.

Figure 4 is the end result of drawing a simple spline to represent your track. Based on this approach, the designer would need to plan their clipping points then create the track around this. Figure 5, on the other hand, is just as valid, and uses the opposite approach. The designer would need to draw on the clipping points, then create the ideal race line. No matter what approach is used, the end result is represented in Figure 6 as a very basic, kart-style layout.

Although this is indicative of an end result, by no means does it represent the body of knowledge that is required to make an empowering track. The next issue that needs to be addressed is corner difficulty, which is a combination of race line and clipping points.

Difficulty of a corner increases if the angle between these three points is more acute and / or if the distance between these points is reduced — as seen in a comparison between Figure 7 and Figure 8.

A corner can have multiple clipping points within itself; however, there will always be definite entry and exit points. The player needs these definite entry and exit points as a type of “punctuation” to help memorize the circuit.

Further to this, by taking this approach, a track designer can come up with a circuit that is a combination of straights and corners.
Depending on the type of vehicle dynamics system that is being used, a combination of straights and corners can help assist in game balance by allowing equal catch-up opportunities for vehicles with different attributes.

Corners that have multiple clipping points are referred to as “compound corners” (Figure 9). The approach to ascertaining difficulty remains unchanged for compound corners. Distance between clipping points and the amount of correction required by the vehicle (as defined by extrapolating the angle between three points) are valid means for ascertaining difficulty.

It is important to note that different racing games will have different types of vehicle dynamics, which will ultimately dictate the way clipping points are used. This will be described in more detail during the case studies of Initial D and Maximum Tune.

Understanding clipping points and the how they subsequently impact on creating the race line is the most integral piece of the puzzle when taking a rational approach to track design. It is important to consider that a racing game is very much a twitch-puzzle game.

What this means is that the player needs to find elegant solutions to spatial problems by using the least amount of steering, braking and acceleration input. Although vehicle dynamics have been discussed, the type of dynamics system used by the game will have a significant impact of how designers should go about creating clipping points and race lines.
Metric 3: Track Width

Track width is one of the common-sense type metrics that is relatively easy to understand and implement. As a general rule of thumb, making the road wider will make corners easier as it creates a more obtuse angle for the clipping points and also provides some forgiveness in the track design (as seen earlier in Figure 3).

A commonly acknowledged rule for third person games is that the environment should be scaled up by a factor of around 33 percent, and the same applies for racing games and the scale of tracks. The reason this approach is used is to allow space for the camera to move through the environment, and also to create passing opportunities.

When designing the scale of a track, each lane should be 1.6 car widths wide, allowing three cars to be side by side in two lanes with a very minimal distance separating them (Figure 10). In addition to this, the road shoulder should be around 50 percent to 75 percent the width of a car (Figure 11).
This makes the player take a risk by taking this strategically powerful position — especially around corners where the lateral force will be trying to pull the vehicle’s mass against the player’s will. Having a wider section of track used for a corner will allow for more margin for error. Wider corners also give experienced players more ability to apply longitudinal force as the race line can become far more smooth.

Metric 4: Road Camber

Road camber is the metric associated with how the road’s pitch and roll angle will affect the car’s ability to turn-in to a corner (over-steer) or alternatively the car’s inability to turn into a corner (under-steer) (Figure 12). The terms under-steer and over-steer are related to describing vehicle dynamics, however on-camber and off-camber are terms associated with track design (Figure 13).

Daytona USA famously used a large amount of on-camber turns to allow for impossible corner entry and exit speeds, designed to empower non-drivers and reward them for little input. On the other hand, more realistic driving games such as Gran Turismo will use combinations of on-camber and off-camber corners to test the limits of the player and their chosen vehicle. This type of model ultimately requires more from the player in terms of practice and hence is not suited to an arcade environment.

Ideally, all corners in an arcade style racing game will be on-camber, as this allows for some bold and empowering cornering. Given the type of demographic attracted to these types of driving games, this is an ideal approach.

Metric 5: Height Variation

Height variation in track design fulfills two distinct purposes. The first is to create asymmetric balance which may favor or disadvantage certain types of vehicles and the second is to create tension, relief and the occasional “vista moment”. The latter of these two purposes is a topic in itself, and one that I have previously discussed in some detail in another article. However, to concisely summarize the two uses, we can consider that the first plays a game design role, which will either advantage or disadvantage certain vehicles based on their mass and power.

To paraphrase the later use, we can consider it to be a purely emotional component of both track design and level design in general. Limited line of sight will result in the player being anxious, as they are less able to plan ahead. When the player has increased line of sight, they feel empowered, as they are able to easily plan their moves several steps in advance. The previous article expands this concept in some depth.

From an emotional perspective, height variation makes tracks interesting, so long as it is used in moderation. Height variation can also be used to create “vista moments” for the player that add that extra wow-factor to the environment and the play experience.

These vista moments are usually achieved by restricting the player’s line of sight for an extended period by forcing them to travel up hill.

Once they reach the plateau and begin their subsequent downhill run, their line of sight is increased significant in comparison to the uphill run, allowing them take in a full view of the circuit and the level art. Once again, as this is such a significant topic, it is best to use the previous article as a starting point to investigate the concept further.

Putting the Metrics Together

Now that we have an understanding of the metrics of track design, it is time to apply these in the contexts of the two case studies. However as vehicle dynamics plays such a key role in understanding the design of racing games, it is necessary to differentiate Initial D and Maximum Tune by examining the types of vehicle dynamics that they use. Maximum Tune favors a type of driving called the “Scandinavian Flick”, whilst Initial D is characterized by a system which can be defined as “Race Line Punishment”.

The Scandinavian Flick

Figure 14 is an example of how the Scandinavian Flick works. The player hits the ideal entry point and then turns the vehicle towards the ideal clipping point.

Once the vehicle’s mass is heading towards this point, the player then counter-steers and aims the vehicle towards the ideal corner exit, eventually countering the vehicle’s inertia and transitioning the mass of the vehicle towards a different point in space using a combination of longitudinal force, lateral force and yaw. It is the excessive amount of longitudinal force used in the Scandinavian flick which differentiates itself from pure ‘grip’ forms of driving.

Earlier in this article, it was mentioned that lateral force is detrimental; however, the vehicle dynamics in Maximum Tune have been designed in such a way that small portions of lateral force are actually required for the ideal race line.

In the case of Maximum Tune, the vehicle will lose speed on the turn in, but will gain speed on the counter-steer. What this means is, in Maximum Tune, it is often more desirable to spend more time in counter-steer — and this subsequently means that in Maximum Tune most of the ideal clipping points are less than 50 percent of the way through a corner.

This is one of ways in which Maximum Tune addresses the issue of lateral force being detrimental. By having the clipping points earlier, it means that the majority of the corner is spent apply more longitudinal force than lateral force. Maximum Tune is able to make clipping points come earlier, by making the corner exits wider than the entries.

Missed Clipping Points

Both Maximum Tune and Initial D use missed clipping points as a way to punish players and provide overtaking opportunities. Figure 15 is an example of a player who has missed the ideal clipping point. In order to maintain the race line (and block the fastest possible way through a corner) the player will need to make a further correction, hence slowing the vehicle down unnecessarily.

A vehicle does not like to be disturbed by unexpected forces once in motion. Every time a correction is required, this places some extra and unexpected force of the vehicle, subsequently slowing it down or making its behavior erratic. In all racing games, a high corner exit speed is always the most desirable outcome for the player. These examples will be further expanded upon when examining the case studies.

Race Line Punishment

Initial D uses a system of vehicle dynamics which combines slip and grip vehicles and subsequently creates an asymmetrical relationship between vehicles — vehicles do not need plastic symmetry, as the combination of the player and the track will always create asymmetry.

Some will be more inclined to use Scandinavian Flick, whilst others will be pure grip, race-line vehicles, taking the most effective line through a corner. This asymmetric relationship means that the primary mechanic in Initial D is race-line punishment.

Figure 16 is a time-lapse example of two vehicles entering the same corner. The silver vehicle takes a less risky race line, however it opens itself up to being overtaken on the inside using the more risky, but subsequently more effective, race line. As the red vehicle is able to hit the ideal clipping point, it will yield a higher corner exit speed. The CX values of the vehicles (a measure of how much energy they absorb in the case of a collision) means that the red vehicle has the advantage in Initial D, as its mass will push the silver car off the ideal race line.

In both Initial D and Maximum Tune, the player needs to weigh up how they will approach the corners. Figure 17 is an example of player who takes less risk by allowing greater room for correction on either side of the vehicle. Although they are less likely to hit the sides of the road (and subsequently lose la significant amount of speed) they are also taking a less effective race line and subsequently allowing room to be overtaken on the ideal race line.

By taking the most risky line through the corner as seen in Figure 18, the player has the most to gain if they hit the ideal clipping point, but also the most to lose if they fail, due to the lack of correction space.

Generally speaking, when vehicles in a racing game collide with each other, they impose less inertial forces than hitting a track barricade. What this means in relation to driving games is it is more beneficial to hit another vehicle as opposed to any other obstacle, as the player will ultimately be able to maintain a higher level of vehicle stability. When the vehicle is more stable, it is more likely to accelerate quicker and corner more predictably as there are no other forces acting on the vehicle’s dynamics.

Initial D vs. Maximum Tune

So far we know that Maximum Tune and Initial D both have different approaches to vehicle dynamics and track design. However, they can both be described as highly empowering experiences for non-drivers. Both games provide a different experience and mood, so by analyzing some specific examples of track design within these games, we can come up with a track design language that will be useful when taking a rational approach to track design.

Characteristics of Maximum Tune track design and vehicle dynamics

Tracks are much wider as they are designed for four players, instead of two or three in Initial D

Much higher track speeds, so corners are more forgiving

Designed to have other NPC vehicles on the road during gameplay

Lead players can choose to take a different route through the course

Much fewer tight turns than Initial D

Characteristics of Initial D track design and vehicle dynamics

Two player network play against either the AI or other players, which emphasizes close, focused rivalries

Slower speed vehicles which operate on narrower tracks

Race line punishment

No traffic obstacles

Hanshin Express Line: Maximum Tune 3

The Hanshin Express Line is a popular track in Maximum Tune 3, and has a lot of similarity to the track design in Daytona USA — particularly the beginner circuit. The track is wide and has lots of sweeping, on-camber corners. Just like the Mt. Akina Circuit used in Initial D, the Hanshin Express Line is an embellished version of a real-world roadway — this one in Osaka, Japan.
As Maximum Tune is based around the illegal freeway racing scene epitomized by the manga series Wangan Midnight, there is an emphasis on creating tense yet flowing high speed maneuvering through regular traffic.

As mentioned earlier, Maximum Tune is able to implement its ideal clipping points early in the corner, hence allowing for greater corner exit speeds. The way that it achieves this is by making the corner exits wider than the entries. From an emotion point of view, this may sound boring. However, the designers of Maximum Tune have built in a clever feature to embellish the player’s actions and make them look better than what they actually are. This concept is known as needle threading.

Needle Threading: Maximum Tune

The Hanshin Express Line is epitomized by these needle threading corners. Put simply, a needle threading corner is one which provides a very wide corner entry point, an ideal clipping point (just one) and then the perception of a very narrow corner exit (Figure 19).

Needle threading corners have significant emotional value, and often give the perception of mastery for the players who are able to achieve them. Just like anything in game design, it is all about making the player look better than they actually are — especially in the highly voyeuristic environment of the arcade.

Figure 20 shows how this sense of mastery and achievement is achievement. As the player corrects towards the ideal corner exit point, the vehicle is still sideways whilst passing through this “needle thread” point, making the track walls closer to the vehicle. The positioning of the camera is purposeful and captures this impossibly accurate near-miss which would more often than not lead to disaster in real life — especially at the speeds cars are traveling at within the game.

When implemented a needle thread corner, the initial design needs to be done without the narrow exit point. If you look at Figure 20 and remove the barricade, we can see the design methodology at play. In Figure 21, you can see how the corner exit becomes noticeably wider than the entry, meaning that the ideal clipping point can be much earlier in the corner designs. The addition of the barricade is the illusion that the player needs to embellish their actions and make them feel empowered.

Asymmetric Balance: Initial D

The combination of multiple types of vehicle dynamics used within Initial D means that track design is of the utmost importance when trying to provide a balanced and empowering experience for the player. No track epitomizes this mantra more than Mt. Akina, an embellished version of the real world Mt. Akina road in Gunma Prefecture, Japan. Figure 22 is a planar map of the circuit. Although the track can played in either direction, the normal start line in sector one is the highest point of elevation and moves downhill progressively towards sector ten.

The type of vehicle that the player chooses at the start of the game will have a large impact on what types of track it will be best suited to.

A heavy car like the Nissan GTR will be balanced in such a way that it is usually more capable on an up-hill circuit where having more power is advantageous. A smaller car like the Toyota AE86 will have more of an advantage in down-hill circuits due to its lower mass and ability to over-steer on corner exits.

The Mt. Akina circuit uses a clever combination of corners to balance the gameplay and yield close rivalries, even without significant rubber-banding. Mt. Akina uses a unique leveling section in sector eight. If you are familiar with the Initial D franchise, then you will know the three consecutive corners as shown in Figure 23.

As the road markings play such an important role in the sensation of speed, they have been left in the diagram to demonstrate the sense of urgency that is conveyed to the player.

There are a number of metrics that need to be considered before the importance of this particular corner can be explained. In Initial D (and most other racing games) a compound corner which becomes progressively tighter will be advantageous for a lighter vehicle, whilst a compound corner which becomes progressively more obtuse will benefit a heavier, more powerful vehicle (Figure 24 & Figure 25).

There is also an additional component of compound corners which needs to be considered, and that is the correction distance between clipping points. To a large extent, this metric of difficulty can be explained by the angle extrapolation method covered in the clipping point metric. However, Figure 26 demonstrates the difficulty metrics associated with the distance between clipping points.

Figure 26
The reason the distance between these correction points is so critical is due to vehicle dynamics and Newton’s first law — an object in a state of uniform motion tends to remain in that state of motion unless an external force is applied. Figure 27 combines vehicle dynamics, distance between clipping points, and Newton’s first law. The point of critical weight transfer is used in Initial D to either advantage or disadvantage certain vehicles.

The Use of Straightaways: ID4 vs. MT3 vs. GT5

One thing that has not been covered is the use of straightaway sections in tracks. Straightaways are necessary in all forms of racing games, however if a straightaway is too long, then this will adversely affect the sense of empowerment for non-drivers.

Straightaways may seem fun on first glance: a section of road where the player can apply as much throttle as they want. However there is a significant problem if they are used incorrectly, especially in an arcade driving title. To understand the difference between more realistic straightaway use and use with arcade titles it is necessary to take a basic statistical overview of three titles: Initial D, Maximum Tune, and Gran Turismo.

Figure 28 compares speed telemetry data from experienced players in powerful cars within Maximum Tune 3′s Hanshin Line, Initial D Arcade Stage 4′s Mt. Akina and Gran Turismo 5′s Trial Mountain. Both Maximum Tune 3 and Initial D have the lowest standard deviation, whilst Gran Turismo has the highest deviation from the car’s slowest speed to its fastest speed.

The graph plots the vehicles’ speed telemetry at five second intervals and compares the current speed sample to the last previous sample. A value of 1 indicates that the vehicle has not changed speed since the last sample. Positive values denote an increase in speed and negative values denote a decrease in speed.

The graph demonstrates that in more realistic driving titles such as Gran Turismo, straightaways allow the vehicle to significantly overshoot the ideal corner entry speed, requiring the player to brake for extended periods prior to corner entry. This necessitates the player needing to learn the course, and takes away an aspect of forgiveness in the track design.

Console and computer games have the privilege of being far less forgiving. On a console, amateur players are not paying per play, hence allowing more time for practice and memorization. And most importantly, the home is a safe environment, away from the eyes of other gamers — it is safe to make mistakes, and the player can pick and choose the time when they take their skills public via online play or tournaments.

Arcade titles though need to pander to the ego. Players pay per-play and they do so under the watchful scrutiny of others. Although straightaways are used in all forms of track design, to empower the non-driver, it is essential that straightaways do not allow the vehicle to reach an excessively high speed prior to corner entry. If the straightaway does lead to a tight corner, then there should be a number of easier corners prior to this, allowing the player to shed sufficient speed before attempting corner entry.

Concluding Thoughts

The initial aim of this article was to examine ways in which non-drivers could feel empowered within racing games. Initial D and Maximum Tune are both excellent examples of creating an empowering experience and via the analysis applied to each, we can come up with a set of design heuristics, based on the five metrics of track design:

The use of straightaways needs to be implemented in such a way that the player is never able to significantly overshoot the ideal corner entry speed. Any braking should be kept to a minimum.
Corners need to be progressively tighter to ensure that players are able to have close to ideal corner entries.

The standard deviation in vehicle speed should be quite narrow, ideally within a plus or minus 30 percent region.

Road markings are essential to creating a sense of speed.

Needle threading corners should be used to provide a sense of awe for the player and embellish their skills.

All corners in an arcade racing game should be on-camber.

Height variations should always be used in track design to create emotionally diversity. Rapid changes in height should be avoided though.

Use straights to create “punctuation” for the player. Separate corners using landmarks or iconic features to aid this.

There are other elements of best practice which are beyond the scope of this article. There needs to be a clear distinction between actual difficulty and perceived difficulty. The best example of this is the comparison made between speed changes in Initial D and Gran Turismo. Initial D is very good at giving the player the perception of difficulty, when in fact they are doing very little in comparison to what they would need to do given the same track in Gran Turismo.

As such, the next big area to address is vehicle dynamics. It is important to note that different vehicle dynamics do not downplay the significance of the five metrics, rather it the vehicle will provide a significantly different experience for the player, especially in regards to these different approaches to building difficulty.

Special Thanks to Cliff Kamarga, Katie Murphy and Natasha Lewin for the images.（source:gamasutra）

开发笔记(1)

Wed, 16 Nov 2011 23:08:55 CST

折腾了好久，终于可以开始正式项目开发了。

之前的这段日子，我们陷落在公司的股权分配问题中，纠结于到底需要几个人到位才启动；更是反复讨论，到底应该做个怎样的游戏。林林总总，终于，在已经到位的几位同学的摩拳擦掌中，叮当决定自己挂帅开始干了。

就这么不到十个人，空旷的办公室，跟我们起先想像的情况不太一样。尤其是主策划还没有落定。我说，叮当，你好歹也是一资深游戏玩家，带了这么多年的游戏部，跟了这么多成功的项目，没吃过猪肉总见过猪跑吧，我就不相信你干着会比别人差。若不是我必须盯着程序实现这块，我都想自己做主策划了。不过有你干，我放心。

主策划的位置，咱们可以先空着，前期工作不能延。产品经理代理一下游戏主策划的位置也是创业公司必须的；正如我这挂牌的 CTO ，除了负责系统架构以外，也得兼个程序员做实现嘛。

经过两天对项目计划表的讨论后，我们今天就算正式开工了。

游戏是怎样的？半保密，不在这里多写，怕大家骂。再说了，这个东西现在说是怎样的，一两年后肯定有变化，多说无益，多解释无益。简单说呢，就是一个战斗系统类似魔兽世界，但系统核心玩法差异很大，更为轻松，更偏重 PvP 的 MMORPG 。为什么是这样一个东西，不想解释，反正不是拍脑袋想出来的。

既然是开发笔记，就写写现在在做些啥，打算怎样做下去。

我们先集体玩了一周魔兽世界，虽然大部分人已经是 wow 老玩家，但还是有一两个人玩的比较少，大家一起熟悉一下。主要是熟悉战斗系统，还有美术风格的感觉。培养点兴趣，对未来我们自己做的东西至少在表层上大家都有点感觉，有爱。

瞥开美术和策划的计划不谈，主要写写程序的计划。

在 Closed Beta 前，有 8 个历程碑，到一期截至，就开始有内部运行的版本。这次完全抛弃以往在网易积累的任何一点成品，全部从零开始做。但是，对于程序员来说，一切都在脑子里，其实工作量并不大。有机会重头来，恐怕是大部分程序员梦寐以求的机会。

当然，我们购买了一套 3d engine （不介绍，不解释），起点高一些。服务器也会尽量用一些成熟的开源库。

一期打算实现基本的用户登陆，场景漫游，包括在场景中做各种跑、跳、走、骑乘等动作。

一期程序员三人：

云风：负责总体规划，总体协议设计，以及部分服务器模块的实现。
怪物公司：负责客户端的设计与实现。
蜗牛：负责服务器的细节设计与实现。

吵架是我们的传统，自今天就开始了。按照惯例，我无法说服项目组认可我的所有设计和技术选择。不过大家妥协的结果是，先按我的想法做，一期雏形在下周末前完成，根据实现过程中遇到的问题，我们在修正甚至全部重构目前的设计。一周半时间的代价是目前我们可以承受的。

ps. 程序员就是这么一种奇怪的生物。好的程序员都有自己独立的思想。对自己实现或即将实现的代码有爱。按照别人的思想去实现是件无比痛苦的事情，会觉得在浪费自己的生命。所以，大部分有活力的项目开始都是一个人建立起来的。在大公司，好多老程序员都喜欢招聘所谓有潜力的新人，认为他们白纸一张，好塑造。说到底就是听话。但事实的结果一般是，要么培养出来一个庸才，无法担当；要么，在技术选择上最终分道扬镳。我总是对他们说，想想你愿不愿意总听着别人的意见干活？如果你不愿意，那么就别指挥别人干。自己不愿意做的事情，就别让别人帮你做。

我的设计草稿是这样的：

整个游戏系统（一期工程需要的）大体由这样一些部分组成：

客户端，运行在玩家的终端上，用一条 TCP 连接和系统通讯。它接入游戏服务器网关。
网关，负责汇总所有客户端，大体上和我很多年前的想法一致，虽然会有一些实现上的小改变，但思想没有根本变化。
客户代理(Agent) ，运行在网关的后端，在逻辑上，每个客户端都有一个 agent 负责翻译和转发客户端发来的请求，以及回应。众多 agent 可以实现在同一个进程中，也可以是多个不同的进程里。可以用脚本虚拟机的形式跑，也可以是别的形式，这些都不太重要。这一次，我们最大可能使用独立的 lua state 来实现单个 agent。
数据服务，保存玩家数据，场景数据等。前端用自己的代码和协议同系统其它部分沟通，后端这次想采用 redis 做储存。
场景管理器，用于管理静态场景和动态副本。
若干场景服务器，用于玩家在里面做漫游。

网关之后的服务是相互信任的，并组成一个虚拟网络可以相互通讯。通讯底层暂时采用 zeromq ，通讯协议采用 google protobuf 。

客户端到 agent 的通讯协议与网关后各个逻辑结点之间的通讯协议将隔离，分开设计。甚至不保证采用一致的技术实现方案，以及协议设计风格。

这里的设计关键在于 Agent 的设计，大部分的工作量是围绕它而来的。

单个 Agent 的工作流程代表了项目一期的结果会展现的东西，大体上逻辑流程如下：

等待用户认证
把认证系统交给认证服务器认证，失败则返回 1 重试。
从数据库获取用户数据(一期数据很少,仅有默认的用户名,用户形象) ，并转发给客户端。
取得用户所在场景号，从场景管理器取得场景服务的位置，并申请加入场景。
从场景服务器，同步环境。
转发用户在场景中漫游的请求，并同步场景的实时数据。
一旦客户端发生异常或得到推出消息，通知场景服务器离开。

这里，和历史上我们的游戏服务器设计有一个小的不同。我认为，用户的角色在场景中的位置，动作状态，甚至以后的战斗数值状态，都是属于场景数据的一部分，而不是用户数据的一部分。

用户数据中，和场景有关的只包括他当前所属的场景。由场景自己来保存角色在场景中的状态数据。简单而具体的说，类似网易历史上的西游系列，玩家的坐标是玩家的属性之一，是会在持久化时存放在玩家数据里的。经过我这两年的思考，我觉得这种设计方法是有问题的。

从我现在的直觉上来说，虚拟角色的属性不应包括角色的地理位置信息。那是角色的外在约束。而场景更应该拥有在它其中的 PC 和 NPC 的位置以及各种状态。PC 下线只应该认为是 PC 处于一种特殊状态（不被周围的 PC/NPC 所见或影响），而并没有脱离这个场景。所以我更愿意把 PC 下线定义成 detach ，而上线则是 attach 的操作。在这点上，场景，作为一个实体，拥有它自己的数据逻辑。

agent 相关的协议粗略的设计如下：

auth 登陆认证
- user/pass 取得 userid ，返回成功或各种失败
userdb
- 用 userid 取得 avatar list
- 用 avatar 取得 avatar data (包括场景名)
scene manager
- 用场景名取得 scene id
- 用 scene id 取得场景状态，返回允许进入或各种拥堵状态
scene
- 把 avatar attach 到场景
- 取得 avatar 的场景上下文
- 把 avatar detach 出场景
- avatar 设置坐标,速度,行为(跑,走,站立),方向
- avatar 骑乘状态改变
- avatar 做特定动作

好吧，未来一周的工作任务就是这些了。需要明天再做细化整理。然后就是实现了。

两人的故事 – 值得玩味的小游戏 | 小众软件 > 游戏

Fri, 18 Nov 2011 08:04:07 CST

这是一个关于爱，痛和生活的游戏，官方对它的解释是“ The story of a boy, the story of a girl, the story of both: One and One Story, a game about love, pain and life ”。@Appinn

在游戏里，男孩和女孩之间不管有什么困难和障碍都要在一起，这也是游戏的目的，为了达到这个目的，玩家会经历男孩和女孩之间具有不同背景的多种故事，直到最后的结局。

@root 给喜欢收藏的童鞋提供了离线版，另外随附一份离线视频攻略给不愿看 youXX 的 30s 广告的童鞋参考。。。

下载(14 MB): 115网盘 | 官方网站 | 来自小众软件

UberStrike HD – 画面精致 FPS [Mac] | 小众软件 > Mac

Fri, 11 Nov 2011 16:49:59 CST

刘傅二狗一直对 FPS 游戏有生理上的反感，每次见到画面晃来晃去忍不住头晕眼花。UberStrike HD 是 Mac 上为数不多让人头晕烟花来得更猛烈的射击游戏。地图精美，景色宜人。装备丰富，只不过好装备是要花钱的。@appinn

下载: MAS | 来自小众软件

列举独立开发者适用的数种游戏引擎

Thu, 16 Feb 2012 17:27:23 CST

作者：Gavalakis Vaggelis

人们时常想要自行制作游戏，也经常会有人组建起小团队，讨论新游戏的制作.。多数情况下，有不少团队程序员决定自行制作游戏引擎。我个人认为，任何游戏项目的参与者都应当考虑他们的目标。如果真得是为了制作游戏，那么就没必要费心费力重新制作游戏引擎。目前有大量的游戏引擎可供使用，让开发者开发游戏项目的过程变得更为简单。使用现有的游戏引擎能够让项目更为简单，也能更快地完成项目，保持精灵的合理运转。而且，使用现有游戏引擎几乎可以确保不出现重大漏洞，让游戏可以流畅地运行。

3D游戏开发引擎

Unity3D 3.1

Unity可能是目前独立开发者的最佳选择，可以顺利实现多平台开发。使用Unity，你可以借助迅速架构游戏原型和开发游戏。Unity的渲染&光照能力卓著，支持延迟光照、遮挡剔除、SSAO、Beast光照映射以及诸多后处理效果。Unity拥有对刚体、软体和布料的物理支持。Unity的编辑器用起来令人舒适，资产工作流程也非常棒。编程可以使用C#、JavaScript或Boo，而且Unity可以被扩展，因为它已经可以添加许多优秀插件。网络上有大量资源和帮助你入门的教程，而且拥有一个很棒的开发社区。

Unity Indie是免费的，但缺失许多功能，Unity Pro售价1500美元。如果你想要开发iOS或Android游戏，必须花钱购买授权。

Unity 3D(from gratisprogramas.org)

Shiva 3D 1.9

开发者通常将Stonetrip的Shiva3D与Unity相比，因为它们的使用方法及售价都很相似。与Unity相同，Shiva也有着很棒的整合编辑器，可以用来制作所有的内容。Shiva游戏可以发布到Windows、Mac、Linux、iPhone、iPad、Android、Palm、PSP和Wii上。Shiva的功能正符合开发者对现代游戏引擎的需求。

Shiva PLE是免费的，但是如果要发布游戏的话，有两个差别不大的授权可供选择。一个售价170欧元，另一个售价1500欧元。

shiva-editor-1.9(from shiva3d)

Leadwerks Engine 2

形象地说，Leadwerks Engine可以体现出现代技术发展水平。Leadwerks Engine中带有高效编辑器，可用来设计游戏场景，也可以用现已支持的LUA脚本语言来编写。事实上，Leadwerks Engine的游戏可以用任何语言来编程，因为该引擎被编译成DLL的形式。但是，目前支持的语言只有C#和C++，以往还支持Blitzmax。公司放弃了对Blitzmax的支持让我觉得很可惜，因为这是我最喜欢的语言。但是，该引擎有个很大的优点，就是其API或许是我目前见过的游戏引擎中最清晰和易于理解的。资源数量可能比不上其他游戏引擎，但是足够你使用。值得注意的是，Leadwerks Engine 3正在开发中，我已经迫不及待想看看这个新产品。

Leadwerks Engine 2的售价仅200欧元。

Essenthel Engine

我记得，当自己找到Essenthel Engine时它正处在开发早期。我下载了测试版，它的功能令我感到惊奇，在使用该引擎的数年时间里，它的发展仍足以令我大为惊讶。它支持所有的常见功能。Essenthel带有所有现代引擎应该包含的编辑器，编程语言只能使用C++，至少对我来说这是件很不幸的事。然而，Essenthel Engine带有的编辑器和工具设计不佳而且不够直观。Essenthel游戏能够兼容任何苹果设备，这也算是该引擎的一大优势。

根据你的游戏收益和所需的引擎源代码数量，授权版本的售价从150美元到40万美元不等。事实上，1000美元的版本就可以满足多数人的需求，所获源代码足够用来开发游戏。

GameCore 2.5

虽然这个引擎的知名度并不高，但GameCore 2.5提供了绝妙的图像质量、延迟光照、物理效果以及我见过的最好的编辑器和美术传输途径。输入模型并为其制作材料显得简单易懂。所制作游戏可以发布到PC、Mac和Web上。GameCore 2.5有自己的脚本语言，语法与C语言风格相似，易于使用。

GameCore 2.5 Indie是免费版本，但存在些许局限性，Pro版本的售价为1500美元。

gamecore(from crearevideogames.blogspot.com)

S2 Engine HD

S2 Engine HD还未发布，但是我想把它添加到这个列表中。S2Engine有可能成为一款优秀的游戏引擎，带有丰富的图像、AI和令人惊叹的编辑器。

它的售价为200欧元，如果你想要C++ SDK的话，需要支付2000欧元。

2D游戏开发引擎

Construct 0.99

Construct是款用于2D游戏开发的游戏引擎，可能是最简单的游戏引擎之一，它完全不需要编程知识，因为它是个基于可视事件驱动的系统，类似于老式的Multimedia Fusion软件。可在Construct的编辑器中执行开发，引擎可以通过其插件架构来扩展。我推荐你了解下这款游戏引擎，因为它是免费和开源的。

construct-0.99(from construct.softonic.fr)

Gamemaker 8

Gamemaker已经被用来制作出许多游戏。这是款2D游戏引擎，精致整合的编辑器带有许多功能。它有可视事件驱动系统，但是也支持直接进行简单的编程。Gamemaker的一大优势是良好的支持性和教程，还可以用许多扩展和插件来扩展引擎的功能。

Gamemaker 8的售价只有25美元，但是还有个受限的免费版本。

Game Maker 8(from Software downloads)

Game Editor

Game Editor也是款事件驱动游戏引擎，也是开源的。它有着清爽简单的界面，可以胜任多平台开发，包括智能手机、Linux、苹果设备和Mac。程序说明书做得很棒，而且还有许多教程让你可以轻松上手。

Game Editor(from itunes.apple.com)

Adventure Game Studio 3.1.2

AGS是款用来制作2D指向点击冒险游戏的游戏引擎。有许多冒险游戏（游戏邦注：例如《7 Days a Skeptic》）便是用这款引擎制作完成。所有的开发都在AGS编辑器内完成，你可以制作场景、可移动和可点击区域、UI和事件。制作简单冒险游戏不需要编程，但是引擎也能够支持编程，这样便能制作更多高级的游戏。尽管游戏质量不算很好，但这个引擎确实是经典老式冒险游戏的最佳选择。

AGS是免费引擎。

7 days a skeptic(from nuverian)

Visionaire Adventure Studio 3.4

与AGS相似，Visionaire Adventure Studio也是款用来制作指向点击冒险游戏的游戏引擎。但是与AGS相比，Visionaire Studio显得更为清晰，而且有更多的功能，比如PNG支持，图像质量也更好。引擎的可视事件系统与AGS相似，能够定义可行走和可点击区域。

Visionaire Adventure Studio的售价为35欧元。

Visionaire Adventure studio(from nuverian)

其他引擎

DX Studio

DX Studio是用来制作互动3D图像的综合性开发环境。系统由即时3D引擎和一套编辑工具组成。你可以使用DX Studio来构建全即时互动应用、模拟或游戏，可以独立使用，也可以嵌入其他Microsoft Office/Visual Studio应用中。

Torque 3D

Torque 3D是目前最易于使用的游戏制作平台。Torque 3D以Frontline优秀的Torque Game Engine Advanced为基础构建而成，配备一整套制作游戏的工具和API。游戏的发布平台包括PC、Mac、Xbox 360、Wii、iPhone和web。

Haaf’s Game Engine

HGE是款易于使用而且强大的硬件加速2D游戏引擎。对于想要方便迅速地开发带有商业化质量的游戏的人来说，这是款全功能中间件。它支持所有你能够想到的2D游戏题材，你可以制作从简单的谜题游戏到高级的多层次平台或战略游戏等各种类型的游戏，甚至无需去思考任何游戏逻辑代码！而且，你无需知晓任何有关“窗口信息”和DirectX编程之类的内容。你可以在拿到引擎的15分钟时间里开始开发自己的游戏。

C4 Engine

C4 Engine是款综合性的游戏编程工具，主要针对Windows和Mac OS X平台。它不仅是强大的3D图像引擎，而且还包含对物理、音频、连网、输入设备和资源管理等方面的多方位支持。

Neoaxis Engine

NeoAxis Game Engine是款用于3D模拟、形象化和游戏制作的多用途现代3D图像引擎。NeoAxis Engine是个用来制作互动3D图像的综合性开发环境，可以针对3D虚拟世界、AAA游戏和现实模拟类游戏。系统由即时3D引擎和一套全功能工具组成。

fixel 2

“它使Flash游戏制作发生变革。它是人机对接的新方式。它标志着游戏开发新时代的来临。我们将全部内容放在了新的flixel 2中。组别有助于组织游戏物体，象限四分数可实现更快更精确的碰撞，更清晰的API，同时包含所有老flixel的经典内容：动画精灵、位图和颗粒发射器。最为重要的是，flixel的个人或商业用户来说仍是完全免费的。你还在等什么呢？是时候开始制作游戏了。”

SIO2

什么是SIO2 Engine？SIO2是款基于OpenGLES的跨平台2D和3D游戏引擎，提供所有现代游戏引擎所具有的功能，而售价比同质量引擎要便宜得多。功能丰富、快速灵活的SIO2允许你针对最喜欢的手机平台制作出堪比AAA游戏的美术效果。与其他解决方案相反，SIO2不会强迫你使用任何特定IDE来编程或构建游戏。

Realm Crafter 2

Realm Crafter游戏引擎是MMORPG开发系统的核心。该引擎能够制作出虚拟游戏世界和世界所包含所有东西的行为。它能够生成3D图片，处理连网通信。Realm Crafter引擎显得模块化，这意味着它能够被分解成较小的单位，从而使你可以更轻易地自定义其操作。

游戏邦注：本文发稿于2011年1月17日，所涉时间、事件和数据均以此为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

The Best Game Engines for Indie Game Developers

Gavalakis Vaggelis

People very often want to make a game either for fun or to sell it later. Very often small teams are made and begin the discussion about their new game. It has happened to me before many times and where I utterly disagreed with others, was in the subject of choosing a game engine. Most often, the programmer or programmers of the team decide they make their own game engine. I personally believe that the people in any game project should consider their goals. Is the goal to actually make a game? Because if it IS to make a game, then there is no reason for them to reinvent the wheel. There are tons of game engine out there that make the development of a game project much easier for the developers. Using a pre existing game engine makes the project easier, much faster to complete and keeps the spirit going since there is a relative good progress. Also using an existing game engine makes it almost sure that it has no major bugs, runs smoothly and is production ready anyway. I completely agree with people wanting to make their own engine, but then the goal is the game engine and not the game and thus no music compositor, modeler, texture artist, game designer etc are needed to be involved and in consequence loose interest cause there is actually nothing for them to do. But enough of my ranting.

In conclusion there are many game engines for a team to consider using. I believe that a multiplatform solution is good enough for starting teams, because of the target audience their game can have. The iDevices and Android platforms especially are a good consideration since they have really a lot users and at the end most of the games on those devices are simple to make, thus they cost low and people will buy them, making the team motivated to move on to their next project and in consequence earning experience and possibly some fame.

- 3D –

Unity3D 3.1

Unity is probably the best choice for indie developers right now, that want a multiplatform development without complications. With Unity, you can develop and prototype games real fast with true WYSIWYG capabilities. Unity’s rendering & lighting capabilities are state of the art, supporting deferred lighting, occlusion culling, SSAO, the Beast lightmapper, many post-processing effect and many more. Unity has physics support from rigid bodies to soft bodies and cloth. Unity’s editor is a joy to work and the asset workflow is also very good. Programming can be done in C#, JavaScript or Boo but also Unity can be extended as it has already been done with some great addons. There exist vast resources and tutorials to get you started and a great community.

Unity Indie is free though it’s missing many features, while Unity Pro costs 1500$. If you want to develop for an iDevice or Android extra licenses must be bought.

Shiva 3D 1.9

Stonetrip Shiva3D is commonly compared to Unity for their similarities in way of use and price. Shiva offers a well integrated editor just like Unity that everything is made from within. Shiva games can be published to Windows, Mac, Linux, iPhone, iPad, Android, Palm, PSP and Wii without complications as well. Shiva’s features are many just like anyone could expect from a modern game engine.

Shiva PLE is free but to publish a game there are two licenses with very few differences. One at 170E while the other at 1500E.

Leadwerks Engine 2

Graphically, Leadwerks Engine is state of the art. Leadwerks Engine comes with a WYSIWYG editor to design your scenes but also to program them in the now supporting LUA scripting language. In essence, Leadwerks Engine’s games can be programmed with any language since the engine is compiled as a DLL. The supported languages though are C#, C++ and was Blitzmax. A shame they drop support on Blitzmax though, since it was my favorite. Anyway A big bonus is that the API of Leadwerks Engine, is probably the most clean, easy to understand than everything I’ve seen so far. The resources might not be as many as in other game engines, but they are well enough to get you along. Worth of note is that Leadwerks Engine 3 is in development and I can’t wait.

Leadwerks Engine 2 costs only 200E.

Essenthel Engine

I remember when Essenthel Engine was in early development and found it. I downloaded the demo and got amazed and after some years I am following it, I am still amazed by it’s progress. It support all common features out there and even more. Essenthel comes with an editor as all modern engines should and programming is done only in C++ unfortunately for me at least. The editor and the tools that come with Essenthel Engine are unfortunately very badly design and non intuitive. Essenthel games can also be published to any iDevice, which is a big plus.

Licenses range from 150$ to 400,000$ depending on how much income you have and the amount of source codes you want of the engine. Truth is that the 1000$ license will suit most just fine, with great access to source codes.

GameCore 2.5

Although this engine is a bit obscured, GameCore 2.5, offers excellent graphics quality, deferred lighting, physics and one of the best editors and art pipeline I’ve seen. Importing a model and making a material for it is so straightforward. Games can be published to PC and Mac as well as on the Web. GameCore 2.5 has its own scripting language with a c-style syntax that’s easy to use.

GameCore 2.5 Indie is free with some minor limitations, while the Pro version costs 1500$.

S2 Engine HD

S2 Engine HD is not yet released, but I felt like adding it in this list. From what it seems, S2Engine must be a great game engine featuring rich graphics, AI and fantastic editors.

It costs 200E or 2000E if you want the C++ SDK.

- 2D -

Construct 0.99

Construct game engine is one of those gems that you fall upon randomly. Not kidding. It’s a game engine for 2D games development and possible one of the easiest since it require little or no programming at all, since it is based on a visual, event driven system instead of pure programming, similar to that of the old Multimedia Fusion software. Development is done inside Construct’s editor and the engine is expandable through it’s plugin architecture. I really recommend you take a look at this game engine since most importantly its free and open-source.

Gamemaker 8

Gamemaker has been used to create many games. It’s a 2D game engine with many features in a well integrated editor. It has a visual event driven system but also support direct easy programming. The big plus of gamemaker is the great support, tutorials and real many plugins and addons that are out there to extend the engines capabilities.

Gamemaker 8 costs only 25$, but there is also a limited free edition.

Game Editor

Game Editor is another event driver game engine that is also open source. It has a nice and easy interface while there is the ability for multiplatform development, including Smartphones, Linux, iDevices and Mac. The documentation is good and there are also some tutorials to get you started.

Adventure Game Studio 3.1.2

AGS is a game engine to create classic 2D point & click adventures. It has been used to create a LOT adventure games with my personal favorite to be 7 Days a Skeptic. The whole development takes place in the AGS editor where you create the scene, walkable & clickable areas as well as UI and events. To create a simple adventure, no programming is requires although programming is supported for more advanced games. Don’t expect anything great in quality but hey…this is a targeted to classic old style adventure games.

AGS is free.

Visionaire Adventure Studio 3.4

Similar to AGS, Visionaire Adventure Studio is an engine to create point & click adventures. Compared to AGS though, Visionaire Studio is a bit cleaner and has a bit more features like PNG support (AGS doesn’t) but certainly much better graphical quality. It’s similar to AGS as in the visual event system and defining walkable and clickable areas.

Visionaire Adventure Studio costs 35E.

- Honorable Mentions -

DX Studio

“DX Studio is a complete integrated development environment for creating interactive 3D graphics. The system comprises of both areal-time 3D engine and a suite of editing tools. Using DX Studio you can build complete real-time interactive applications, simulations or games, for standalone use or for embedding in other Microsoft Office/Visual Studio applications.”

Torque 3D

“Welcome to Torque 3D, the most easy-to-use game creation platform available. Architected from the ground up for maximum flexibility and performance across a wide range of hardware and built upon the Frontline award-winning Torque Game Engine Advanced, Torque 3D comes equipped with a full suite of tools and APIs to get your game to the finish line, no matter what your goals. Add publishing paths to PC, Mac, Xbox 360, Wii, iPhone, and the web, and you have the power to distribute games almost everywhere they are played.”

Haaf’s Game Engine

“HGE is an easy to use yet powerful hardware accelerated 2D game engine. It is a full featured middleware for all who want to develop commercial quality 2D games rapidly and easily. It covers all imaginable 2D game genres: you could create everything from a simple puzzle to advanced multilayered platformer or strategy without even thinking of any non game logic code! And you don’t have to know anything about “window messages”, DirectX programming and all that stuff. Instead you can start developing your own game within 15 minutes!”

C4 Engine

“The C4 Engine is a comprehensive suite of robustly implemented game programming tools for the Windows and Mac OS X platforms. Not only is it a powerhouse of a 3D graphics engine, but it also includes integrated support for physics, audio, networking, input devices, resource management, and much more.”

Neoaxis Engine

“NeoAxis Game Engine is an all-purpose, modern 3D graphics engine for 3D simulations, visualizations and games. NeoAxis Engine is a complete integrated development environment for creating interactive 3D graphics including 3D virtual worlds, AAA games, and realistic simulations. The system comprised of both a real-time 3D engine and a suite of full featured tools.”

flixel 2

“A revolution in Flash game production. An amazing new way for man to interface with machine. The beginning of a new tomorrow. Never before has the world witnessed such a collection of AS3 files. We put it all in the new flixel 2. Groups to help organize game objects, quad trees for faster, more accurate collisions, a cleaner API, plus all the old flixel classics: animated sprites, tilemaps, and particle emitters. Most importantly, flixel is still completely free for personal or commercial use. What are you waiting for? It’s time to make games!”

SIO2

“What is SIO2 Engine? SIO2 is an OpenGLES based cross platform 2D and 3D game engine which provides you all the modern game engine functionalities built in right at its core for your mobile devices at a fraction of the regular industry price for the same type of quality. Feature rich, extremely fast and flexible SIO2 allows you to create state of the art AAA games for your favorite mobile platform. As opposite to other solutions, SIO2 doesn’t force you to use any specific IDE to code or build your games.”

Realm Crafter 2

“The Realm Crafter game engine is the heart of the MMORPG development system. The engine creates the virtual game world and the behavior of everything in it. It generates 3D images and handles the network communications. The Realm Crafter engine is designed to be modular, meaning it is broken down into smaller units thus making it easier for you to customize its operations.” ( Source: nuverian.net)

【可爱切切】超级理发师：Super Cuts

Thu, 02 Feb 2012 09:41:55 CST

感谢 AC米兰, 咕嘟咕嘟～, Pisces, 书涵, 阿灰, 夜太黑, 天下游子, fastknot 在爱分享中留言分享！

App简介:

这是一款非常有趣的漫画风格的切切类休闲游戏，通用版本加上可爱的画风，可谓是老少咸宜，不容错过。

在游戏中，玩家是一名敬业的理发师，你的面前就是一只理发椅，形形色色的客人流水般的在你面前不断出现，而你要做的就是抓起一缕头发，在最合适的位置喀嚓一下，即可获得积分啦，连续而准确地理发切割将会获得更多的奖金哦。

游戏中有着大量的风格独特的人物造型，他们都有自己的发型需求哦，快来试试吧。

注：本作品限免结束时间未知，喜欢的朋友速度收下。

 视频见正文…

App截图:

App下载地址:

点击此处下载（来自 www.iapps.im）




$0.99 限时免费
大小: 48.7 MB
系统: 4.2+

您可能也喜欢：
超级泡泡: Super Juicy	【重口味】超级蠕虫：Super Mega Worm	【联系人工具】超级搜索：Contacts Super Search	超级橄榄球: Super Football Kick 3D	超级滚珠球：Super Marble Roll
无觅

F2P深度解析（5）：为什么越来越多的游戏转向F2P？

Wed, 25 Jan 2012 09:11:19 CST

随着F2P的强势崛起，越来越多的游戏开始向F2P转型，如City of Heroes、LEGO Universe、Age of Conan、LOTRO等。但有没有想过，为什么这么多游戏选择F2P这种新型的模式呢？以下是与此相关的一些问题及其解答：

1）为什么F2P模式可行？

F2P游戏为玩家提供了永久免费玩游戏的机会，在不用付钱的情况下体验各种虚拟世界、社交活动等等。少部分玩家（通常为1%-20%）会选择游戏内消费，如花钱买时间加快作物的生长速度、购买装饰品将自己的角色打扮得更炫丽优雅、提高能量等级等。此外，还有很多其他的消耗品变体，且开发者们正在加快这类消耗品的推出速度。

2）为什么很多基于订阅的MMO游戏转向F2P模式？F2P对他们的业务有什么样的影响？

用一句话来概括就是，因为F2P是一种很好的商业模式。

大家都知道，订阅是玩家玩游戏的一个障碍，游戏公司必须首先说服玩家愿意每月定期支付一定数量的费用。而F2P将玩家从订阅模式中解放出来，让更多的人可以无条件接触到游戏，同时鼓励忠实玩家自由消费。Dungeons & Dragons Online游戏的开发商表示，自采用F2P模式以来，他们的收入增加了五倍。相比其他传统模式，F2P帮助游戏公司通过服务较少对象，管理更具意义的业务，这也是向F2P快速过渡的一个主要原因。

3）F2P是一种长远方案，还是临时替补？

F2P是一个具有长远战略意义的双赢方案，绝非临时或短期替补。

对玩家来说，他们可以免费玩各种游戏，包括一些以前他们通常很难接触到的游戏，还可以自由选择是否进行游戏内消费，以及在哪些方面进行消费等等。

对游戏公司来说，可以吸引更多的玩家来体验他们的游戏，与大量粉丝共享他们的创造成果。这意味着他们不需要再花费太大力气进行宣传，就可以收获庞大的用户群，推出成功、盈利的游戏。

4）如何将F2P整合进MMO游戏？

微交易在F2P游戏中起着十分重要的作用，如《魔兽世界》（World of Warcraft）和《星战前夜》（EVE Online）在这方面做得很成功。F2P很好地整合了付费游戏和免费游戏，既融合了付费游戏的用户忠诚度，同时也融合了免费游戏用户进行游戏内消费的随性。

在未来三年，预计大多数MMO游戏（大型多人在线游戏）都会转型F2P。虽然Warcraft、Eve、Rift和The Old Republic等大型游戏仍有可能会保持原来的模式不变，但很多其他的MMO游戏则很可能会抓紧F2P这一难得的机遇。

Via GB

社交游戏终极指南专题(3)：社交游戏的价值

Mon, 23 Jan 2012 14:16:07 CST

有人问了一个有趣的问题：你认为 Facebook游戏对玩家还有价值吗？如果隐私得到保护，你还会申请另一个账号吗？答案当然是Yes，以下就是详细解答：

首先你需要忘记一点，Facebook游戏不是只有类似Farmville这样一种游戏类型，如果说Facebook的所有游戏都和Farmville一样，无异于说所有的PC游戏都和多玩PC游戏Solitaire一样，Facebook也有好坏之分，每个人眼中的好坏也有不同的定义，或许有的游戏在你看来很差，但在别人看来却好

我认识的一位女性玩《魔兽世界》时，觉得太困难而不愿继续，而对我认为非常烦闷的Cityville却能挥洒自如。

所以，每种游戏都有它的观众群，Facebook的目标观众通常是不常玩游戏的玩家，在Facebook游戏中要找到一款好游戏很不容易，必须从大量垃圾游戏中淘，许多网站对Facebook游戏的评价都基于成千上万的玩家，然后这些游戏一般都不太复杂，不是真正的游戏玩家在午休时间也可以玩。虽然不能就此评论一款游戏的好坏，但对你我这样的玩家来说就不适合。

另一个警告就是，如果“隐私曾经不是问题”，那么Facebook隐私“现在”就是个问题，在Facebook上用的真实姓名与你的真是好有进行玩，会存在很大弊端，除非你所有朋友都是Facebook游戏粉丝，Facebook游戏都会产生许多垃圾邮件，所以你作为Facebook游戏玩家的身份就很容易暴露，而且许多Facebook游戏都是社交化的，在游戏中，你需要与朋友合作来闯关，或者花许多的钱来购买道具，不用向好有索求。

现在许多人认为Facebook游戏的这种社交化特征让Facebook游戏越来越不值得玩，这完全可以理解。但作为一个游戏分析师，我更赞同将游戏设置与商业模式分开，比如你花一百万美元去购买一款好的电脑游戏版权，游戏可能非常好，但成本确让许多人无法接受，如果你用真名注册一个Facebook账号，在上边有你的现实好友和亲戚，这样如果你在Facebook上看到一款非常好的游戏，那么你就会跳过，因为你无法接受将游戏推广给你好友所产生的高额成本，于是我和许多朋友注册假名，相互之间发送垃圾邮件来推荐游戏，通常我会拒绝Facebook游戏上的社交成本，这也是Facebook把我账号禁止的原因。

现在确实有一些Facebook游戏停止了垃圾邮件推广或付费购买的商业模式了，只有你的好友才知道你有多爱玩游戏，你的简介及其它隐私设置都会受到保护，不认识你的人根本不知道你的游戏习惯。

不同的游戏都有不同金额的社交成本，如果你愿意支付那些社交成本，就会发现很多好的Facebook游戏

Via TB

【iPad益智】平衡物语两款：Perfect Balance & Imperfect Balance

Sun, 22 Jan 2012 08:46:35 CST

精选限时免费应用，由 AppPusher 为您送达！无限精彩，尽在爱Apps - www.iapps.im
本站原创内容，转载时请务必注明出处，谢谢！



$0.99 限时免费
大小: 53.9 MB
系统: 4.2+




$0.99 限时免费
大小: 37.3 MB
系统: 4.2+

感谢 crypupa, 小野猫,Fate.汶, 咕嘟咕嘟～ 在爱分享中留言分享！

App简介:

我们曾经推荐过该游戏Perfect Balance的iPhone版地狱篇 ^(链接) ，而在今天的这款iPad版本中，整合包含了iPhone版同系列的四个篇章（人间篇、地狱篇、天堂篇、还有失落空间篇），共有340个关卡，可谓非常超值。

同时，该开发商新出的一款Imperfect Balance HD也展开了限时免费活动，因游戏内容相近，包含了150个关卡，就一起推荐给大家吧。

将屏幕顶部的几何体放下来，并尝试让他们停留在屏幕中而不掉落出屏幕外，这需要你实现完美的平衡技巧，340个独特的关卡挑战，这可不是一份轻松的活儿。

在2009年，该类型游戏第一次出现在Flash大赛上，超过900万的玩家进行了挑战，此后在全球获得了广泛关注，如今，自然也来到了iOS平台，该开发商旗下有多款不同系列的同类游戏.

App截图:

App下载地址:

点击此处下载（来自 www.iapps.im）

您可能也喜欢：
平衡世界: Perfect Balance	【益智精品】平衡物语：地狱篇-Perfect Balance: Inferno	【物理解密】完美平衡：天堂版 - Perfect Balance: Paradise	【击鼓传花】平衡炸弹：Balance Bomb	【国产佳作】手指平衡球：Finger Balance
无觅

移动游戏的架构艺术

Fri, 03 Feb 2012 18:05:11 CST

游戏是一门综合的艺术，作者以铸剑为喻，形象地展示了移动游戏架构的艺术之美。

艺术是人的知识、情感、理想、意念综合心理活动的有机产物，是人们现实生活和精神世界的形象表现。文学可以是艺术，雕塑可以是艺术，音乐可以是艺术，电影可以是艺术……那么游戏呢？

游戏是一门综合的艺术

无论是单机游戏还是网络游戏、PC游戏还是手机游戏，都需经过如图1所示的逐步进化的过程。

图1 游戏研发的流程

任何一款游戏，都有故事情节、人物、场景、音乐和音效等内容，因此其中每一部分内容都需要追求以艺术化的手段，将游戏的意象情景更生动地展现给用户。作为程序员的我们，之前可能只是以为只有策划人员需要通过艺术来表达游戏的内容、测试人员需要带着艺术去欣赏并完善游戏的体验，那么程序员对游戏的架构和艺术之间又是怎么挂上钩的呢？

用程序语言铸造艺术之剑

从古至今，有不少人热衷于铸剑，而铸出的剑是否称得上艺术作品，关键就在于它是否能表达出铸剑人的情感和用心所在。那么对于游戏程序的架构来说，也需要能体现出架构师对游戏的整体架构和每一个模块的把握，以及赋予它们的“神力”；同时，好的架构还将贯穿于游戏开发的整个过程。简单的测试一下，你是否也会遇到以下这些问题呢？

感觉游戏框架非常混乱，毫无条理？
开发完成后出现大量Bug，并且不知从何下手去解决？
出现很多难以重现的致命Bug？
添加某个功能或模块非常困难？
经过频繁的修改之后，出现大量冗余代码？

如果出现上述问题，那么说明我们所使用的这把架构之剑并不锋利，可能没有将“力”用在剑刃上吧。这也从另一方面体现出铸剑过程（也就是游戏的架构）的重要性。如果带着这些问题继续锤炼，那么终将铸成一把绝世宝剑。

架构是一个看不到也摸不着的虚幻东西，因此，我们还是结合具体的实例来分析如何将架构艺术化，通过代码来表达架构思想。假设现在有一套策划案，并且美术人员能够为我们准备所需要的资源。

“采矿”是铸剑之根本

有了铸剑的意念，就需要去选择各种高品质的玄铁矿石。同样，对于游戏的架构来说，就需要对游戏的各个功能模块进行分析，针对每个模块需要实现的功能和特殊属性进行抽象，概括出各个模块所需要定义的数据结构和接口以及各模块之间的关系。然后，再根据策划文档整理出适合编写程序的流程图、关系图、结构图等。最后，根据这些文档资料配合游戏的运行环境（比如游戏运行的平台）对实现技术进行需求分析，该分析主要针对功能和性能进行。下面我们以Android和iPhone两大平台为例进行分析。

在Android平台上，从效率的角度考虑，可以选择C/C++作为开发语言、OpenGL|ES作为图形库；从简单方便的角度考虑，可以选择Java作为开发语言、Skia作为图形库。

而在iPhone平台上，从跨平台的角度考虑，可以选择C/C++作为开发语言、OpenGL|ES作为图形库；从开发的难易程度考虑，可以选择Objective-C作为开发语言、Quartz2D作为图形库。这里我们没有考虑3D的特殊问题，如果进行3D游戏开发，必然会选择OpenGL|ES。另外，在iPhone平台上使用Quartz2D作为图形库开发游戏的比较少。

如果要做的是一个跨平台的游戏，我们还需要分析各平台的跨平台能力和特性（包括开发语言、渲染库、资源管理、内存管理等），例如iPhone中内存管理采用了引用计数的机制，那么可以考虑通过C++来实现一个类似的机制，这样就可以保证其他平台也都可以通用该机制。

这里我们也没有刻意地对某个语言和库进行比较，因为它们通常都有各自的优势，需要根据具体的游戏需求进行选择。准备好铸剑的玄铁之后，下一步我们开始铸剑（编写代码）了吗？

“剑范”决定“剑气”

“剑范”即铸剑所用的模型，“剑气”即剑品的气势，因此，铸剑所用的模型将最终决定宝剑的“主题”。

“剑范”的打造对应于游戏架构中负责全局范围的核心框架，该框架是否合理，将决定整个架构的成败。说到框架，不得不说说大家可能都比较熟悉的MVC框架，作为程序员，应该没有谁不知道MVC的定义，但是关键在于如何从更深层次去学习它，理解它，运行它。曾经一位朋友问我：“你们通常采用什么框架？什么框架会比较好呢？”我回答：“MVC框架啊！”看着他一脸吃惊的表情和一句“也很普通的框架！”的回答，我真不知道说什么好！MVC框架的确很普通，也很简单，而如何让它发挥出其本身的功效却是关键！例如，在iPhone开发中，苹果公司就推荐采用该框架，具体描述如下：

视图（V）：由UIView类的子类及其相关的UIView-Controller类来提供；
控制器（C）：控制器行为通过主要由委托、目标操作、通知来实现；
模型（M）：通过数据库和数据含义等协议提供逻辑模型，由控制器进行管理。

另外，就连目前红遍整个互联网的Android系统来说，Google官方也同样推荐使用MVC框架来开发和维护应用程序，具体描述如下：

视图（V）：由View和SurfaceView（或者自定义的视图）提供用户的界面，采用XML格式进行布局；
控制器（C）：由Activity来管理视图和逻辑模型；
模型（M）：向视图提供逻辑模型，由控制器来触发，比如各种Adapter接口。

根据切身的经历，我得出了下面的观点： “如果不能保证将其他的设计模式运用好，就不如选择类似于MVC这类的简约而不简单的框架来完成，可能结果会更精彩！”

由此可见游戏架构中框架的重要性。如果你还觉得不够，那么我建议应该向众多的Android和iPhone开发者询问答案，苹果和 Google的文档将是你最好的学习资料！相信你已经跟着我们的脚步，打造出了适合你自己的 “剑范”了，现在是时候开始铸剑了！

真金不怕火炼

宝剑品质的好坏在于使用的原材料，如何检验矿石的材质？还得看准备的火力是否强劲。现在让我们回到游戏架构的话题。

首先，尽管通常游戏中可能会存在多个视图、多个模型甚至多个控制器，我们还是将一款游戏分为三个大的模块，即MVC的控制器、视图、逻辑模型。图2为我当前正在开发的一款Android游戏的框架。

由图2可以看出，程序从入口Activity进入，通过setContentView()函数设置显示一个视图类MainView时，游戏的主线程已经开始Loop了；而游戏要显示的具体场景则由控制器Control类根据游戏状态等信息通过getCurScene()函数得到，得到的场景实际上是抽象场景SceneInterface类的子类（如SceneA）；在SceneInterface中包括各个场景的公共接口，以便在Control.control()中能直接控制当前显示的场景，需要注意的是，在控制器中一般需要先通过SceneInterface.reCycle()来对上一个界面产生的垃圾进行回收，同时对逻辑模型类Model中的数据进行处理。

图2 MVC游戏框架

由于图片大小的原因，我没有列出全部类结构，这些类包括在SceneInterface中定义一个界面事件的公共接口或者对Model采用“实体—对象—类”的方式进行扩展以及所需的工具类。

铸剑的最高境界—指导练剑之人

好的宝剑通常可以提高用剑之人的剑术！Google和苹果所铸造的Android、iPhone这两把宝剑，指导了无数的开发者。我们又何不学习学习Google和苹果这两位铸剑人的技艺呢？

下面继续分析Android可能会如何指导“练剑人”。在做Android应用开发时，Google推荐通过XML文件来布局界面，从而让UI界面和程序逻辑分离，方便维护；实际上Google对XML文件以及其他资源都进行了优化，这样做可以提高程序的运行效率。下面我们也将学习这一招，通过XML文件来布局游戏场景。

首先，将一个游戏场景（SceneA）中需要显示的内容分为UI界面（如按钮、菜单等）和游戏对象（如精灵）两部分；其次，UI界面和游戏对象可能都需要动画；最后，既然要使用XML文件来布局，就需要一个专门的解析器。稍作整理，现在我们所需要的模块如图3所示。

图3 游戏场景架构

图3描述了一个场景的元素架构与解析，其中UI界面、游戏对象、动画模块都将使用一个或多个XML文件来完成，通过XML的解析，最终将XML文件的内容输出到SceneA中。整个过程首先需要构建一个XML解析器，然后根据游戏的需要构建各种UI控件、游戏对象、动画等类。目前工程中用到的类包括：

UI控件：UIText、UIProgress、UITexture、UIList、UIClick、UICheckBox
游戏对象：GameObj、EffectObj、Bullet、Enemy
游戏动画：PosAnimation、ColorAnima-tion、FrameAnimation

每一个类中都有其所需要的成员变量，下面我们可以根据解析器的实现来使用XML文件布局游戏场景了。根据游戏的需要，可以将XML文件扩展到支持多级子节点，然后在游戏中获取XML中定义的元素，进行操作即可。同样需要将界面和程序进行分析，方便修改和维护。整个过程的完整流程如图4所示。

图4 XML布局流程

实际上我正在进行的项目除封装了上面所说的三个模块外，还将整个游戏架构都进行了封装，包括图2中所展示的控制器、主线程、模型，整个框架都能通过XML文件直接编写。到这里，你所铸造的宝剑也应该出世了，带上宝剑，冲向游戏世界吧。

作者： 杨丰盛，轻灵数码研发部经理，精通Java、C/C++等语言及J2ME、BREW、MTK、Android、iPhone等平台。曾领导和参与《三国群英传》、《大航海传奇》等游戏的开发。著有《Android应用开发揭秘》。

（本文来自《程序员》杂志11年01期，转自：http://www.programmer.com.cn/5223/）

您可能也喜欢：
Android与iOS在交互细节上的区别	Google+发布Android和iOS客户端	苹果iOS通知中心专利在韩国被三星控告侵权	为什么开发商更喜欢iOS而非Android	Card.io发布Android平台SDK
无觅

IT瘾游戏推荐

GDC：2026年游戏业界52%人士认为AI产生负面影响

更多阅读：

【独家专访】那位站上今晚苹果新品发布会舞台的华人，他的名字叫陈星汉

正在崩塌的手游渠道，手游正越来越像当年的端游？

野蛮的渠道，5/5分成起步

渠道霸权的原因：产品过剩、同质化严重、人口红利

霸权旁落，硬核并不是原因

市场垄断、发力官服，渠道的未来堪忧

App Annie：2015年移动游戏收入占移动应用市场总收入85%

为何说大数据精准广告并不靠谱？

所有游戏开发者都应该知道的一些参数

【译文】Top 10：HTML5、JavaScript 3D游戏引擎和框架

移动游戏流失用户预测

如何让玩家相信游戏是公平的

开源项目CodeCombat：玩游戏就能学会编程

摩托罗拉千元机Moto G实际使用速度竟然比Galaxy S4还快？！

Oculus Rift ：开拓虚拟现实新时代

Pixel light 中的场景管理

手游圈2012年终总结之91无线胡泽民：Android与iOS差距减小

JavaScript 游戏中的面向对象的设计

相关文章

10款超炫HTML5游戏 附游戏源码

1、HTML5版切水果游戏 HTML5游戏极品

2、HTML5中国象棋游戏 自定义象棋难度

3、奇葩版Flappy Bird,HTML5 Flappy Text游戏

4、HTML5五子棋游戏 画面超酷 可设置难度

5、HTML5跳伞游戏 看谁先安全降落地面

6、HTML5版Flappy Bird游戏 仅65行Javascript代码

7、HTML5吃豆人游戏PCMAN

8、HTML5太空战机游戏 有声有色

9、HTML5重力感应游戏 甩甩领导的头像

10、HTML5超级玛丽游戏重体验 HTML5游戏经典

聊聊用户访谈

技术宅打造全能美剧播放器

1:前言

2:添加yyets.com搜索引擎

3:修正标题bug

Patrick Wyatt：魔兽争霸的制作过程（1）

相关文章

游戏设计师的职责

实例分析赛车游戏的赛道设计原则

开发笔记(1)

两人的故事 – 值得玩味的小游戏 | 小众软件 > 游戏

相关文章

UberStrike HD – 画面精致 FPS [Mac] | 小众软件 > Mac

相关文章

列举独立开发者适用的数种游戏引擎

【可爱切切】超级理发师：Super Cuts

App简介:

App截图:

App下载地址:

F2P深度解析（5）：为什么越来越多的游戏转向F2P？

1）为什么F2P模式可行？

2）为什么很多基于订阅的MMO游戏转向F2P模式？F2P对他们的业务有什么样的影响？

3）F2P是一种长远方案，还是临时替补？

4）如何将F2P整合进MMO游戏？

社交游戏终极指南专题(3)：社交游戏的价值

【iPad益智】平衡物语两款：Perfect Balance & Imperfect Balance

App简介:

App截图:

App下载地址:

移动游戏的架构艺术

10款超炫HTML5游戏附游戏源码

2、HTML5中国象棋游戏自定义象棋难度

4、HTML5五子棋游戏画面超酷可设置难度

5、HTML5跳伞游戏看谁先安全降落地面

6、HTML5版Flappy Bird游戏仅65行Javascript代码

8、HTML5太空战机游戏有声有色

9、HTML5重力感应游戏甩甩领导的头像