“高山速降”到“月入千万”:H5游戏春天来了？|H5游戏|游戏开发|开发者_新浪科技_新浪网
“高山速降”到“月入千万”:H5游戏春天来了？
　　摘要：如果H5游戏行业仍然充斥着大量个人开发者制作的小成本、小制作的轻度化产品，行业依然会遭遇与2015年相似的情况，仅一款千万级爆款游戏的带动作用有限。
　　前天，一款HTML5游戏宣布月流水突破了1500万，业内首款千万级别的H5游戏终于出现。这款游戏开发公司的创始人是前总裁。
　　一款月流水超过1500万的H5游戏意味着什么？
　　它好比一针兴奋剂，意味着曾被看衰的H5游戏的变现能力由此正名；也意味着资本市场需要修正之前对H5游戏行业“目前不具备盈利能力”的整体判断。白鹭时代CEO陈书艺等游戏界的大佬都曾提过，月流水千万是一个门槛，H5游戏只有突破了这个门槛才能赢得大资本、大团队的持续投入。
　　H5游戏行业在经历了2015年的高开低走之后，一款“月入千万”的产品让业界重拾对H5游戏的信心。
　　2015年开年时，在原生游戏用户红利结束，进入稳定期的大背景下，业内普遍认为H5游戏存在着移动端唯一可能的用户红利，并预测H5游戏行业在2015将迎来大爆发。事情最初也像大家预测那样，《围住神经猫》等H5游戏刷爆朋友圈。
　　但随着《神经猫》大火之后微信对H5游戏的流量管制，以及受制于留存率和流量变现能力的不足，进入2015下半年，H5游戏生存状态急转直下。甚至有人直言H5游戏现阶段存在硬伤，未盼来春天，已进入寒冬。同时，国内资本市场大环境趋冷，更让H5游戏业内的创业团队倍感煎熬。
　　H5游戏行业经历了从2015年的“高山速降”到2016“月入千万”的突破，是否意味着H5游戏的春天终于来了呢？二爷认为H5游戏行业目前仍有“三座大山”需要突破，1500万更应该是一针镇定剂。
　　运营能力缺失，指望不上的“天才操盘手”
　　整个2015年，H5游戏始终在“高传播、高流量、低留存、低转化、低ARPPU”的圈子里打转，对H5游戏厂商来说，这“三低”痛点疼得厉害。
　　H5游戏最大的优势在于其天然的具备社交传播特性，一个URL即可分享，在社交软件内的传播大幅降低了用户的获取成本。目前看来，H5游戏最大的阵地仍是微信，朋友圈给H5游戏带来了高PV。但流量来了，游戏厂商却抓不住，留存难，转化更难，朋友圈里绝大多数的H5游戏都是一闪而过，短时刷屏，迅速衰落。
　　作为一款游戏，产品好固然重要，但运营能力更为关键。这款H5游戏之所以能够成为首款千万级别的H5游戏，与其创始人凌海在盛大时期的经验密不可分。10年的盛大生涯让凌海很清楚地知道如何去运营好一款游戏，无论这款游戏的载体是PC、手机还是H5。这样的经验并不是人人都可以具备的，特别是对创业团队来说。二爷曾采访一位世界500强的大中华区总裁，他评判人才的一条重要标准便是“他是否具有成功经验”。
　　对整个H5游戏行业来说，整体运营能力的提高，决定着行业是否能够走出2015的怪圈。H5游戏行业的主体仍是创业团队，期望所有的创业团队能够在短时间将运营能力提高到另一个层次，并不现实。
　　所以，要“点燃”H5游戏行业需要更多成熟的大公司的进入，不仅是现金和技术的进入，更是运营能力的进入。创业团队在运营能力方面的修炼、学习和成长需要更快，除非出现“天才操盘手”，但这真的指望不上。
　　短命的轻度H5游戏泛滥，优秀的重度化产品寥寥无几
　　截止2015年底，HTML5游戏数量超过3000款，在已上线的H5游戏中，制作简单、易于传播的休闲益智类小游戏占比达到75.10%，其次是角色扮演类、动作冒险类游戏，占比分别为9.22%和6.04%。
　　在2015年，大批开发成本较低，轻度化的H5游戏“霜化”在朋友圈，成为先烈。同为H5游戏，该款千万级游戏强大的IP自然功不可没，但同样重要的是它作为一款H5游戏，重度化色彩极重。凌海坦言“我的标准比别人高。”
　　目前，轻度休闲H5游戏开发成本较少，1个开发者在几天时间内独立完成，成本是几万元。中度及重度产品的开发费用和周期则可比拟原生APP，《貂蝉有妖气》开发成本约100万元，周期4个月；《时尚都市》开发周期75天，上线后持续开发及迭代共10个月，总体成本约200万；《传奇世界》开发成本100万，周期为3个月。
　　虽然H5游戏的研发成本与原生手游仍无法相提并论，但出于产品生命周期的考虑，厂商已经开始向H5游戏重度化方向倾斜。在2015年各季度CP新创建的HTML5游戏中，益智休闲类游戏占比分别为82.1%、78.2%、70.3%和72.08%，呈现明显的下降趋势；而角色扮演类游戏在Q3实现爆发，占比从6.8%提升到14.0%；在玩法上，出于游戏变现的需求，CP开始注重研发玩法偏重化的HTML5游戏，探索HTML5游戏道具收费的模式。
　　二爷认为，2016年，如果H5游戏行业仍然充斥着大量个人开发者制作的小成本、小制作的轻度化产品，行业依然会遭遇与2015年相似的情况，仅一款千万级爆款游戏的带动作用有限。
　　支付不做好，就像淘宝没有
　　目前，低ARPU、高DAU，病毒式传播的休闲类HTML5游戏都是依靠社交工具实现，用户粘性不足、付费意愿偏弱、游戏生命周期较短，且二次入口导致CP吸量减弱，市场定位仍是“市场部门的营销工具”。
　　尽管，H5游戏用户规模已达1.75亿人，同比增长率达到112%，且H5游戏的流量入口已呈现多元化趋势，包括在内的流量聚集平台都开始尝试布局H5游戏中心，但通过H5游戏实现流量变现的路径仍然不清晰。付费方式依然是通过经营流量广告变现，整体付费率依旧处于较低的水平。虽然游戏内付费点产生收入也有望成为H5游戏的主流盈利模式，但有能力以IAP（游戏内支付）的方式通过出售游戏内计费点收费，并有一定流水的H5游戏产品，屈指可数。
　　二爷认为，在行业整体付费率较低的情况下，脱离开支付环节去谈商业模式几乎是扯淡。目前的H5游戏行业的情况类似于2005年支付宝出现之前的B2C电商行业，支付环节存在的问题较多。
　　H5游戏的支付主要分为APP支付接口与WEB支付接口两种，相对而言，APP支付接口的响应速度较WEB支付接口更快，APP的支付渠道数量也比WEB支付渠道更多。H5游戏厂商在加强对提升玩家群付费水平的研究之外，还要关注如何让用户更加愉快的付费，优化付费环节的体验。
　　试想的成功有多大程度得益于开发出支付宝？当然，现在的技术水平和当年早已不可同日而语，支付工具和技术手段已相对成熟，H5游戏厂商自然不必再造一个支付宝，大家需要思考的应当是如何更好地利用它们。
　　这款千万级H5游戏的缔造者凌海表示“今年很可能会有过亿的手机页游。因为我看到自己还有很多做得不足的地方，如果可以有效解决，收入绝对可以翻番。”
　　凌海当然有理由意气风发，我们也有理由相信他的判断，但在这个喜庆的时刻，二爷觉得，对于H5游戏行业的春天，我们的期待还需要再冷静一些。
毫不夸张地说，自电脑几近毁掉一代人的文字书写能力之后，新媒体...
对品牌商来说，目标是盈利，而不是为人类的电商事业当小白鼠。对...
单从牌面来看，缺少了《龙之谷》背书的《精灵王座》未必就会一落...
传Alphabet、Facebook和微软等计划提交一份联合动议，支持苹果上诉FBI。
在伊比利亚半岛的明珠之上，一年一度的MWC世界移动通讯大会又发生了些什么？勇者后裔h5初始英雄白魔导士属性特色如何，游戏里的战斗，需要勇者的参与，更需要一路上收集不同属性的英雄，逐步组...
100W金币、麻痹碎片*2、主宰碎
主宰碎片*10、羽毛*20、强化石
元宝*100，随机天书*20，兽魂丹
搜魂令*3、黄金鞭*10、80000银子
升星石*100、宝石碎片*100、九
恭喜您，领取成功！请您在3小时内激活，此后卡号将会进入淘号区被其他网友查看。
你今天领取的卡号为：
网游排行榜
999.5万人玩
999.4万人玩
998.8万人玩
998.6万人玩
996.4万人玩
989.2万人玩
988.4万人玩
988.4万人玩
984.1万人玩
983.2万人玩
单机排行榜
998.8万人玩
998.6万人玩
989.4万人玩
988.6万人玩
987.5万人玩
986.7万人玩
978.7万人玩
966.7万人玩
955.3万人玩
918.4万人玩
新游排行榜
999.5万人玩
999.4万人玩
998.8万人玩
998.8万人玩
998.6万人玩
998.6万人玩
996.4万人玩
989.4万人玩
989.2万人玩
988.6万人玩
||||||||||||||||||　　自神经猫风波之后，微信中的各种小游戏如雨后春笋般目不暇接，这种低成本，高效传播的案例很是受开发者青睐。作为一名前端，随手写个这样的小游戏出来应该算是必备技能吧。恰逢中秋节，部门决定上线一个小游戏，在微信里传播一下与用户互动互动。这任务自然落在了我头上。前段时间用DOM+CSS3写了个小游戏，在Android机器上巨卡无比，有了上次的经验，这次决定用canvas来写。其实这些小游戏在业界也都是canvas来做，已经有很成熟的技术和框架，由于不会频繁修改DOM树，所有的动画都是在一块画布上完成，所以在手机上的效果比DOM要优秀很多。
　　楼主本人用canvas做游戏的经验为0，只在大学的时候鼓捣过一次，知识全部忘却了。这次也是边学边做，鉴于游戏逻辑比较简单，鼓捣了一天，终于搞出一个能玩的了。在此把实现原理记录一下。也给像我这样的初上手的一些参考资料。
　　先来说说这个游戏，名字叫玉兔吃月饼，很有中秋的氛围哈~玩法非常简单，用手指触控屏幕来控制一只开着飞碟的兔子移动，天上会不停掉月饼，有好月饼和坏月饼之分，吃到好月饼就得分，吃到坏月饼就挂掉。主要逻辑就这么简单。看一下游戏的截图：
　　，点击试玩。
　　下面就把整个游戏的实现细节来说一下，其实整体来看还是没有什么难度的。
游戏舞台的尺寸
& & &先从最基本的来说起。游戏的舞台就是我们的canvas元素，这个元素的尺寸应该如何设置呢？既然要适配各种手机屏幕，那我在css中给它宽高都设为100%不就可以喽。其实这个朴素的想法是错误的，canvas元素的使用与普通的html元素并不相同，它有一个默认尺寸300*150，在css中设置宽高只能改变canvas的显示宽高，而并没有改变画布绘制时的尺寸，所以要为canvas设置绘制的尺寸，必须写在元素标签上。例如，我的canvas元素是这样的：
&div id="gamepanel"&
&canvas id="stage" width="320" height="568"&&/canvas&
　　这里你可能要问了，为什么尺寸是320*568呢？这里有必要说一下，我们在做手机端页面时，给iPhone的容器宽度是320px，给Android的容器宽度是360px，这里想要兼容两者，所以只能取最小的320了，否则iPhone出现滚动条是很蛋疼的。至于安卓设备，我们只能委屈它一下了，给一个较窄的宽度，然后让整个容器居中对齐，游戏容器的样式如下：
#gamepanel{
width: 320px;
margin: 0 auto;
height: 568px;
position: relative;
overflow: hidden;
　　宽度整好了，那height值为568又是什么原因呢？其实我也没有研究过，只是看到别人代码里这么写，就抄过来了。
& & &就在楼主写这篇文章的时候，看到了cocos2d-js生成的canvas是这样的规则：
& & &Android设备：360*640
& & &iphone5：320*568
& & &iphone4：320*480
& & &所以以后在不用框架的时候，可以用js判断来确定canvas的尺寸，这里算是学到的一点小知识。
滚动的背景
& & &我们有一张天空的图片来做背景，并且要不停向下移动，这样感觉飞碟在不停的向前飞行。如何让背景图片连续不间断的移动呢？
& & &首先定义了一个全局对象gameMonitor，游戏控制需要用到的参数、方法，都定义为它的属性，用来组织游戏的整体逻辑。其中，滚动背景的函数rollBg定义如下：
rollBg : function(ctx){
if(this.bgDistance&=this.bgHeight){
this.bgloop = 0;
this.bgDistance = ++this.bgloop * this.bgS
ctx.drawImage(this.bg, 0, this.bgDistance-this.bgHeight, this.bgWidth, this.bgHeight);
ctx.drawImage(this.bg, 0, this.bgDistance, this.bgWidth, this.bgHeight);
　　有两个变量bgloop和bgDistance分别记录背景的重绘次数和移动了的距离，每次重绘让bgloop自增，乘以速度就是新的距离。为了实现背景图片的无缝滚动，我们需要调用两次drawImage来绘制两张图片上去，绘制的位置关系如下图所示：
　　这样才能保证背景滚动的过程中不会闪烁也不会中断。
简易的图片加载器
& & &由于游戏一开始并没有把所有的图片都加载下来，所以后续要用到的图片，比如飞碟、兔子都是需要延迟加载进来的，所以需要实现一个图片加载器，大体的功能就是让浏览器加载图片，然后在别的代码中调用可以直接使用图片，代码如下：
function ImageMonitor(){
var imgArray = [];
createImage : function(src){
return typeof imgArray[src] != 'undefined' ? imgArray[src] : (imgArray[src] = new Image(), imgArray[src].src = src, imgArray[src])
loadImage : function(arr, callback){
for(var i=0,l=arr. i&l; i++){
var img = arr[i];
imgArray[img] = new Image();
imgArray[img].onload = function(){
if(i==l-1 && typeof callback=='function'){
callback();
imgArray[img].src = img
　　返回的对象有两个方法，第一个createImage，返回当前数组中对应的图片，如果不存在该图片，则new一个来返回。第二个loadImage接收一个数组和一个回调函数，把数组中的图片路径逐一加载，保存到一个数组中，最后一张图片加载完后执行一个回调函数。
& & &这段代码其实是我从别人代码中偷来的，稍一推敲，就会发现这段代码其实是有问题的：
& & &1. createImage方法，在当前imgArray数组中有所需图片时是没问题的，但是如果没有就需要现加载，在别的地方如果调用了这个方法，那么后面的代码应该是放在img的onload函数中执行才对，否则一旦网络较慢，这个时候可能图片还未加载下来，后续代码会报错。
& & &2. loadImage方法，回调函数的执行是在最后一张图片的onload函数中执行，这也是有可能出问题的，因为浏览器是可以并发请求的，有可能最后一张图片已经加载完了，前面的图片还没加载完（最后一张图片较小，前面的较大，或者是网络的原因），这个时候执行回调的时机也是不准确的。
& & &开发的时候因为时间紧急我没有改良这段代码，只是避开了可能出问题的用法。那么标准的加载图片，或者说资源管理应该是如何进行呢？我相信业界已经有了标准答案，后续我会搞清楚这个问题。以后写游戏就用框架（像cocos2d-js）来管理这些了，原生的要顾及的东西实在是多。
实现飞船的绘制、操控
& & &接下来就开始实现游戏的主体，飞船。用js面向对象的写法（大家都这么叫，姑且这么叫吧），我们编写一个Ship类，属性有宽高、坐标、游戏图片，有一个paint方法来把自己绘制出来，还有一个controll方法来响应用户的操作，代码如下：
function Ship(ctx){
gameMonitor.im.loadImage(['static/img/player.png']);
this.width = 80;
this.height = 80;
this.left = gameMonitor.w/2 - this.width/2;
this.top = gameMonitor.h - 2*this.
this.player = gameMonitor.im.createImage('static/img/player.png');
this.paint = function(){
ctx.drawImage(this.player, this.left, this.top, this.width, this.height);
this.setPosition = function(event){
this.left = event.changedTouches[0].clientX - this.width/2 - 16;
this.top = event.changedTouches[0].clientY - this.height/2;
if(this.left&0){
this.left = 0;
if(this.left&320-this.width){
this.left = 320-this.
if(this.top&0){
this.top = 0;
if(this.top&gameMonitor.h - this.height){
this.top = gameMonitor.h - this.
this.paint();
this.controll = function(){
var _this = this;
var stage = $('#gamepanel');
var currentX = this.left,
currentY = this.top,
move = false;
stage.on('touchstart', function(event){
_this.setPosition(event);
move = true;
}).on('touchend', function(){
move = false;
}).on('touchmove', function(event){
event.preventDefault();
_this.setPosition(event);
　　代码是一目了然的，paint方法是基础，setPosition其实就是修改飞船的left和top值，并防止移出屏幕，每次移动完后调用paint方法来重现绘制飞船。controll方法则是监听了touch事件，计算得出新的位置。
实现月饼的绘制、移动
& & &实现了Ship类，接下来该实现月饼了，我们定义为Food类。与Ship类有些不同，Food的示例会有很多个，因为天上在不停掉月饼嘛，而且月饼有好坏之分，所以Food类多了两属性：id和type，用来标识月饼和它的类型。另外，由于Food类会new很多实例出来，所以方法我们定义在prototype上，这样减少每次创建实例时的内存消耗。代码如下：
function Food(type, left, id){
this.speedUpTime = 300;
this.type =
this.width = 50;
this.height = 50;
this.left =
this.top = -50;
this.speed = 0.04 * Math.pow(1.2, Math.floor(gameMonitor.time/this.speedUpTime));
this.loop = 0;
var p = this.type == 0 ? 'static/img/food1.png' : 'static/img/food2.png';
this.pic = gameMonitor.im.createImage(p);
Food.prototype.paint = function(ctx){
ctx.drawImage(this.pic, this.left, this.top, this.width, this.height);
Food.prototype.move = function(ctx){
if(gameMonitor.time % this.speedUpTime == 0){
this.speed *= 1.2;
this.top += ++this.loop * this.
if(this.top&gameMonitor.h){
gameMonitor.foodList[this.id] = null;
this.paint(ctx);
　　另外还有一点要说的是，月饼的速度是在不断增加的，以此来控制游戏的难道逐渐增高。定义一个speedUpTime&作为加速的时间间隔，默认为300，游戏的帧率为60，所以每隔5秒就会进行一次加速。新创建的月饼实例在初始化的时候，它的速度要和当前屏幕上的月饼速度一致，所以这个speed是动态的，有一个计算公式。
随机产生月饼
& & &有了Food类后，只要我们调用new Food(type, left ,id)，就会创建出一个月饼。接下来，我们需要在屏幕上以一定的频率随机产生月饼。在gameMonitor中定义一个genorateFood方法，让它来管理月饼的生成，代码如下：
genorateFood : function(){
var genRate = 50; //产生月饼的频率
var random = Math.random();
if(random*genRate&genRate-1){
var left = Math.random()*(this.w - 50);
var type = Math.floor(left)%2 == 0 ? 0 : 1;
var id = this.foodList.
var f = new Food(type, left, id);
this.foodList.push(f);
月饼产生频率genRage默认为50，即不到1秒的时间产生一个月饼，根据实际测试，这个值比较合适。然后把new出来的月饼实例push到gameMonitor的FoodList数组中。FoodList中保存着当前屏幕上的所有月饼，这样，我们每次重绘canvas的时候，只要把foodList中的月饼挨个绘制出来就OK了，同样的道理，当有月饼移出屏幕，或者是被吃掉时，把它从FoodList中删除就OK了。
兔子吃月饼
& & &兔子有了，月饼有了，接下来就该吃了。我们给Ship类添加一个eat方法，表示吃月饼。所谓吃月饼说白了还是做碰撞检测，每次帧刷新的时候，让飞碟与界面上所有的月饼做一次碰撞检测，如果发生了碰撞，判断月饼的类型，好月饼则得分加一，坏月饼则游戏结束。因为飞碟和月饼都是近似圆形，所以按照圆形模型来做碰撞检测就再简单不过了，两圆心的距离小于半径之和，则认为发生了碰撞。Ship的eat方法定义如下：
this.eat = function(foodlist){
for(var i=foodlist.length-1; i&=0; i--){
var f = foodlist[i];
var l1 = this.top+this.height/2 - (f.top+f.height/2);
var l2 = this.left+this.width/2 - (f.left+f.width/2);
var l3 = Math.sqrt(l1*l1 + l2*l2);
if(l3&=this.height/2 + f.height/2){
foodlist[f.id] = null;
if(f.type==0){
gameMonitor.stop();
$('#gameoverPanel').show();
setTimeout(function(){
$('#gameoverPanel').hide();
$('#resultPanel').show();
gameMonitor.getScore();
$('#score').text(++gameMonitor.score);
$('.heart').removeClass('hearthot').addClass('hearthot');
setTimeout(function() {
$('.heart').removeClass('hearthot')
调用的时候，我们把gameMonitor维护的foodList数组传进来即可。同时要注意，当一个月饼被吃掉后，要从该数组中移除，这样下一帧就不会把它绘制出来了。
让游戏run起来
& & &我们该定义的东西也都差不多了，接下来是让游戏跑起来的时候了！所谓的跑起来，就是让canvas不停的重绘而已，在gameMonitor上定义一个方法run，通过setTimeout来递归调用它，延时时间为1000/60，这样可以维持帧率在60。run方法定义如下：
run : function(ctx){
var _this = gameM
ctx.clearRect(0, 0, _this.bgWidth, _this.bgHeight);
_this.rollBg(ctx);
//绘制飞船
_this.ship.paint();
_this.ship.eat(_this.foodList);
//产生月饼
_this.genorateFood();
//绘制月饼
for(i=_this.foodList.length-1; i&=0; i--){
var f = _this.foodList[i];
f.paint(ctx);
f.move(ctx);
_this.timmer = setTimeout(function(){
gameMonitor.run(ctx);
}, Math.round(1000/60));
_this.time++;
首先我们会执行一次canvas的clearRect方法来把画布清空一下，否则画面会重叠上去。之后绘制背景、飞船、月饼。调用相关的动画方法后，整个游戏就动起来了~
& & &其实在这里我开发的时候遇到了一个纠结的地方，那就是用setTimeout来控制帧刷新，在上篇文章中，我有介绍用requestAnimationFrame也是可以控制帧刷新的，写这个小游戏的时候我一开始也是用了这个方法，但是在测试的时候遇到了一个现象，在iphone4上，当用手指控制飞船移动的时候，帧率就有明显的下降，我不清楚是什么原因造成，后来看别人代码中是setTimeout的，就抄了过来解决问题。所以在此我也抛出一个问题：setTimeout与requestAnimationFrame到底该选择哪个，是否与canvas有关，有大牛知道也望请指点。
& & &通过以上几个步骤，游戏的基本功能就完成了，其他一些游戏流程控制，包括开始、结束、得分计算等在此就不叙述了。总体感觉用canvas做一个小游戏的难度也不算大，不过我写的这个游戏也确实特别简单，可以作为入门的例子。
& & &这次当做多原生canvas的一次学习，以后做游戏的话，我也不打算用原生canvas了，准备学习下cocos2d-js，最近也发布了其正式版本，正是上手的最佳时间。
& & &本游戏的源代码扔在了github上：
　　本文仓促完成，有些观点和写法可能不正确，如有问题，欢迎留言指导~
阅读(...) 评论()You are here:
H5行业疯狂 腾讯回应:H5手游还在做试验
【Gamelook专稿，转载请注明出处】
Gamelook报道/最近这几天，包括gamelook在内的多家游戏媒体追踪报道腾讯H5手游业务的新动向，引发整个游戏圈的沸腾，在这几轮报道中，不仅有媒体披露了腾讯微信将启动H5手游接入，亦有业内人士向gamelook爆料称腾讯明年H5手游的KPI是50亿元。
做H5的兄弟走到这天真不容易…
消息传来，喜大普奔，对苦逼多年的H5手游创业者来说，腾讯正式入局毫无疑问解了很多人的燃眉之急，终于画了多年的饼能吃到了，终于为创业当年卖掉的房有机会再买回来了！…
在gamelook前日发出腾讯H5报道之后，看到行业的沸腾状、腾讯再也坐不住了，腾讯公司相关人士直接联系到了gamelook，对近期业内对腾讯公司H5业务的若干猜想做了澄清和确认。
腾讯H5手游的事实情况是怎样的呢？喜忧参半。
先说好消息。
首先被腾讯公司确认的是腾讯确实要做H5手游业务，目前具体负责H5手游引进工作的是IEG（腾讯互娱）。
而提供给H5游戏流量的确实是如传闻所称的手Q、微信两大平台，发行套路将与目前腾讯精品独代游戏的模式完全一致。
再说坏消息。
H5手游业务推进速度可能会比业内人士预期的要慢。
腾讯对gamelook表示，“目前H5手游业务仍处于各项框架论证搭建阶段，并没有确定测试产品和开测时间，更不会在短期内开始大规模推广。”
因此间接否认了年内微信、手Q在H5手游上有大动作的可能，但gamelook认为不排除会有H5产品先试跑、来评估这项业务未来的可行性。
其次，腾讯直接否认H5手游明年50亿元KPI的传闻：“腾讯将逐步展开H5游戏的发行推广尝试。由于是尝试性质，所以并没有为这项业务设置任何KPI。”
就上述腾讯方的正式回应，gamelook简单分析下腾讯的潜台词：
1）精品独代成为H5手游合作的前提，不是开放接入
根据过往微信、手Q合作产品的规则来看，腾讯会要求独家代理，且对游戏产品的素质提出了很高的要求，而腾讯此次确认了H5手游合作依然继承独代模式，这意味着要进入腾讯H5手游的体系，必须拿出过硬的产品、要超过行业平均水平，仅这一条，已把众多开发者堵在路上。IP、美术质量、整体品质、玩法、数据，甚至资本关系是否是自己人，行业都懂。
2）流量方为微信、手Q被确认，高流量导入意味着高收入
此次腾讯方的合作中，并没有提到应用宝H5手游合作，但明确了H5手游运营的流量平台为微信和手Q，这是一件很让行业高兴的事，微信、手Q是目前腾讯活跃用户量最高的两款产品，强势流量的导入意味着一旦H5手游变现收入将不是小数。
3）未定KPI？信不信由你
真的没有KPI么？也许腾讯内部没有明确这个数字，但gamelook相信负责这项业务的腾讯领导、团队心中必然有一杆秤，这个数字究竟是能达到乐观的50亿、还是比50亿少？我们简单分析一下。
H5领域几个游戏公司此前自己喊的口号叫突破年10亿盘子，如果沿用这些业内CP公司的预想套到腾讯头上，10亿是多了还是少了？gamelook可以说肯定是算少了！
目前国内几款规模变现H5手游产品的总流水相加已超过了5000万单月，因此即使没有腾讯介入H5，以这些公司的努力2017年H5全行业实现10亿收入是非常有把握的。
那么腾讯介入呢？在gamelook看来，10亿对腾讯是个小数，这个体量只等于腾讯做一款成功的原生手游的业绩，对腾讯来说代理一款游戏就可实现的目标又有何必要折腾出一套新体系、甚至动用微信手Q的资源来伺候H5？显然有些大材小用之嫌，因此gamelook认为这个潜在的真实KPI应该底线在20-30亿元，只是什么时候腾讯发力H5就不好说了。
虽然今日腾讯对H5手游近期的狂热状态泼了一瓢冷水，但腾讯亦明确了将注入优质流量资源对H5手游市场进行投入，这就是H5市场最大的进步。
从PC时代HTML5游戏就一直陷入炒作、寒冬、炒作、寒冬的怪圈，步入移动互联网，对裸奔这么多年的H5游戏，在gamelook看来事实上只剩下好消息已经没有坏消息了。
人都要有梦想，没准实现了呢？H5，加油！
& 2017 . All rights reserved.