从0到1，深度解读小游戏开发技术奥秘

自 2018 年初，首批微信小程序游戏上线，从凭借微信带来的巨大流量和变现能力，小游戏生态极速地建立了起来。截至到目前，微信小游戏月活用户已超 4 亿，开发者高达数十万。在现如今的游戏市场寒冬中，拥有微信庞大的用户量以及更好兼容性的小程序游戏，优势就显得格外明显。无疑，这将会是一个巨大的风口。

那么，如何从 0 到 1 去实现一款微信小游戏？微信小游戏背后的技术本质是什么？提供哪些能力和玩法？使用小程序·云开发将获得哪些独家优势？带着对这些问题的解答，来自腾讯云·云开发团队与微信团队的四位讲师开始了这场技术布道。

如何入手开发一款小游戏？

众所周知，微信第三方开发分为两类，一类是基于行业通用网页技术框架开发的微信 H5 与公众号文章，另一类则是基于微信技术框架开发，包含着微信私有技术特性的普通小程序与小游戏。

在 H5、普通小程序与小游戏之间的区别中，目前小游戏是唯一一个真正支持关系链数据使用方案的。为此，腾讯高级工程师周桂华（花叔）讲解道，一个微信用户的关系链数据包括两部分，一部分为用户好友的用户数据，另一部分为该用户所在的某个群的群成员用户数据。之前为了保护用户关系链数据，微信基于技术框架会在前端做一个封闭式的子域，而主域会把信息丢给开放数据，这个开放数据也就是子域。每当子域需要暴露关系链的数据，如绘制排行榜等业务场景，需要将排行榜绘制到封闭式的 sharedCanvas 上，再在主域将 sharedCanvas 渲染上屏。

然而，子域不可能发出第三方请求，每个开发者的数据库都是微信定义在托管服务器里，你的业务数据只能跟主域做交互。但在最新一套的开放能力中，微信提供 JSServer 服务器与互动型托管数据。其中，互动型托管数据是把好友之间的交互数据单独存一份的数据，而 JSServer 的作用则是校验用户数据，顺便把数据存到普通的托管数据里。

在演讲中，拥有重构工程师和设计师“双重身份”的花叔，提起自己第一次开发小游戏，深有感触地说道：“如果第一次做游戏的话，你会有一种感觉，像是你在创造一个世界。其实我对第一个游戏最大的感触是非常开心。”

2017 年，小程序诞生，为了学习如何开发小程序，花叔尝试做了一款关于思维导图的小程序工具。当小游戏出现后，花叔默默定下了独立开发一款小游戏的目标。在开发的过程中，花叔渐渐发现，CreateJS 做游戏有点弱，那是偏程序编码的开发方式，虽然在做数据调用和程序逻辑方面比较灵活，但是做游戏 UI 效果，CreateJS 会显得无力，因为要一行行代码写，效率不高。而实际游戏开发中，UI 效果的制作工作量又不少，所以 CreateJS 在游戏开发上面还是略逊一筹，可以说它只是个代码库，要真正做游戏还是需要一整套开发套件才行。

那么，偏程序开发的形式来开发游戏太累，怎么办？此后花叔慢慢转战 Coccos Creator。起初，作为代码流的花叔一开始挺不习惯 Coccos Creator 的开发流程，其开发理念是以工作流为核心，让不同职能的开发者能够快速找到最大化自己作用的工作切入点，并能够默契流畅的和团队其他成员配合。

简单来说，Coccos Creator 就是把游戏中可能用到的各类功能或者元素封装成一个个组件，这些组件带有自己的回调方法，组件在可视化开发工具里就能通过拖拽和拼装形成游戏。Coccos Creator 还有有一个比较好的点是：它约定了程序员可以定义一些属性，这些属性能暴露给其他同学去修改。这样就可以很好地解决前端诉求，开发质量和开发效率的问题。

但是接下来又有另外一个问题，传统服务器后端方案太庞杂，一个半前端的开发工程师，怎么独立并快速开发游戏？以花叔开发的《影子的游戏》为例，这个游戏也是基于 Coccos Creator，后端方案跟上述所说的不太一样，是基于云的。而这时的技术框架很简单，上面是小程序云，下面是小游戏端，而小程序·云开发只需要一个前端开发就搞定。

而小程序·云开发解决的问题，就是前端开发和后端开发中间的并行过程。小程序·云开发提供了三板斧和两封装，三板斧指的是小程序·云开发提供了数据库、存储、云函数的能力，两封装则指鉴权与云调用。其中，某些方法在调用的时候，开发者需要做服务端 API AccessToken 机制，抑或是小程序的登陆鉴权，但这些都不用管，小程序·云开发把这些东西都封装好了，开发者直接用就行了。

小程序·云开发技术加持

自 2018 年初，首批微信小程序游戏上线，到现在不到两年的时间内，微信小游戏的生态，已有数十万的开发者，月活高达 4 亿。其中，58%以上是 30 岁以上的用户，31%是 40 岁以上的用户，而之后父母辈将会成为小游戏的主力。

小游戏生态的繁荣来自于过硬的基础能力，从发布初期的原生 Canvas，到现在完成主流引擎的适配，小游戏开发门槛在一步步下降，此外还有硬件接口暴露，分包加载等基础能力，都在不断扩展游戏开发的边界。基于微信的关系链，以及数据运营能力上的完善和基础架构层面云开发提供的便捷服务，整个生态都进入了良性的循环，开发者可以通过这些东西完善自己的小游戏，并且从游戏中获得推广和收益。

那么，为什么要有云开发？众所周知，传统开发模式对于业务开发存在一些痛点难以解决。腾讯云云开发团队前端工程师杨航讲解道，一款生产级别应用的开发，除了业务逻辑以外， 有太多的东西需要处理。为了保证服务的稳定， 需要庞大的周边设施，包括负载、高可用、安全、监控等。在传统模式下，从物理机托管，再到使用云上的服务云主机，最后到 PaaS 级别的服务，随着服务封装层级越来越高，暴露出开发者需要关心的细节就越少，也就释放出更多的人力与投入成本， 但最终仍需要专业的运维人员来介入维护，不但耗费资源，人力的引入也带来错误引入的风险。

除此之外，开发层面上前后端分离虽然是一种优秀的架构，但实际开发过程中前后端分离所带来的权责不清晰，沟通时间增多，代码调试等挑战都使得整个开发进度趋于缓慢。

那么，是否有一种新的开发模式，可以让开发者可以更多地专注业务逻辑。从小程序的技术来看，小程序技术栈主要限制在了 JS，与前端开发相匹配，使用 Node 可以在一定程度上分担后端的业务，降低沟通成本，前后分离得更彻底，解决业务逻辑开发部分的问题。但绝大多数业务开发对于各种复杂周边设施搭建、网络、主机运维相关的知识也是很有限的，想要搞好，就得投入大量的时间精力来建设。

基于这样的想法，腾讯云总结了整个开发流程中普适性广的基础能力，进行更上层的封装，运维部分被完全隐藏掉，暴露函数式调用的接口来直接操作服务，业务开发者完全不感知环境与运维。同时提供代码运行容器解决复杂业务逻辑处理的问题，甚至是让前端程序员可以独自包揽整个项目，推出这种无服务的 Serverless 开发模式。

无服务是未来开发的发展趋势，从物理机到云上的 IaaS 层、主机、PaaS 层的开放架构，一步一步释放了开发者运维相关的东西，让开发者更专注于自己业务能力的开发。而云开发正是 Serverless 应用服务中台。

云函数是 Serverless 的核心，也是云开发功能中很重要的一点。在云函数中，开发者不需要自己写逻辑来获取到小程序的 appid、openid，云开发通过私有协议把其置入云函数的运行上下文，在云函数里可获取，同时在云函数前端进行了鉴权处理，所有到达云函数的请求都是合法登录态的请求，函数中完全不需要鉴权操作了。

其中，云调用就是云函数中很好用的一个功能，如果开发者经常进行小程序开发，需在服务器运行的 API，通过 access_token 来做权限标志。但云调用就屏蔽了这件事情，开发者在云函数中直接调用 Cloud Open API，整个调用链就可以直接顺畅下来了。

实时推送能力落地与实践

随着小程序·云开发的普及，开发者希望云开发能提供通过后台直接往前台推送消息的功能。由于此前没有这个功能，导致开发者需自己去搭 WebSocket 服务，而在搭建的过程中无法保证良好的可靠性和并发性。如果要提供良好的性能，需要的开发成本会很高。

那么，如何在现有云开发能力下进行即时通信能力的开发呢？微信小程序研发工程师邓坤力提出了两个关键词 —— 长连与推送。长连是所有技术通信服务，或者需要依赖于实时性的所有服务的基础。而推送能力，是需要有一个主动同步客户端的能力。此外，存储、消息与文件的持久化也很重要，一是结构化文本的数据，这些文本的数据通常适用数据库存储，对于一些较大的数据，比如图片、音频、视频，这些在聊天中会出现的内容，需要用云存储来承载。

那么，从上述三个即时通信服务的要点来讲，目前用云开发能完成这一整套即时通信的服务吗？一、对于长连来说，云开发并不满足，因为云开发是 Serverless 短连的服务；二、没有主动同步客户端的能力。因此，在这种情况下，大部分的开发者也只能通过短轮询的方式作为长连、推送的替代方案。而短轮询则是每隔一段时间去请求一下数据库，看一下数据库是否有更新，如果有更新，再去更新客户端的意外状态。但短轮询会带来一系列包括资源浪费，维护、开发成本高等问题，甚至在安全性方面，很多开发者还会为了贪图方便会把不宜落在客户端的信息传到客户端使用，比如 access_token 和 session_key。

为此，云开发数据库新增了实时推送更新的能力，实现在小程序端、小游戏端就可以直接对数据发起监听的能力。开发者可以给定查询语句进行监听，每当查询语句的结果发生变化时，小程序端就会收到包含更新内容的推送，并对实时数据变化做出响应。

实时数据推送的场景有很多，包括即时通信、状态同步、实时协作等，在演讲中邓坤力举例说道，对于小游戏开发来讲，状态同步很常见，游戏通常分为状态同步和帧同步。状态同步的游戏，像棋类、牌类，由服务端存储完成状态，像五子棋、象棋等游戏都属于状态同步的类型。再比如，实时协作的场景，在线共享文档、腾讯文档、谷歌文档，以及项目管理的协作工具等，这都是可以通过实时数据推送能完成的事情。

从整体架构上，实时数据推送能力分成了三个模块：小程序的前端 SDK、中间接入层和后台。他们分别承担的业务为：

• 小程序的前端 SDK：这个业务需要在前端做些逻辑去保证服务的可靠性。然后在提供一个简单易用的接口给前端同学用。

• 中间接入层：其任务是与前端保持 WebSocket 长连接，接入层会去后台轮询，取到最新的消息事件后就发送给前端。

• 后台：就是一个比较传统的服务，在这一层监听到最新消息就返回。

为了保证数据的可靠性和完整性，在做模块设计时，小程序·云开发采用互不信任的原则，即上述三个模块之间是互不信任的。为此做了很多的冗余设计，如果系统中的某一模块没有调用成功，小程序·云开发会采取一些措施来弥补这个缺失。比如说小程序的 SDK，它会定期的去接入层查询最新消息事件的版本号，如果查到与本地的版本号对不上，它就会重新拉取一下这个消息事件。这样即使出现数据丢失或者网络连接断掉的异常情况时，依然能保证数据的可靠性。

为了保证低延时，除了在接入层提供 WebSocket 接口以外，后台所有的业务都使用了基于 TARS 框架的 RPC 通信，TARS 是一个成熟的开源框架，其性能很好。

为了处理高并发，小程序·云开发也在持续优化接入层，让其尽可能的维持更多的实时连接。

此外，邓坤力在演讲的最后也介绍了云开发近期推出的其他能力，包括已有的 HTTP API，能打通云开发的资源，在其他端也能直接使用；数据库聚合，普通数据库的能力无法满足的话，开发者可以通过聚合做分组查询、统计查询；数据库的高级查询，这也是控制台的新能力，以前控制台只可以完成简单的数据库操作，加上这个能力之后，开发者可以在控制台中用数据库的语法进行批量的数据增删查改。

多人联机对战玩法的实现

所谓联机游戏，是指玩家与互联网上其他玩家一起玩的游戏。联机游戏的类型有很多，比如《欢乐麻将》《欢乐斗地主》等回合制多人游戏，《贪吃蛇大作战》、《极速大乱斗》、《乱斗英雄》等实时多人游戏，还有火爆一时的社交小游戏《海盗来了》。

小游戏生长于微信、QQ 等社交平台，天然适合拉好友一起玩联机游戏，比如情侣、朋友、团队等玩法。但目前的小游戏大多是单机游戏，原因之一是联机游戏背后的业务和技术逻辑很复杂，开发者要考虑的问题很多。这些联机游戏有什么特征呢？或者有什么技术难点呢？腾讯云高级产品经理张小华分析出以下三点：

• 第一，先把玩家组织起来，因为它是联机游戏，你要在互联网上找到一个跟你一起玩的人，相当于是要有某一种组织把互联网上的人组织在一起，我们把这个组织就称为“房间”。做房间管理比较简单，但做在线匹配，会发现当有很多人发起匹配请求的时候，一台服务器根本撑不住，而想要多大容量的服务器才能做到全区全服，这是一个技术难点。

• 第二，玩家和玩家之间要进行网络通信，这就涉及到很多问题，网络通信是TCP协议，还是UDP协议？开发者花了半年去开发一款联机游戏，结果发现还很卡，联机游戏网络波动、抖动的时候如何让游戏呈现出平滑的效果，这里面的技术很有难度。

• 第三，部署和运维。对战类的游戏，尤其是房间类的游戏，它是有状态的。比如，4个人加入到这个房间，这4个人会同时到一台服务器上战斗，不能分布在多台服务器战斗，如果分布在多台服务器战斗，可能会连接数据库，降低效率。尤其是当很多人频繁操作数据库的时候，数据库的性能可能会出现异常。

对战类游戏并不是很好做，是很困难的，而小游戏联机对战引擎(MGOBE)就将联机游戏背后的技术和运维难点一一解决，开发者只需要调用几个 JS 接口，5 分钟即可实现房间管理、在线匹配、联网对战等功能，无需复杂的后台代码。

很多开发者有疑问，房间管理也好，在线匹配也好，都是调用的 API。如果我有自己的逻辑，要写一些特殊的逻辑，怎么办？小游戏联机对战引擎有一个房间的扩展，开发者每调用房间里的 API，引擎都会触发自定义逻辑的脚本，开发者可以在这个脚本里面写自己的代码。这样的话，一个技术栈就可以完成前后端的能力。甚至包括掉线场景，开发者都可以到自定义服务逻辑中去写，比如，玩家掉线了，你让他对局失败，还是把他剔除房间，这都可以在房间扩展里面去写自己的一些特殊逻辑。

刚才讲的是怎么把玩家组织起来，玩家和玩家之间怎么进行网络通信。这里有三种模式：

一、客户端直接发消息到另外一个客户端，按需发；

二、帧同步

其中，张小华以《王者荣耀》为例，讲解帧同步的原理。在游戏中，客户端会把玩家的动作指令发布给后端，但是后端不会立刻转给其他的客户端，而是按照一定的频率，把所有客户端转给它的消息再同步给各个客户端，每一个客户端就都有其他客户端的逻辑。所以这时候开发起来就会像单机游戏一样，服务端会有一定的渲染，如果用户实时的同步，客户端就会不停的在渲染。像这种定时的客户端，客户端渲染的频率也是固定的，不会很乱，这样的话，就能实现它较高的开发效率。

尽管如此，帧同步还是有一些缺点，网络要求高，防外挂能力比较弱，并且断线重回的时间很长。由于它的帧同步是渲染，如果渲染断线了，会从第一帧渲到当前。如果之前游戏玩了 5 分钟，重新渲染也可能要 5 分钟，当然 mgobe 已经解决这个问题了。另外，因为客户端的服务器，不管是手机也好，电脑也好，里面有浮点数，各个电脑产生的浮点数都是不一样的，这时候按照浮点数渲染出来的结果会导致各个客户端不一样。

三、状态同步

帧同步用的游戏不算多，主要是小战场实时的游戏，大部分游戏用的是状态同步，状态同步的防外挂能力很强，它能胜任大事件、大战场，像吃鸡类游戏。而状态同步，断线重回的时间也很短，因为每一次都保存的是一个状态，网络环境相对轻松，但开发效率相对慢一些，因为在服务端写一遍，可能跟客户端差不多的逻辑。mgobe 支持状态同步，开发者只需要写逻辑，无需关注部署的事情。

结语

据第三方机构报告显示，2019 年小游戏的市场规模或达 250 亿元，其生态也不断成熟。而小程序·云开发将持续丰富 SDK 能力，释放腾讯的技术价值，逐渐支持多种开发语言，让开发更便捷。未来，新的技术层出不穷，但是要知道技术始终是为人服务的。不解决人的问题，技术无法成长壮大。将开发者的精力解放出来，让他们投入到业务逻辑等更具价值的工作中，从根本上赋能技术发展，才是推动行业”车轮“不断向前驶进的源动力。