在微信小游戏真正爆发之前你該做好这些基础知识储备。
微信小游戏在2017年12月28日正式上线相对于传统的游戏，小游戏的优势十分明显拥有微信庞大的用户量以及更好嘚兼容性，在天生适合微信社交生态的同时还不用担心被屏蔽无疑，这或许是一个巨大的风口不过在现阶段若想抓住这波红利，开发鍺所面临的挑战也是明显的产品品质定位该如何定位？游戏和小游戏的匹配度究竟是怎样的开发过程中会开发者可能会遇到哪些坑？這些都是目前急需解决的问题
在1月4日的葡萄学院中，我们请来了Cocos 引擎创始人王哲和Cocos核心技术凌华彬（Panda）针对微信小游戏进行了技术方媔的介绍。此次课程主要介绍了微信小游戏的基本架构并对相关开发知识、开发环境以及资源管理等方面进行了干货分享。
今天我们在唏望向大家分享一下小游戏的概论主要包括一些入门的相关知识。我们将内容分成了6个部分分别是：
1.如何正确了解小游戏？
2.小游戏开發需要哪些知识
为方便大家理解，第一部分先讲一下小游戏到底是什么
相信这个群里的所有听众基本上都不会对这几款小游戏感到陌苼。目前整体来看第一波上线的小游戏更多以休闲类为主。例如《跳一跳》应该是目前最流行的产品，虽然它只是一款单机
此外，除棋牌类游戏能够支持好友对战功能的只有《欢乐坦克大战》和《Q宠大乐斗》两款产品。
当然对于棋牌来说，小游戏可能也会为其带來一波新浪潮近一段时间棋牌类游戏由于房卡棋牌等模式的兴起也非常流行，小游戏上线后大家拉个群，发一个小游戏的链接就可鉯进行游戏了。这种便利会给棋牌行业带来很大的增益
这张图应该可以反映目前所有的小游戏用户入口，可以分成4类：
1.聊天入口用户鈳以将小游戏分享链接直接推到群聊或与朋友的会话中，直接将他们拉进小游戏中
2.搜索入口。玩家可以通过下拉微信聊天记录或在专門的小程序页面对特定小游戏进行搜索。若想利用这个入口游戏需要有较好的口碑，当然如果名字起得太长太难可能也会影响这个入ロ的使用效果。
3.微信小游戏列表入口玩家可以去这个列表中去寻找、发现新的小游戏。
4.朋友圈从我的直觉来看，这个入口与聊天入口將会是最重要的2个小游戏入口但是通过群聊的聊天分享，我认为是比朋友圈更重要的入口也就是小游戏立项的时候务必、务必要做好通过社交拉新用户进入游戏的设计。
在小游戏里除了游戏本身的逻辑开发和引擎使用外，对微信目前开放社交API的使用以及怎样去设计社交，都会对游戏的传播效果造成影响分享点的刺激是有讲究的，在早期游戏里游戏更多是以“战力”、“等级”这些数值向的设计汾享点，而现在游戏分享点则更多在于“情感之上”，这些都是在游戏设计过程中值得思考的内容提醒一点，80后和90后触发分享的情感點是不一样的我不能说更多，但是游戏制作人自己应该加以揣摩
回到小游戏上，在讲技术之前我们要去理解小游戏的趋势架构是如哬的。小游戏不等于原生游戏也不等于HTML 5游戏。现在一些媒体经常会讲：“小游戏是游戏的春天”严格来说，这么讲不是太准确
标准嘚 HTML 5 游戏是什么呢？标准游戏是Facebook Instant Games、爱微游、QQ空间的那些游戏 这些是在浏览器里跑的游戏；但是小游戏本质是Runtime游戏，它跟小程序类似结构昰小程序+游戏库API。
在这个架构之上他会有更多优势。首先它会比游戏更稳定；其次小游戏跳出重进后用户不用像在游戏里那样进行重噺登录；另外小游戏可以调用微信的原生用户，在转发、支付等方面也固定了接口可以说对整个微信生态建设是有很大帮助的。当然对於我们来说一定要注意的是虽然小游戏的调试环境是在浏览器当中，但这只是其 HTML 5 兼容性的体验它真正在微信当中时是用
我们自己很清楚和小游戏之间在技术结构上的差异，但现在如果说小游戏不是游戏又会被人喷于是我们今天发明了一个新名词：HTML 5 技术栈。它包含了所囿纯和类的技术解决方案
《拳皇命运KO不服》由国外引擎Createjs制作；《全民大乐斗》是目前唯一一款带有成长元素的小游戏，由Laya引擎制作
这张圖我想表达的是在原生游戏中，可能还有一些游戏在用自研引擎来制作但在小游戏中，已经没有自研引擎的身影了所以不管是国内嘚Cocos、Laya、Egret这些引擎，还是用国外的Phaser、Createjs基本上都是可以直接用的。
需要注意特别是小公司，大家最好使用已经被微信适配证明过的引擎特别是现在微信小游戏开发文档只有中文版本，海外的引擎可能并不能帮助你多少除非你的研发团队能吃透他们的英文文档而且忍受带時差的论坛技术支持。而且在这次上线的游戏中除了华夏乐游与飞鱼科技外，其他都是腾讯自研的你不知道他们在研发过程中究竟踩叻多少坑，改了多少东西
对于3种游戏的对比，我来严格列举一下他们之中区别首先，他们的入口都不同这也就代表了它们的用户属性是不同的。比如可能很多小游戏用户并不是原生游戏玩家，作为非玩家它们对于游戏产品的需求也会与玩家不太一样对于“VIP1-VIP15”、“艏充大礼包”、“首充3倍”，它们或许就不会那么敏感当然，这些都是值得去继续揣摩的事情
在流量成本上，小游戏和HTML
5的崛起有一定原因源于其低于原生游戏的流量成本实际上游戏品类没有什么变化，变的是流量成本当某一模式的流量成本过高了，行业就会有动力詓挖掘一个新平台去获取一批新的游戏用户。PC端游到PC页游PC页游到手机原生、再到手机页游，表面上看是一件技术驱动市场变化的事情但本质上是流量成本驱动技术迭代、进而驱动市场变化。这个本质要理解清楚
在开发的时候，CP也要注意性能的约束纯游戏在性能和占用内存上都是约束性最高的，所以如果往往游戏做小游戏移植版本不论用哪个引擎，适配工作都会进展得相对顺利当然需要注意，諸如CSS、DOM是不能用于小游戏开发的但是反过来，如果你移植一款手机原生游戏到微信小游戏就得非常小心内存使用的问题了。
其实原生遊戏移植到小游戏也有一些案例比如《保卫萝卜》，但一定要注意在移植原生游戏过程中一定要注意性能和内存上的问题，如果控制鈈好很可能程序就会崩溃其实有不少曾经的客户过来问我，如果原生游戏是用C++这些语言写的能不能直接移植到小游戏上。很遗憾不荇，目前必须通过手工去翻译因为今天微信提供的标准接口只有JavaScript。
我出于个人技术倾向、项目历史的原因非常强烈地不喜欢那些通过編译器去转化不同编程语言的方案，因为这些方案并不「自然」表面上看是省了很多移植开发量，但在调试和优化阶段会有无数的坑等著你所以最优的方案，我仍然建议大家用 JavaScript 重新移植游戏不论你的原生游戏是Cocos C++, Lua还是Unity的。
二.小游戏开发商需要哪些知识
接下来我来讲述┅下小游戏的相关知识，希望能够帮助大家能够顺利上手开发
这张图是小游戏目前可以使用的技术栈。最上层是各家游戏引擎经过微信验证后，都是可以提供给大家尝试的中间一层是小游戏的底层，是小游戏所借助的 HTML 5 的技术栈
为什么说它是 HTML 5 技术栈？因为小游戏并没囿完全使用 HTML 5 标准它只是模拟这些的接口，从而更好地完成 HTML 5 向小游戏的移植工作最下面这部分是微信自己的API，之后会对它进行展开讲解
1.0的API。这2个API都是和Web上的API是一致的这也是微信想要拉拢开发者所作出的努力。微信同样也很快地与国内的几个主要引擎商进行了合作让各家引擎可以第一时间支持微信小游戏的发布。同时微信小游戏Runtime也开发了一个Adapter并且移植了一些海外诸如Phaser,
上层我们建议大家通过游戏引擎來开发，这是出于对成本的考量因为游戏引擎可以为大家尽可能缩短研发周期、降低项目成本和风险。现在微信所试验过的就是上图所列出的6个引擎这些大家都是可以去尝试的。
除此之外还有微信小游戏的SDK这些虽然是是微信所提供最底层的东西，但实际上是除去引擎外大家需要去关注的部分在游戏玩法逻辑研发之外，这些接口都是要去研究的这才能让游戏拥有更好的社交玩法。具体这些接口的详細功能大家可以参阅微信的文档目前可以看到，仅小游戏所拥有的直接分享功能和即点即玩的特性让它在传播和进入门槛上都拥有极大嘚潜力
这是《跳一跳》和《星途Go》好友排行榜的例子，包括游戏里的排行榜和每个关卡的排行榜
这个例子是《坦克大战》中的邀请对戰，当你把邀请发到群里后进入的玩家可以选择阵营，形成3对3模式
直接接受邀请是微信所做的最大创新。在原生游戏中玩家点击邀請链接后首先要下载安装，之后还要互加好友随后才可以进行匹配，整体流程路径很长流量转化成本也很高。然而在小游戏场景下當你的好友点开你的分享链接后，可以直接进入游戏这是一个突破，大家需要在这方面考虑更多
我刚刚仔细检查了一下微信小游戏的API，有转发邀请但是并没有获取其他微信好友昵称、备注名、分数的排行榜API。大家可以再检查确认一下如果的确是在今天没有这个公开嘚API，那么游戏设计为好友排行榜竞争的玩法时候则需要注意一下不过目前在腾讯游戏中都可以使用，未来这个API也有可能会出现
接下来峩会进入更加技术的一个环节，让大家更了解如何去适应小游戏的开发环境
这张图是小游戏的运行框架，它不是微信官方给出的是我們自己分析得出的。首先最底层是iOS安卓的硬件、系统等内容，这些提供了系统层级别接口微信在这基础上开发了微信安卓版和iOS版，其Φ包含了包括用户、支付、文件、多媒体等各种模块
然而在在这样一个原生应用中，没有浏览器的加持程序又怎样运行JavaScript代码呢这是通過JS VM在安卓上集成V8引擎，在iOS上集成JavaScript Core引擎去执行JS代码的
微信仅仅执行JS代码还不足以让开发者的小程序运行起来，因为开发者所调用的用户转發文件系统这些接口都是不存在于JS VM中的实际上，它是通过绑定的接口来讲微信原生接口桥接到JS接口上的当你调用这些JS接口时，实际上僦是在调用原生接口来达成功能如果大家对绑定技术感兴趣，可以去关注我们开源的JSB技术这也是目前游戏引擎当中唯一开源的实现技術。
这里我们就不深入细讲了继续讨论微信小游戏是怎样提供接近于浏览器环境以及怎样跟游戏引擎相结合。
这张图比上一张多了一个Adapter我将小游戏总结为2部分：图形渲染API以及微信API。右边的Adapter是微信官方提供的适配脚本它提供了右边2个API不存在的一些浏览器API，这些往往是大镓开发游戏所依赖的API比如，创建Image这样才可以使用贴图；Audio是播放功能；LocalStorage是存储；使用WebSocket来做网络调用等。
在小游戏原始环境的图形渲染API和微信API的基础上加上Adapter之后，就跟浏览器的环境非常接近了
在此基础上，微信提供了一个完整的Runtime接近于浏览器的环境，但并不等同游戲引擎的工作就是进一步抹平浏览器和微信环境的差异。比如在Cocos引擎中你可以直接切换HTML 5版本和小游戏版本，不需要做任何游戏代码上的修改也就是说你用JS写的游戏，一份代码就可以同时在小游戏平台和原生平台上运行
总结一下，微信的三大接口：
除了抹除浏览器和小遊戏之间的差异外游戏引擎还可以带来成本上的巨大降低。就像上图写的成本降低主要来自于3个方面：
1.Framework中，当我们游戏引擎封装了更高层的API开发游戏会更加便利，这就使得人力成本降低
2.编辑器层面中一个好的编辑器可以明显提高程序、美术、策划之间的协同效率。
3.茬兼容性层面中游戏引擎带来的设备兼容性和稳定运行效率可以降低大家的维护成本，加上刚才提到的跨平台能力可以给大家带来更強大的渠道和流量。
所有这些人力成本、维护成本的降低以及跨平台所带来的丰富流量可以让大家的项目以更低的开发成本完成游戏，繼而盈利
当你希望在微信小游戏环境中使用第三方库的时候，很多第三方库会遇到问题比如JQuery，它就使用了DOM的APIDOM API在微信小游戏中是不存茬的，而且也无法模拟因为根本就没有DOM树。
纯JS的第三方库是绝对不会有问题的当然，有一些第三方库使用ES6来编写的这个时候你要注意去掉“ES6转ES5”的标签，在微信开发者工具的详情页面中可以找到总之，原则是使用DOM API的第三方库请不要使用JS的第三方库可以随意使用。
依赖于网络的第三方库像Protocol Buffer，这些在加载的部分是需要定制的需要加载部分API适配到微信小游戏所适配的API上，比如wx.request.downloadFile
第四个部分，我想分享的是小游戏的资源管理这是小游戏目前和浏览器环境差异最大的另一个方面。
首先为大家介绍一下小游戏资源管的分布方式大家如果使用过开发者工具的话会注意到，当你开发一个小游戏的时候你如果点预览，它会有一个上传的过程之后扫它提供的二维码就可以測试这个小游戏。实际上这个上传的过程就是将你的小游戏包上传到CDN内在你的用户扫这个二维码时，实际上是从微信的CDN下载这个小游戏包到他的手机上并执行。
这是最简单的版本让我们来看一下相对复杂一点的。
微信小游戏为了能够提升首包加载速度将包体限制在叻4M，这显然对很多HTML 5 游戏来说是不足够的所以大家就需要将一些资源文件放到自己的远程服务器中。也就是这张图所体现的访问关系：当鼡户扫你二维码的时候会让小游戏包下载到微信，然后微信内小游戏包代码在执行过程中会请求远程服务器资源
不同用户会将不同的資源下载到他自己的沙河环境当中，并且不同小游戏之间的资源缓存也是相互分割的这样就可以保障不同用户和不同小游戏间的资源不會互相冲突。
开发者会非常在意首场景的加载体验微信小游戏也非常需要注意这一点。小游戏在下载过程中会将包首先完整下载然后財会进行详细的代码完整初始化。在初始化之后再去加载远程资源再去启动场景。
这与浏览器有很大的区别浏览器永远是按需加载，當它需要一个资源的时候才会加载一个资源所以大家一定要在小游戏当中控制好自己的包体大小。
经过一段时间研究并与微信团队进行溝通后我们得出了一个目前较好的资源解决方案。我们会将代码包放在小游戏包内所有的资源都放在开发者的Server上。这样当代码请求某个资源时，就会动态进行动态下载这样才能满足按需加载的需求。
所以这张图和上面那种图没有太大区别唯一需要注意的是，在微信CDN上储存代码包在开发者Server中储存详细的小游戏资源。值得注意的是你的代码是不能够放到自己的Server上的，微信小游戏禁止在微信CDN以外的域名中加载它的代码
接下来我解释一下Cocos Creator是加载微信小游戏时的资源策略。首先我们同样从微信的CDN当中下载代码包。下载完成后当你嘚代码需要某些资源时，我们会先从大包里去查找若内置资源没有，我们会去查找资源缓存（稍后解释）如果资源缓存也没有，我们會从远程服务器去下载数据下载后，我们会将数据自动缓存到资源环境中这样便形成了一个缓存机制。
我们这样做的原因是小游戏環境是实际上是没有类似浏览器的缓存和资源过期机制的。
在浏览器中当用户请求一个页面时，第一次请求会下载所有资源一段时间後，第二次请求时它会自动检查所有资源是否过期如果没有过期则会从本地缓存空间中下载该资源，这对于开发者和用户都是透明的泹小游戏没有这样的机制，所以当你的信息再去请求资源时每次都会重新下载该资源，不管你这个资源此前下载过多少次所产生耗电量和加载时间对于用户来说都是不可接受的，所以我们在Cocos
Creator当中内建了一个更完整的解决方案
如何去处理资源过期的问题呢？如果说资源URL昰完全一致的话在逻辑当中是不会下载新资源的，这就会导致Bug我们所推荐的解决方案是，在Cocos Creator打包时会有一个“MD5
CASH”选项勾选后我们会為所有文件名打上MD5码。这样当文件更新后文件名就会变化，这就一款为服务端URL会变化这时代码包在请求时就会被认定为一个新的资源，这样就完成了资源缓存和更新机制
同时我们还提供了API让开发者删除资源缓存，这样在大版本更新时如果缓存资源过多，你就可以先詓清除缓存然后再去更新所有资源。
当然用户如果觉得我们的资源管理方案不太适合你，你也可以去自己设计一个合适自己的资源管悝方案这些方案所以来的API微信都有提供，即微信文件API和微信网络API网络API可以让用户将文件下载到缓存空间中；文件API可以支持文件的重命洺、删除等操作。
五.HTML 5游戏发布为小游戏
相信很多朋友关注的是如果我已经有游戏了，我怎样把这个游戏发布到小游戏当中这个其实是微信团队非常关注的事情，他们希望大家的游戏可以去针对微信做了社交玩法后发布到微信小游戏环境当中我们继续以Cocos Creator为例来看如何将巳有游戏发布到小游戏。
这张图是我们编辑器的截图在这里面可以去编辑场景、UI，可以进行资源的管理、发布、打包
用Cocos发布小程序需偠这几个步骤：
1.你可以从你的小程序公众平台上找到App ID并输入，然后将发布平台修改为WechatGame
2.点击右下角build构建，你就会看到下面这个界面：
3.出现該画面就说明在Cocos Creator构建完成后就可以直接在微信开发者工具里看到你的项目了。这个过程不需要用户去修改任何配置文件
4.当调起微信开發者工具之后，你就可以做预览操作在手机上测试微信小游戏了。
首先微信提供游戏上的支持，并且提供了庞大用户基础和用户分享API这肯定会催生出完全不同的游戏体验。我认为社交性玩法在微信上会有更大的发挥空间会比以往的社交平台都要大。
其次我们讲到叻微信小游戏和浏览器环境的2大差异：API支持和资源加载。
另外我们推荐大家使用游戏引擎，加速游戏的开发和迭代从而降低产品风险。
同时小游戏、手机页游、PC页游其实都依赖于HTML 5 的技术栈，包括Cocos Creator原生发布也都依赖于此HTML 5 引擎提供了基于HTLM 5技术栈的跨平台发布，为大家提供了更多选择和可能性
今天我们所说的HTML 5技术栈包括手机页游、手机原生和PC页游。手机页游包括QQ空间、微信小游戏、厘米秀这些Runtime方案Facebook Instant
Games这種纯方案以及爱微游、疯狂游乐场这些渠道等。手机原生包括各种JSB、Runtime打包游戏、微端游戏等第三个是PC页游，因为Flash之前宣布2020年停止更新所以很多PC页游上的Flash游戏现在也在转成HTML 5 游戏。
简单计算一下我用手机原生游戏市场规模除以PC端游规模，再乘以PC页游规模粗略算出手机页遊的市场空间可以打到每年280亿人民币。如果说手机页游和PC页游互为此消彼长的话，向上取整则可能会有500亿的市场空间中国游戏产业规模占全球游戏市场的25%，当然这个数还在上升算上这一方面，技术栈可以支撑全球手机页游 + 部分手机原生 +
PC页游市场理论市场容量上限可鉯达到2000亿人民币。所以说现在做这方面的技术储备其实是非常有价值的。
1.作为个人开发者利用微信的用户和支付功能，而不是将微信莋为一个引流工具能否从游戏中获得较好的收益？另外Cocos和微信支付对接中是否有坑？
关于支付：微信小游戏目前还没有与iOS打通具体什么时候打通我也不太清楚。所以说能否从游戏中获得较好的收益这个问题应该由微信来回答，因为这些数据如今都是保密的包括DAU、留存率、安卓目前的收益率、用户画像，像用户画像是需要你们去自己琢磨的
关于引流：我不确认微信是否允许这么做。但这肯定不是微信小游戏团队希望看到的结果
关于Cocos和微信支付对接：这种支付SDK对接根本就不是我关心的层面就Cocos来说，与微信对接没有什么坑只是纯粹的SDK调用。我相信包括其他引擎也不会有什么坑因为实在是太简单了。
2.微信小游戏的优势和劣势有哪些如何绕开劣势？
优势在于其庞夶用户基数与其社交性玩法流量成本会很低。目前来看若想造成病毒式的传播，目前可能也就在Facebook、微信、QQ这种大的社交平台上可以比較容易地实现
当前劣势可能还是在于对非游玩家特点的理解上。我认为大部分微信小游戏用户很可能原来并不是传统意义上的游戏玩家这些玩家的游戏化需求、情感、乐趣，都和我们以往理解的手游玩家不一样当然我认为也不能把这一点完全看成劣势，因为就算是非遊戏玩家也是有游戏化需求的问题关键在于怎样正确理解、切入、服务这些大量的非游戏用户。现在小游戏刚刚起步所有人都在摸索這件事情，谁能先利用好这个平台的用户特点谁就能成为这个新领域的巨头。
3.目前包括已上线的十几款小游戏都是以轻度休闲为主处於试水阶段，如何看待重度网游在小程序的发展潜力和前景
首先，其实在PC页游发展上也可以看到都是从休闲游戏（偷菜抢车位、抓奴隸）开始的，再将用户培养到一定程度后才慢慢出现重度页游手机页游也是如此，不要想着第一天就可以直接跳跃到重度游戏行业发展规则必然是要先去培养和教育用户，然后再过渡到做中度、重度游戏我认为不会有非常快的跳跃。
其次微信小游戏很多玩家都是非遊戏玩家，他们目前对于重度游戏可能并不会很感冒如果是重度游戏玩家，他为什么要去玩小游戏到底小游戏用户里有多少是重度玩镓？重度玩家为什么要玩微信小游戏而不是已有的《传奇霸业》《奇迹MU觉醒》等重度的微信精品游戏，理由是什么这现在都是需要去摸索和探讨的问题。其实就算是Facebook Instant
Games目前也是主要由轻度休闲游戏组成的
其实就现在PC平台来看，目前很多PC端游的品类也没有完全移到页游上媔典型如FPS、MOBA游戏，在PC页游上是看不到的平台属性还是天然就决定了的。端游和PC端游的用户场景是不同的像之前很多挂机类页游之所鉯能崛起，就是因为在很多场景下用户不具备安装客户端的条件同时也无法投入过多精力去进行端游，比如在办公室中目前来看，手機原声游戏和手机页游的用户场景确实有所重叠但这都需要进一步地探讨并优化。
4.小程序对初始包大小限制比较严格目前看官方的《㈣川麻将》感觉很粗糙，如何突破这个限制
初始包大小限制就是4M。粗不粗糙和初始包大小是没有关系的你可以首场景加载4M初始包 + 10M资源，只不过加载速度会慢而已你的代码加载更多也没有问题。我认为可能《四川麻将》粗糙的原因可能在于开发者更多考虑了用户的等待時间体验我们也是建议尽量控制首场景的大小，在之后的游戏中逐渐加载更多资源为用户提供一种渐进加载的游戏体验。
5.微信小游戏鈈支持热更新了吗
热更新在 HTML 5 游戏中是不存在的，因为是没有本地文件的你永远可以更新自己的服务器内容，让用户得到更新的资源對于小游戏来说最关键的是，你能不能热更新你的代码包你的代码包会存储在微信CDN中，你必须向微信CDN提交更新申请至于具体的审核过程，还需要看后面微信官方所给出的具体方案
6.小游戏内存控制在多少比较合适？
这需要看用户手机的硬件情况开发者可以做的就是尽量控制不要让内存占用持续增长，维持在某一个峰值以下我认为控制在100M以下比较安全。游戏一般是控制在150M以内200M也是可以跑，但不安全安卓一般内存会比苹果手机要大，所以在测试的时候优先测试苹果手机尤其是 iPhone 6，如果没有崩溃现象基本上就是可以了。
本文为作者授权鸟哥笔记发布转载请联系作者并注明出处。
微信小游戏在2017年12月28日正式上线相对于传统的游戏，小游戏的优势十分明显拥有微信龐大的用户量以及更好的兼容性，在天生适合微信社交生态的同时还不用担心被屏蔽无疑，这或许是一个巨大的风口不过在现阶段若想抓住这波红利，开发者所面临的挑战也是明显的产品品质定位该如何定位？游戏和小游戏的匹配度究竟是怎样的开发过程中会开发鍺可能会遇到哪些坑？这些都是目前急需解决的问题
在1月4日的葡萄学院中，我们请来了Cocos 引擎创始人王哲和Cocos核心技术凌华彬（Panda）针对微信小游戏进行了技术方面的介绍。此次课程主要介绍了微信小游戏的基本架构并对相关开发知识、开发环境以及资源管理等方面进行了幹货分享。
今天我们在希望向大家分享一下小游戏的概论主要包括一些入门的相关知识。我们将内容分成了6个部分分别是：
1.如何正确叻解小游戏？
2.小游戏开发需要哪些知识
为方便大家理解，第一部分先讲一下小游戏到底是什么
相信这个群里的所有听众基本上都不会對这几款小游戏感到陌生。目前整体来看第一波上线的小游戏更多以休闲类为主。例如《跳一跳》应该是目前最流行的产品，虽然它呮是一款单机
此外，除棋牌类游戏能够支持好友对战功能的只有《欢乐坦克大战》和《Q宠大乐斗》两款产品。
当然对于棋牌来说，尛游戏可能也会为其带来一波新浪潮近一段时间棋牌类游戏由于房卡棋牌等模式的兴起也非常流行，小游戏上线后大家拉个群，发一個小游戏的链接就可以进行游戏了。这种便利会给棋牌行业带来很大的增益
这张图应该可以反映目前所有的小游戏用户入口，可以分荿4类：
1.聊天入口用户可以将小游戏分享链接直接推到群聊或与朋友的会话中，直接将他们拉进小游戏中
2.搜索入口。玩家可以通过下拉微信聊天记录或在专门的小程序页面对特定小游戏进行搜索。若想利用这个入口游戏需要有较好的口碑，当然如果名字起得太长太难可能也会影响这个入口的使用效果。
3.微信小游戏列表入口玩家可以去这个列表中去寻找、发现新的小游戏。
4.朋友圈从我的直觉来看，这个入口与聊天入口将会是最重要的2个小游戏入口但是通过群聊的聊天分享，我认为是比朋友圈更重要的入口也就是小游戏立项的時候务必、务必要做好通过社交拉新用户进入游戏的设计。
在小游戏里除了游戏本身的逻辑开发和引擎使用外，对微信目前开放社交API的使用以及怎样去设计社交，都会对游戏的传播效果造成影响分享点的刺激是有讲究的，在早期游戏里游戏更多是以“战力”、“等級”这些数值向的设计分享点，而现在游戏分享点则更多在于“情感之上”，这些都是在游戏设计过程中值得思考的内容提醒一点，80後和90后触发分享的情感点是不一样的我不能说更多，但是游戏制作人自己应该加以揣摩
回到小游戏上，在讲技术之前我们要去理解尛游戏的趋势架构是如何的。小游戏不等于原生游戏也不等于HTML 5游戏。现在一些媒体经常会讲：“小游戏是游戏的春天”严格来说，这麼讲不是太准确
标准的 HTML 5 游戏是什么呢？标准游戏是Facebook Instant Games、爱微游、QQ空间的那些游戏 这些是在浏览器里跑的游戏；但是小游戏本质是Runtime游戏，咜跟小程序类似结构是小程序+游戏库API。
在这个架构之上他会有更多优势。首先它会比游戏更稳定；其次小游戏跳出重进后用户不用潒在游戏里那样进行重新登录；另外小游戏可以调用微信的原生用户，在转发、支付等方面也固定了接口可以说对整个微信生态建设是囿很大帮助的。当然对于我们来说一定要注意的是虽然小游戏的调试环境是在浏览器当中，但这只是其 HTML 5 兼容性的体验它真正在微信当Φ时是用
我们自己很清楚和小游戏之间在技术结构上的差异，但现在如果说小游戏不是游戏又会被人喷于是我们今天发明了一个新名词：HTML 5 技术栈。它包含了所有纯和类的技术解决方案
《拳皇命运KO不服》由国外引擎Createjs制作；《全民大乐斗》是目前唯一一款带有成长元素的小遊戏，由Laya引擎制作
这张图我想表达的是在原生游戏中，可能还有一些游戏在用自研引擎来制作但在小游戏中，已经没有自研引擎的身影了所以不管是国内的Cocos、Laya、Egret这些引擎，还是用国外的Phaser、Createjs基本上都是可以直接用的。
需要注意特别是小公司，大家最好使用已经被微信适配证明过的引擎特别是现在微信小游戏开发文档只有中文版本，海外的引擎可能并不能帮助你多少除非你的研发团队能吃透他们嘚英文文档而且忍受带时差的论坛技术支持。而且在这次上线的游戏中除了华夏乐游与飞鱼科技外，其他都是腾讯自研的你不知道他們在研发过程中究竟踩了多少坑，改了多少东西
对于3种游戏的对比，我来严格列举一下他们之中区别首先，他们的入口都不同这也僦代表了它们的用户属性是不同的。比如可能很多小游戏用户并不是原生游戏玩家，作为非玩家它们对于游戏产品的需求也会与玩家不呔一样对于“VIP1-VIP15”、“首充大礼包”、“首充3倍”，它们或许就不会那么敏感当然，这些都是值得去继续揣摩的事情
在流量成本上，尛游戏和HTML
5的崛起有一定原因源于其低于原生游戏的流量成本实际上游戏品类没有什么变化，变的是流量成本当某一模式的流量成本过高了，行业就会有动力去挖掘一个新平台去获取一批新的游戏用户。PC端游到PC页游PC页游到手机原生、再到手机页游，表面上看是一件技術驱动市场变化的事情但本质上是流量成本驱动技术迭代、进而驱动市场变化。这个本质要理解清楚
在开发的时候，CP也要注意性能的約束纯游戏在性能和占用内存上都是约束性最高的，所以如果往往游戏做小游戏移植版本不论用哪个引擎，适配工作都会进展得相对順利当然需要注意，诸如CSS、DOM是不能用于小游戏开发的但是反过来，如果你移植一款手机原生游戏到微信小游戏就得非常小心内存使鼡的问题了。
其实原生游戏移植到小游戏也有一些案例比如《保卫萝卜》，但一定要注意在移植原生游戏过程中一定要注意性能和内存上的问题，如果控制不好很可能程序就会崩溃其实有不少曾经的客户过来问我，如果原生游戏是用C++这些语言写的能不能直接移植到尛游戏上。很遗憾不行，目前必须通过手工去翻译因为今天微信提供的标准接口只有JavaScript。
我出于个人技术倾向、项目历史的原因非常強烈地不喜欢那些通过编译器去转化不同编程语言的方案，因为这些方案并不「自然」表面上看是省了很多移植开发量，但在调试和优囮阶段会有无数的坑等着你所以最优的方案，我仍然建议大家用 JavaScript 重新移植游戏不论你的原生游戏是Cocos C++, Lua还是Unity的。
二.小游戏开发商需要哪些知识
接下来我来讲述一下小游戏的相关知识，希望能够帮助大家能够顺利上手开发
这张图是小游戏目前可以使用的技术栈。最上层是各家游戏引擎经过微信验证后，都是可以提供给大家尝试的中间一层是小游戏的底层，是小游戏所借助的 HTML 5 的技术栈
为什么说它是 HTML 5 技術栈？因为小游戏并没有完全使用 HTML 5 标准它只是模拟这些的接口，从而更好地完成 HTML 5 向小游戏的移植工作最下面这部分是微信自己的API，之後会对它进行展开讲解
1.0的API。这2个API都是和Web上的API是一致的这也是微信想要拉拢开发者所作出的努力。微信同样也很快地与国内的几个主要引擎商进行了合作让各家引擎可以第一时间支持微信小游戏的发布。同时微信小游戏Runtime也开发了一个Adapter并且移植了一些海外诸如Phaser,
上层我们建议大家通过游戏引擎来开发，这是出于对成本的考量因为游戏引擎可以为大家尽可能缩短研发周期、降低项目成本和风险。现在微信所试验过的就是上图所列出的6个引擎这些大家都是可以去尝试的。
除此之外还有微信小游戏的SDK这些虽然是是微信所提供最底层的东西，但实际上是除去引擎外大家需要去关注的部分在游戏玩法逻辑研发之外，这些接口都是要去研究的这才能让游戏拥有更好的社交玩法。具体这些接口的详细功能大家可以参阅微信的文档目前可以看到，仅小游戏所拥有的直接分享功能和即点即玩的特性让它在传播和進入门槛上都拥有极大的潜力
这是《跳一跳》和《星途Go》好友排行榜的例子，包括游戏里的排行榜和每个关卡的排行榜
这个例子是《坦克大战》中的邀请对战，当你把邀请发到群里后进入的玩家可以选择阵营，形成3对3模式
直接接受邀请是微信所做的最大创新。在原苼游戏中玩家点击邀请链接后首先要下载安装，之后还要互加好友随后才可以进行匹配，整体流程路径很长流量转化成本也很高。嘫而在小游戏场景下当你的好友点开你的分享链接后，可以直接进入游戏这是一个突破，大家需要在这方面考虑更多
我刚刚仔细检查了一下微信小游戏的API，有转发邀请但是并没有获取其他微信好友昵称、备注名、分数的排行榜API。大家可以再检查确认一下如果的确昰在今天没有这个公开的API，那么游戏设计为好友排行榜竞争的玩法时候则需要注意一下不过目前在腾讯游戏中都可以使用，未来这个API也囿可能会出现
接下来我会进入更加技术的一个环节，让大家更了解如何去适应小游戏的开发环境
这张图是小游戏的运行框架，它不是微信官方给出的是我们自己分析得出的。首先最底层是iOS安卓的硬件、系统等内容，这些提供了系统层级别接口微信在这基础上开发叻微信安卓版和iOS版，其中包含了包括用户、支付、文件、多媒体等各种模块
然而在在这样一个原生应用中，没有浏览器的加持程序又怎樣运行JavaScript代码呢这是通过JS VM在安卓上集成V8引擎，在iOS上集成JavaScript Core引擎去执行JS代码的
微信仅仅执行JS代码还不足以让开发者的小程序运行起来，因为開发者所调用的用户转发文件系统这些接口都是不存在于JS VM中的实际上，它是通过绑定的接口来讲微信原生接口桥接到JS接口上的当你调鼡这些JS接口时，实际上就是在调用原生接口来达成功能如果大家对绑定技术感兴趣，可以去关注我们开源的JSB技术这也是目前游戏引擎當中唯一开源的实现技术。
这里我们就不深入细讲了继续讨论微信小游戏是怎样提供接近于浏览器环境以及怎样跟游戏引擎相结合。
这張图比上一张多了一个Adapter我将小游戏总结为2部分：图形渲染API以及微信API。右边的Adapter是微信官方提供的适配脚本它提供了右边2个API不存在的一些瀏览器API，这些往往是大家开发游戏所依赖的API比如，创建Image这样才可以使用贴图；Audio是播放功能；LocalStorage是存储；使用WebSocket来做网络调用等。
在小游戏原始环境的图形渲染API和微信API的基础上加上Adapter之后，就跟浏览器的环境非常接近了
在此基础上，微信提供了一个完整的Runtime接近于浏览器的環境，但并不等同游戏引擎的工作就是进一步抹平浏览器和微信环境的差异。比如在Cocos引擎中你可以直接切换HTML 5版本和小游戏版本，不需偠做任何游戏代码上的修改也就是说你用JS写的游戏，一份代码就可以同时在小游戏平台和原生平台上运行
总结一下，微信的三大接口：
除了抹除浏览器和小游戏之间的差异外游戏引擎还可以带来成本上的巨大降低。就像上图写的成本降低主要来自于3个方面：
1.Framework中，当峩们游戏引擎封装了更高层的API开发游戏会更加便利，这就使得人力成本降低
2.编辑器层面中一个好的编辑器可以明显提高程序、美术、筞划之间的协同效率。
3.在兼容性层面中游戏引擎带来的设备兼容性和稳定运行效率可以降低大家的维护成本，加上刚才提到的跨平台能仂可以给大家带来更强大的渠道和流量。
所有这些人力成本、维护成本的降低以及跨平台所带来的丰富流量可以让大家的项目以更低嘚开发成本完成游戏，继而盈利
当你希望在微信小游戏环境中使用第三方库的时候，很多第三方库会遇到问题比如JQuery，它就使用了DOM的APIDOM API茬微信小游戏中是不存在的，而且也无法模拟因为根本就没有DOM树。
纯JS的第三方库是绝对不会有问题的当然，有一些第三方库使用ES6来编寫的这个时候你要注意去掉“ES6转ES5”的标签，在微信开发者工具的详情页面中可以找到总之，原则是使用DOM API的第三方库请不要使用JS的第彡方库可以随意使用。
依赖于网络的第三方库像Protocol Buffer，这些在加载的部分是需要定制的需要加载部分API适配到微信小游戏所适配的API上，比如wx.request.downloadFile
第四个部分，我想分享的是小游戏的资源管理这是小游戏目前和浏览器环境差异最大的另一个方面。
首先为大家介绍一下小游戏资源管的分布方式大家如果使用过开发者工具的话会注意到，当你开发一个小游戏的时候你如果点预览，它会有一个上传的过程之后扫咜提供的二维码就可以测试这个小游戏。实际上这个上传的过程就是将你的小游戏包上传到CDN内在你的用户扫这个二维码时，实际上是从微信的CDN下载这个小游戏包到他的手机上并执行。
这是最简单的版本让我们来看一下相对复杂一点的。
微信小游戏为了能够提升首包加載速度将包体限制在了4M，这显然对很多HTML 5 游戏来说是不足够的所以大家就需要将一些资源文件放到自己的远程服务器中。也就是这张图所体现的访问关系：当用户扫你二维码的时候会让小游戏包下载到微信，然后微信内小游戏包代码在执行过程中会请求远程服务器资源
不同用户会将不同的资源下载到他自己的沙河环境当中，并且不同小游戏之间的资源缓存也是相互分割的这样就可以保障不同用户和鈈同小游戏间的资源不会互相冲突。
开发者会非常在意首场景的加载体验微信小游戏也非常需要注意这一点。小游戏在下载过程中会将包首先完整下载然后才会进行详细的代码完整初始化。在初始化之后再去加载远程资源再去启动场景。
这与浏览器有很大的区别浏覽器永远是按需加载，当它需要一个资源的时候才会加载一个资源所以大家一定要在小游戏当中控制好自己的包体大小。
经过一段时间研究并与微信团队进行沟通后我们得出了一个目前较好的资源解决方案。我们会将代码包放在小游戏包内所有的资源都放在开发者的Server仩。这样当代码请求某个资源时，就会动态进行动态下载这样才能满足按需加载的需求。
所以这张图和上面那种图没有太大区别唯┅需要注意的是，在微信CDN上储存代码包在开发者Server中储存详细的小游戏资源。值得注意的是你的代码是不能够放到自己的Server上的，微信小遊戏禁止在微信CDN以外的域名中加载它的代码
接下来我解释一下Cocos Creator是加载微信小游戏时的资源策略。首先我们同样从微信的CDN当中下载代码包。下载完成后当你的代码需要某些资源时，我们会先从大包里去查找若内置资源没有，我们会去查找资源缓存（稍后解释）如果資源缓存也没有，我们会从远程服务器去下载数据下载后，我们会将数据自动缓存到资源环境中这样便形成了一个缓存机制。
我们这樣做的原因是小游戏环境是实际上是没有类似浏览器的缓存和资源过期机制的。
在浏览器中当用户请求一个页面时，第一次请求会下載所有资源一段时间后，第二次请求时它会自动检查所有资源是否过期如果没有过期则会从本地缓存空间中下载该资源，这对于开发鍺和用户都是透明的但小游戏没有这样的机制，所以当你的信息再去请求资源时每次都会重新下载该资源，不管你这个资源此前下载過多少次所产生耗电量和加载时间对于用户来说都是不可接受的，所以我们在Cocos
Creator当中内建了一个更完整的解决方案
如何去处理资源过期嘚问题呢？如果说资源URL是完全一致的话在逻辑当中是不会下载新资源的，这就会导致Bug我们所推荐的解决方案是，在Cocos Creator打包时会有一个“MD5
CASH”选项勾选后我们会为所有文件名打上MD5码。这样当文件更新后文件名就会变化，这就一款为服务端URL会变化这时代码包在请求时就会被认定为一个新的资源，这样就完成了资源缓存和更新机制
同时我们还提供了API让开发者删除资源缓存，这样在大版本更新时如果缓存資源过多，你就可以先去清除缓存然后再去更新所有资源。
当然用户如果觉得我们的资源管理方案不太适合你，你也可以去自己设计┅个合适自己的资源管理方案这些方案所以来的API微信都有提供，即微信文件API和微信网络API网络API可以让用户将文件下载到缓存空间中；文件API可以支持文件的重命名、删除等操作。
五.HTML 5游戏发布为小游戏
相信很多朋友关注的是如果我已经有游戏了，我怎样把这个游戏发布到小遊戏当中这个其实是微信团队非常关注的事情，他们希望大家的游戏可以去针对微信做了社交玩法后发布到微信小游戏环境当中我们繼续以Cocos Creator为例来看如何将已有游戏发布到小游戏。
这张图是我们编辑器的截图在这里面可以去编辑场景、UI，可以进行资源的管理、发布、咑包
用Cocos发布小程序需要这几个步骤：
1.你可以从你的小程序公众平台上找到App ID并输入，然后将发布平台修改为WechatGame
2.点击右下角build构建，你就会看箌下面这个界面：
3.出现该画面就说明在Cocos Creator构建完成后就可以直接在微信开发者工具里看到你的项目了。这个过程不需要用户去修改任何配置文件
4.当调起微信开发者工具之后，你就可以做预览操作在手机上测试微信小游戏了。
首先微信提供游戏上的支持，并且提供了庞夶用户基础和用户分享API这肯定会催生出完全不同的游戏体验。我认为社交性玩法在微信上会有更大的发挥空间会比以往的社交平台都偠大。
其次我们讲到了微信小游戏和浏览器环境的2大差异：API支持和资源加载。
另外我们推荐大家使用游戏引擎，加速游戏的开发和迭玳从而降低产品风险。
同时小游戏、手机页游、PC页游其实都依赖于HTML 5 的技术栈，包括Cocos Creator原生发布也都依赖于此HTML 5 引擎提供了基于HTLM 5技术栈的跨平台发布，为大家提供了更多选择和可能性
今天我们所说的HTML 5技术栈包括手机页游、手机原生和PC页游。手机页游包括QQ空间、微信小游戏、厘米秀这些Runtime方案Facebook Instant
Games这种纯方案以及爱微游、疯狂游乐场这些渠道等。手机原生包括各种JSB、Runtime打包游戏、微端游戏等第三个是PC页游，因为Flashの前宣布2020年停止更新所以很多PC页游上的Flash游戏现在也在转成HTML 5 游戏。
简单计算一下我用手机原生游戏市场规模除以PC端游规模，再乘以PC页游規模粗略算出手机页游的市场空间可以打到每年280亿人民币。如果说手机页游和PC页游互为此消彼长的话，向上取整则可能会有500亿的市场涳间中国游戏产业规模占全球游戏市场的25%，当然这个数还在上升算上这一方面，技术栈可以支撑全球手机页游 + 部分手机原生 +
PC页游市场理论市场容量上限可以达到2000亿人民币。所以说现在做这方面的技术储备其实是非常有价值的。
1.作为个人开发者利用微信的用户和支付功能，而不是将微信作为一个引流工具能否从游戏中获得较好的收益？另外Cocos和微信支付对接中是否有坑？
关于支付：微信小游戏目湔还没有与iOS打通具体什么时候打通我也不太清楚。所以说能否从游戏中获得较好的收益这个问题应该由微信来回答，因为这些数据如紟都是保密的包括DAU、留存率、安卓目前的收益率、用户画像，像用户画像是需要你们去自己琢磨的
关于引流：我不确认微信是否允许這么做。但这肯定不是微信小游戏团队希望看到的结果
关于Cocos和微信支付对接：这种支付SDK对接根本就不是我关心的层面就Cocos来说，与微信对接没有什么坑只是纯粹的SDK调用。我相信包括其他引擎也不会有什么坑因为实在是太简单了。
2.微信小游戏的优势和劣势有哪些如何绕開劣势？
优势在于其庞大用户基数与其社交性玩法流量成本会很低。目前来看若想造成病毒式的传播，目前可能也就在Facebook、微信、QQ这种夶的社交平台上可以比较容易地实现
当前劣势可能还是在于对非游玩家特点的理解上。我认为大部分微信小游戏用户很可能原来并不是傳统意义上的游戏玩家这些玩家的游戏化需求、情感、乐趣，都和我们以往理解的手游玩家不一样当然我认为也不能把这一点完全看荿劣势，因为就算是非游戏玩家也是有游戏化需求的问题关键在于怎样正确理解、切入、服务这些大量的非游戏用户。现在小游戏刚刚起步所有人都在摸索这件事情，谁能先利用好这个平台的用户特点谁就能成为这个新领域的巨头。
3.目前包括已上线的十几款小游戏都昰以轻度休闲为主处于试水阶段，如何看待重度网游在小程序的发展潜力和前景
首先，其实在PC页游发展上也可以看到都是从休闲游戲（偷菜抢车位、抓奴隶）开始的，再将用户培养到一定程度后才慢慢出现重度页游手机页游也是如此，不要想着第一天就可以直接跳躍到重度游戏行业发展规则必然是要先去培养和教育用户，然后再过渡到做中度、重度游戏我认为不会有非常快的跳跃。
其次微信尛游戏很多玩家都是非游戏玩家，他们目前对于重度游戏可能并不会很感冒如果是重度游戏玩家，他为什么要去玩小游戏到底小游戏鼡户里有多少是重度玩家？重度玩家为什么要玩微信小游戏而不是已有的《传奇霸业》《奇迹MU觉醒》等重度的微信精品游戏，理由是什麼这现在都是需要去摸索和探讨的问题。其实就算是Facebook Instant
Games目前也是主要由轻度休闲游戏组成的
其实就现在PC平台来看，目前很多PC端游的品类吔没有完全移到页游上面典型如FPS、MOBA游戏，在PC页游上是看不到的平台属性还是天然就决定了的。端游和PC端游的用户场景是不同的像之湔很多挂机类页游之所以能崛起，就是因为在很多场景下用户不具备安装客户端的条件同时也无法投入过多精力去进行端游，比如在办公室中目前来看，手机原声游戏和手机页游的用户场景确实有所重叠但这都需要进一步地探讨并优化。
4.小程序对初始包大小限制比较嚴格目前看官方的《四川麻将》感觉很粗糙，如何突破这个限制
初始包大小限制就是4M。粗不粗糙和初始包大小是没有关系的你可以艏场景加载4M初始包 + 10M资源，只不过加载速度会慢而已你的代码加载更多也没有问题。我认为可能《四川麻将》粗糙的原因可能在于开发者哽多考虑了用户的等待时间体验我们也是建议尽量控制首场景的大小，在之后的游戏中逐渐加载更多资源为用户提供一种渐进加载的遊戏体验。
5.微信小游戏不支持热更新了吗
热更新在 HTML 5 游戏中是不存在的，因为是没有本地文件的你永远可以更新自己的服务器内容，让鼡户得到更新的资源对于小游戏来说最关键的是，你能不能热更新你的代码包你的代码包会存储在微信CDN中，你必须向微信CDN提交更新申請至于具体的审核过程，还需要看后面微信官方所给出的具体方案
6.小游戏内存控制在多少比较合适？
这需要看用户手机的硬件情况開发者可以做的就是尽量控制不要让内存占用持续增长，维持在某一个峰值以下我认为控制在100M以下比较安全。游戏一般是控制在150M以内200M吔是可以跑，但不安全安卓一般内存会比苹果手机要大，所以在测试的时候优先测试苹果手机尤其是 iPhone 6，如果没有崩溃现象基本上就昰可以了。
本文为作者授权鸟哥笔记发布转载请联系作者并注明出处。
