看前几天的科技新闻，微信中的“跳一跳”小游戏从去年12月发布，截至到今年3月份已经积累了3.9亿玩家，这是一个多么恐怖的数字，“跳一跳”游戏带火了整个微信小游戏开发圈。微信小游戏是个什么东西呢？
微信小游戏是基于微信客户端的游戏，它即点即玩，无需下载安装，体验轻便，可以和微信内的好友一起玩，比如PK、围观等，享受小游戏带来的乐趣。微信小游戏不是一场，过去传统的重度手机游戏依然有其空间，微信小游戏既不需要下载安装包，又有合格的流畅性，是更适合休闲类游戏生长的土壤。
关于发展前景：未来的微信小游戏将是广告（高活跃）和虚拟道具（高收入）齐头并进的局面，在前期主要先做高活跃，等小游戏这个平台发展壮大，再发力高收入的游戏。
这张图说明微信小游戏的技术架构，通俗的说微信在自己Ａｐｐ里做了一个支持Ｈ５的浏览器内核（也可以叫一种容器），但是功能受到了一些。不支持 HTML 标签的解析、及 CSS 和 DOM 的解析。Ｈ５容器做的最主要事情，就是从操作系统的 Objective-C, Java, C++ API 上开始写起，里面实现自己的逻辑，然后架上安卓 v8、苹果 JavaScriptCore 等 JavaScript 虚拟机（JSVM），进而把这些操作系统 API 都绑定到 JavaScript 上。
从技术角度来说，微信小游戏是微信小程序的基础上添加了游戏库 API。小游戏只能运行在小程序中，所以小游戏既不是原生游戏，也不完全等同于 HTML5 游戏。但实际上小游戏面向的就是 HTML5 游戏开发者，为了能够让 HTML5 游戏可以尽可能低成本得移植，小游戏尽可能复用了 WebGL、JavaScript 等源自浏览器的 HTML5 技术。
可以说小游戏是使用 HTML5 技术搭建，具有原生体验的微信内游戏产品。小游戏保留了H5中游戏相关的技术，而在此基础上又追加了小程序部分特性能力。
微信中Ｈ５浏览器内核容器的方案和 HTML5 标准是两码事，但又有共通之处。比如小游戏封装出的 OpenGL JavaScript API，和 WebGL 是一模一样的，这就让游戏的移植工作量大幅降低。只是覆盖掉了这些差异性，让开发者「感觉」自己就是用普通的游戏引擎在开发一款 HTML5 游戏，确实也能在 Chrome 里面做调试。但如果你一旦使用了既超出引擎 API、又超出微信游戏容器 API，但是符合 HTML5 标准的代码，比个 CSS，来个 DOM，那么就无法运行在小游戏里面啦。
微信小游戏不是纯H5，可以理解为定制修改过的浏览器，把延伸功能、渲染、存储用JS脚本绑定上来，所以说小游戏实际运行在Runtime中，而开发中的调试主要是网页浏览器，它们的内存和性能不一样，所以要尽早跑在手机上，尽量潜在问题。
普通小程序的设计模式是“单向”绑定的模式，入口在app.js，通过定义各个页面，然后在页面中给回调事件定义逻辑代码实现数据呈现。
而“小游戏”更加，入口在game.js，没有page的概念，通过weapp-adapter.js引进canvas实例，无设计模式要求。
游戏引擎封装出的高层接口可以大大降低开发者的开发门槛，缩短项目周期。国内的三家主流引擎 Cocos Creator、Egret、Laya 均已支持微信小游戏开发。
微信小游戏还提供了丰富的微信内部 SDK 供开发者调用，使用这些接口可以完成用户登陆、转发、排行榜等常规的社交功能。
首先去申请微信小游戏账号，跟小程序申请的流程基本相同。为了顺利通过审核，请选择填写好游戏类别。
用微信开发工具创建一个小游戏项目，输入保存下来的AppId，最后，勾选“建立游戏快速启动模板”，点击确定，你就得到了你的第一个小游戏了。
点击工具上的编译按钮，可以在工具的左侧模拟器界面看到这个小游戏的表现。点击预览按钮，通过微信的扫一扫在手机上体验你的第一个小游戏。
小游戏开发者通过在根目录编写一个 game.json 文件进行配置，开发者工具和客户端需要读取这个配置，完成相关界面渲染和属性设置。
这些使用 wx API 模拟 BOM 和 DOM 的代码组成的库称之为 Adapter。顾名思义，这是对基于浏览器的游戏引擎在小游戏运行下的一层适配层，使游戏引擎在调用 DOM API 和访问 DOM 属性时不会产生错误。Adapter 是一个抽象的代码层，并不特指某一个适配小游戏的第三方库，每位开发者都可以根据自己的项目需要实现相应的 Adapter。实现了一个 Adapter 名为 weapp-adapter， 并提供了完整的源码，供开发者使用和参考。
main文件和databus文件，main.js里有程序的主函数，包括游戏开始、敌人产生、游戏侦循环、图像绘制、碰撞检测等。游戏结束后重新开始的按钮及事件处理也在这个文件中。
databus是个全局状态管理器，可以回收敌人，回收子弹，被回收的内容，不会进行侦循环，就不会绘制到屏幕上。
ｎｐｃ目录下：是敌机类，从类Animation继承而来，有属性可以设置敌机飞行速度、敌机图像、预订的敌机被击中时爆炸的动画。
ｐｌａｙｅｒ目录下有两个类：玩家战机，和子弹类。都是从Sprite类继承而来。其中玩家战机中有手制战机的事件处理。子弹类中有子弹速度参数，及子弹超出屏幕回收的处理逻辑，当然这两个类都有绘制图像的资源定义。
ｂａｓｅ目录下有对象池类，游戏基础的精灵Sprite类，和从精灵类继承而来的简易的帧动画类Animation。
ｐｏｏｌ类用于对象回收，Sprite类中声明的宽度、高度、坐标、图像，调用适配器中ｃａｖａｎｓ绘制图像（战机）。还有简单的精灵碰撞（中心点碰撞）的定义。
weapp-adapter 不是小游戏基础库的一部分，今后也将不再对 weapp-adapter 进行更新和。开发者应该根据自己使用的游戏引擎，实现自己的 Adapter 来使所用的游戏引擎适配小游戏的运行。
把敌机改成足球，可以使用各种不同类型的足球图片。生成足球的逻辑也修改，不同类型的足球生成的概率不同。珍惜级别的足球，降低概率。不同的足球，设置不同的权重，击落后励的分数不同，修改计分逻辑。
根据 12 月初伽马数据的行业报告，国内 2017 年手机原生游戏 1162 亿，PC 端游 648 亿，PC 页游 156 亿，所以按比例简单计算的话，梦见吃面条手机页游的市场空间 = 1162 ÷ 648 x 156 = 每年 280 亿人民币。
如果进一步考虑 Flash 宣布 2020 年停更，市面大量 PC 页游都开始转用 HTML5 技术制作，而手机原生上也出现了大量的微端产品，那么如果不考虑此消彼长的制约， HTML5 技术可以支撑的游戏市场规模应该 = 280 亿 手机页游 + 156 亿 PC 页游 + 部分手机原生游戏 ≈ 每年 500 亿人民币。
500 亿人民币还只是计算国内的规模。根据国外 Newzoo 在年中的数据，中国游戏产业规模占全球 25%，那么 HTML5 技术理论上可以支撑的全球手机页游、手机原生、PC 页游市场容量上限可达每年 2000 亿人民币。
本文由来源于财鼎国际(www.hengpunai.cn)