微信小程序能做游戏了~
现在只要更新到6.6.1版本的微信，开场就会出现一个游戏。你也可以到发现-游戏里找其他所有的小游戏
这应该是小程序有史以来最大的一次更新，还记得1月10日发布时，小程序是明确说明暂不支持开发游戏的，短短数月，态度却发生了180度转弯。
可能有同学还来不及反应，心里就疑问：为何这么善变？
谁说不是呢？但是做互联网技术，特别是做前端开发的同学都知道，技术一年一年变，从2010年进腾讯到现在以来，花叔颇有感触，前端技术的持续演变以及人力模型的多向发展，时时刻刻都提醒着花叔，时下还处于“技术驱动产品”的年代，随着技术复杂度以及创新度的变化，产品的形态也随之发生一连串的革新。更何况那是生来就带着“技术”和“产品”特质的腾讯。
所以，只要是正向，能为行业带来活力，谁在乎变还是不变。
再说，“小游戏”可不是一时半刻就做得出来的东西，也许就在小程序发布后不久，又或者是小程序发布前，“小游戏”可能就在策划中，为何这么说？因为“小游戏”虽然依赖于小程序的账号体系，但从技术层面来看，这完完全全是一套全新的、庞大的、完整的以及独立的开发体系。
接下来花叔要给大家说说它到底是什么？我们来解决2个问题吧。
一.“小游戏”跟公众号、小程序什么关系？
众所周知，小程序跟公众号可以算是“兄弟关系”，也有人说小程序就是公众号的补充，花叔不大认同。公众号是以内容为主，小程序则是以服务为主的，“服务”与“内容”的关系，花叔总觉得不应该是“补充”关系吧？暂且把“小程序”和“公众号”的关系定义成“对等”的，按这逻辑也就是说，公众号能做的，小程序应该也能做才对，只不过做的东西内容是一样但形态不大一样。
那么问题来了，基于公众号能做游戏么？
可以，其实基于公众号能实现一些h5游戏，这些h5游戏能具备普通h5没法实现的功能，如微信支付、用户信息获取等功能。
于是小程序支持做游戏，好像也不是特别难理解（哈哈，花叔强行把逻辑拉到一个线上）。“小游戏”是小程序的子分支，现在可以暂且把小程序归类为：
普通小程序
小游戏
具体来说，小游戏就是小程序里的一个类目，只不过这个类目有点特别，一旦被定义后，后面就没法改了，而且这个类目会让这个小程序号具备了游戏的标识，也让这个小程序号的开发模式锁定在游戏开发的解决方案中。
理清这些关系后，咱们从技术层面看看它是个什么货。
二.“小游戏”是什么技术？
说这个前，我们还是复习一个功课。
现在市面看到的H5游戏有很多，微信也有专门发展h5游戏，如：
大家应该知道那是基于通用html5技术的游戏，html5技术是基于浏览器统一标准的网页技术，是一种通用技术，提供了游戏以及非游戏应用所能用到的所有技术。
那么问题又来了，我做个游戏，给我提供那么多附带技术干嘛，是不是有点“杀鸡焉用牛刀”的感觉？而且这些附带的技术还可能会带来一些不必要的消耗。
做h5游戏，技术上应该要做“减法”。
“小游戏”保留了H5中游戏相关的技术，而在此基础上又追加了小程序部分特性能力。这样出来的游戏，技术更专注、特点更微信。
把游戏相关的技术揪出来，加上微信原来的功能特性接口，这样会使得运行效率更高、更精简而又能让微信为其赋予创造力，从用户层面看，游戏会更流畅，提供的功能服务会更强大。
从产品角度看，“小游戏”是不是在建立统一的H5游戏生态圈又或者其他目的，花叔不是产品经理也没法评论，但微信产品同学的规划能力相当厉害，这是毋庸置疑的，小游戏的产品形态一定是经过仔细雕琢，这里就不分析了。
技术选型角度看，花叔觉得，除了“难以跨平台”这个缺点外，也没什么坏处，总结一下“小游戏”的技术点：
难以跨平台
基于小程序的账号体系，与小程序一样，小游戏只能运行于微信中，难以跨平台。
与普通小程序设计模式不一样
普通小程序的设计模式是“单向”绑定的模式，入口在app.js，通过定义各个页面，然后在页面中给回调事件定义逻辑代码实现数据呈现。
而“小游戏”更加自由，入口在game.js，没有page的概念，通过weapp-adapter.js引进canvas实例，无设计模式要求。
基于普通H5游戏技术，更多的是Canvas技术，同时提供原生能力API。
现有游戏框架，如createjs、threejs等2d或者3d框架，经过小改就能直接应用于小程序的“小游戏”中（不知道国庆前花叔推荐过大家去研究canvas，大家研究了没。）
同样，小游戏也会如普通小程序一样支持部分原生功能。
应该暂不对个人开发者开放（>_
跟普通小程序一样，小游戏暂不对个人开发者开放。
最后大家发现没，第一批小游戏中大多具备展示关系链数据的功能块，未来会不会开放这块数据呢？嘿嘿嘿~
综合上述，这种“技术形态的拆减和组装”本身就是一种创新，而往往技术的创新会带来深远影响。
想必这又会掀起一波热浪。
您准备好了么？
