网页游戏策略养成类游戏排行榜-【Issue 1713】腾讯TGideas@花叔：我的小游戏开发之路

前言

现在很多产品都用小游戏来留住用户。 文末有抽奖。 今日早读文章由腾讯云@汉婷授权分享。 本文来自公众号：云家社区（ID：腾讯云官方开发者社区）。

@花叔，腾讯高级工程师，平台开发组负责人，人称花叔，先后接手腾讯增值业务、架构业务、游戏营销业务，喜欢鼓捣小玩意儿。

正文从这里开始~~

华总从个人学习路径的构建入手，阐述了非游戏开发者如何快速学会微信小游戏的开发，同时带动团队对接小游戏业务。

分享中，华叔用2W1H的方式讲解了他要讲的内容，介绍了小游戏是什么，团队为什么要做小游戏，他是如何学会开发小游戏的。 另外，我也说说自己的感受。

演讲开始前，花叔用手机表演了一个猜数字的魔术游戏。 请了一位女观众说出数字3，华叔把预先盖在桌上的手机翻了过来，屏幕显示出正确的数字。 那是 3，每个人都很惊讶。 花叔说自己用这个神技追上了现在的老婆，然后就开始以2w1h的形式发表演讲了。

第一个W：小游戏是什么？

我觉得有必要说说小游戏是什么？ 在微信上做第三方开发，有两种：

小游戏于2017年1月上线，同年年底微信上线小游戏。 其实这两者都是基于微信的技术框架，具有微信的一些专有技术特性。 那么我们理解的H5和小程序有什么区别：

有很多不同之处，今天我将重点介绍其中三个：

而就在最近，官方发布了一个关系链升级功能，今天简单介绍一下关系链数据在小游戏中的调用逻辑，顺便也说说这次升级带来的影响。

遗留关系链数据调用逻辑

此前，为了保护用户关系链数据，官方会在提供主域的同时，在前端额外提供一个封闭的子域（也称为开放数据域）。 主域会通过 向子域抛出信息 当子域需要暴露关系链的数据时，比如好友排行榜，则通过对主域的封闭来绘制。 子域不可能发送第三方请求。 您游戏中的游戏数据和关系链数据都存储在微信为您定义的托管服务器中。 这是之前的一套，有点绕。 现在这套已经升级了，会发生什么？ 新系列更加扭曲。

新版关系链数据调用逻辑

新的逻辑会提供两个额外的服务器，一个是服务器； 另一个是交互式托管数据服务器，用于存储玩家之间的交互数据。 通过这两个可以达到什么效果呢？ 我做了一个demo，这是我的好友排行榜，我给老婆点赞了，老婆的手机排行榜点赞了。 玩过子域开发的同学都知道，以前是做不到的。

花大爷排行榜和花大爷老婆排行的live demo点赞demo

接下来我简单说一下这里的技术逻辑。 首先是服务器，它的作用是验证用户的数据，同时他可以将数据存储在普通的托管数据中，也就是旧的托管数据集。 在保存的过程中，他可以在新的交互式数据库中再次保存数据。

调用关系链数据是小游戏的特殊能力，先说到这里。

第二个W：为什么要做小游戏？

我们为什么要做小游戏？ 大家做小游戏的目的是什么？ 很多创业团队可能会做小游戏来赚钱，或者构建自己的流量矩阵。 对于我们来说，其实做小游戏并不是为了赚钱。 我们是一个很奇怪的团队，不同于一般的游戏开发团队。 我们过去做的最特别的事情就是开发了一些H5页面，散布在朋友圈或者朋友群里，里面会有一些有趣的互动。 比如吴亦凡这个案子，其实你以为你在看某个新闻的时候，他突然动了，同时说要打电话给你解释。 这会让你觉得有趣，你就会主动传播这个事件，而H5最后的引导是一个叫CF的游戏，目的就是推广这个游戏。 这是我们团队大部分时间所做的事情。

从技术上来说，团队是做互动营销技术的，我们的技术载体是视频和H5。 技术栈是web开发技术，赛道是双平台H5，然后是小游戏。 我们相信游戏也是一种互动形式。

我们在小游戏发布之前就已经开始接触这个领域了。 此时，团队的技术栈已经从原来的一个变成了三个。 我们做小游戏的目的不是为了广告，不是为了内购，不是为了ARPU，我们的目的是为了游戏而做游戏。 对我们来说，我们的指标更重要的是客户端游戏品牌曝光、预约转化、新转化。

因此，当小游戏于 2017 年 12 月首次发布时，我们提供了前 17 款游戏中的 2 款。 游戏。 这两款游戏都是用有利于开发思维的引擎制作的。

刚开始接触游戏领域的时候，觉得挺好玩的，后来做了《红色警戒》小游戏、权力的游戏小游戏、休闲塔楼游戏等策略类游戏。

接下来，游戏越做越大，我们为很多其他的游戏商家做了小游戏：

而这些小游戏最终都会引导用户去预约或者下载客户端游戏，大部分都是为了这个目的。

另一方面，许多案件以前从未做过。 就这样，我带着一群朋友尝试了一个新的领域。 同时还要自己去学习，接下来说说我是怎么学的。 .

最后H：如何学习开发小游戏？

今天分享的另一个主要内容是关于我是如何学习如何开发小游戏的。 可能不会太深入，大家有什么问题可以随时打断我。

我是怎么学的？ 老实说，我是一名重构工程师。 我以前在腾讯很容易被人知道，但在其他公司却不容易被人知道。 至今，我还是属于设计。 我自己是一个设计师，所以我的学习方式很粗糙。

2017年，我创建了一个公众号。 当时小程序就出来了。 一开始只是为了学习小程序，所以做了一个小程序。 这个小程序是一个思维导图工具。 思维导图，如果要在手机上做，会很麻烦，而且其他手机思维导图工具大多是收费的，所以想自己做一个，所以就做了，所以积累了很多微信开发经验。

突然，一个小游戏来了，我想切过去研究一下。 但是这时候，就会出现一个问题：我该如何开始呢？

我很直接，我会先定下一个很致命的目标。 这时候我定下的目标是“一定要一个人做一个游戏”。 至于具体的方法和方法，我会去查的。 然后我开始了，先自己画交互，把元素之类的都画出来。 我自己是设计师，但是我的设计能力不行，所以我选择了手绘风格，灵魂画手的风格。

由于本人是一名重构工程师，对JS有一定的了解，但是之前的思维都是自顶向下的编程思维，对mvvm或者面向对象设计模式研究的不多。 所以我只是选择了一个没有那么多限制的框架来做。 我选择做引擎，因为它没有太多的套件，就像用一个JS库一样。

当时并没有去研究它和其他引擎有什么不同。 定下来了网页游戏策略养成类游戏排行榜，我也是据此学的。 那背景呢？ 当时腾讯云做了一个打包的后端方案（一台业务服务器一台服务器），其实是兼容小游戏的，所以我就直接用了。

然后努力学习，努力尝试，努力制作demo，终于做出了人生第一款游戏。 事实上，这是早期的吃鸡游戏之一。 每淘汰一个玩家，就会有另一个玩家进来。虽然当时我对游戏开发了解不多，但还是给他做了一些特效，比如激光炮，还有AOE效果的技能效果。

你能猜出实时作战计划是什么吗？ 讲个故事，很有趣。 前段时间有个网友，跟你一样，我们都在一个开发组，有一天他突然看到我，他加了一句，灵活地说：“原来你是华叔，我看你的游戏做实时对战，太神奇了，这两年我一直在研究实时战斗的技术，做了很多demo，但我觉得没有你的好。 他拿给我看，我说还不错。然后他问我当时在做什么，怎么做的这么顺利。我说：AI。他目瞪口呆，不知道接下来要做什么。

所以，我是一个初学者，但是我想实现一个类似吃鸡的游戏，可以用不同的方式切。 之前遗漏了一个机器人，一个简单的战斗模式，让它自己跑。 这是一个让我有些触动的小故事。

其实做这个游戏的另一个最大的感受就是：做游戏就像创造一个世界。 像《坦克大战》，里面有剧情，技能有故事说明。 我构思这个故事就像写小说一样。 比如我把风、火、雷五行结合起来，为游戏的技能创造了一些故事。 小游戏本身有一个内置的社区，所以我把这些故事放在那里。

可以说非常享受这个过程，非常开心。 至于代码，就不多说了，我用的是框架。 根据官方文档，稍加修改即可用于小游戏。 具体就是把官方的三个js暴露出来，做一个聚合js，分别引用。

但是当我做完这个游戏之后，我问了我们组一个比较有游戏开发经验的同事，我问他，你觉得我做这个可以吗？ 他说：“你真傻，我们做游戏干嘛干嘛干嘛干嘛干嘛干嘛，每一行代码，每一个按钮，每一个效果都是用代码写的，你不能这么干。”

他说的，我也觉得有道理，因为如果单纯的用它来做的话，很多UI层面的东西都需要一句代码来实现。 所以虽然适合新手玩，但也面临一个问题：以部分程序开发的形式开发游戏太累，怎么办？

所以我努力学习。 恰好那时候我非常迷恋重力感应。 刚好有个设计师朋友有个玩法也符合重力感应的思路。 “小游戏：

它的初衷是基于我小时候玩的纸飞机游戏。 其实主要的技术原理是基于微信小游戏的加速API。 通过这个游戏，我接触到了cocos，发现这个框架非常方便，可以很快的做一个游戏。 因为游戏逻辑不是很复杂，视觉素材全部准备好后，基于cocos，一到两周就可以开发出游戏。

为什么这么快？ 我们看一下技术架构，它做的事情很简单：

总结一下，无非三点：

这个游戏的技术细节我就不多说了，因为我也有一篇文章，大家可以找找，里面会讲游戏的故事。 基于cocos这样的开发包，可以很好的解决开发质量和开发效率的问题。 但随之而来的还有一个问题：传统的服务器后端方案过于复杂。 上面提到的游戏，按照前面的逻辑，我们要搞服务器资源，自己配置服务器。

这个过程涉及前端和后端开发。 对于后端来说，涉及到https部署/域名备案/服务器运维等一系列工作，涉及到很多开发工具。 一个专注于前端的同学感觉很难把图中的所有东西都搞定。 那么，半前端开发工程师如何独立快速的开发游戏呢？

这时，我又做了一个游戏。 这个游戏比较有趣。 我丢了一只猫，不幸去世了。 我做了一个游戏来纪念它。

这个游戏的主要玩法是猫拿着手电筒，手电筒可以投射出影子，你可以将影子实体化来帮助你越过这些障碍。 这个游戏的前端也是基于，但是后端的解决方案和之前的不太一样，它是基于一个新的东西——小程序云。

小程序云提供的技术框架非常简单。 上半部分是小程序云的主要逻辑，下半部分是小游戏的前端。 整个过程只需要前端开发的相关知识，只需要用JS开发，很少使用开发工具。 下面就小程序云解决的问题做一下说明：

在游戏开发环节中，有一个并行的前端开发和后端开发的子流程。 小程序云就是让前端开发同学直接做子流程。 主要提供三个trick和两个。 提供数据库、存储、云功能等后台基础功能：

两个包指的是：鉴权和云调用。

一方面，基于服务器开发的小游戏登录认证非常麻烦。 需要结果图左侧的构建逻辑，对前后端开发能力有很高的要求。 如果是基于小程序云，这个机制直接封装在云函数中，前端开发同学可以做登录认证。

另一方面，对于微信提供给小程序的一些http接口，按照以往的做法，我们需要根据appid和 key来构造鉴权。 这个过程有点繁琐（如图右半部分），还需要定义一个缓存机制，对于没有后端开发经验的前端开发人员来说还是有点难度。 而小程序云将这些东西封装成一种机制，叫做“云调用”，你只要稍加配置就可以直接使用。

基于小程序云和cocos，连续做了9个游戏demo，其中5个是用云做的。 以上从一个比较浅的层面，对我做的游戏和遇到的问题进行了说明。 可能就不解释太深了。 有什么问题可以线下找我，再讨论一些更详细的技术点。

魔法的秘密

今天其实要带来一个我个人觉得比较有意思的话题，那就是我最近对线下游戏的思考。 首先，让我们在一开始就揭开魔法的秘密。 有同学想过这是什么原因吗？ 有人认为是语音，有人认为是AI，其实不是。 其实，我刚才的发言已经揭晓了答案。

是的，原理和《太空重力》这个游戏一样，都是基于重力加速度或者陀螺仪的API。 一部手机只有4个方向，这也是为什么我要让美女猜出4个数字中的一个。

其实这种魔幻游戏，或者说这种线下互动，其实和真实的商业场景结合是非常有限的。 可能只适合现在的分享场合，或者追美女的时候用，所以要结合商业场景想一想，什么样的游戏（交互）才算合格？ 好的线下游戏（交互）=合适的技术+合适的场景。

要做一个好的线下游戏或者交互，有两点需要配合：

相关案例

基于以上思路，我们做了一些案例：

1、案例一：触摸屏技术

2017年，我们与腾讯互娱合作了一个大型会展项目——TGC。 每次这个展览都会给玩家提供一些技术驱动的创意体验，在前期规划他的技术创意的时候，我们发现有一个技术可能可以发挥一些作用，那就是触屏技术。

其实每个人的手机都是多点触控的。 您可以用一根手指、两根手指或三根手指进行交互。 手机最多可以触摸五六个触点，甚至更多。 我们知道这件事情后，有点分歧，其实是觉得可以在手机上盖章。

与此同时，我们还发现了另一部动漫——《猎人×猎人》，其中有一座贪婪之岛。 剧情是让玩家在一个封闭的小岛上玩纸牌游戏。 这个场景是否可以在我们的展览活动中重复使用？ 羊毛布？ 所以我们开始计划，后来我们终于做到了。

2.案例2：+小程序

这次也是TGC，2019年在成都环球中心举办，会场开张了网页游戏策略养成类游戏排行榜，现场人挺多的。 我们发现有一种技术叫，这是一种室内定位技术，小程序也支持。

基于+小程序，我们可以为玩家提供定点拍照的方式，在不同地点拍照后可以获得奖励。 在这种方案下，硬件部署成本很低（因为每台设备成本不到100元，需要的设备数量也不算多），用户参与活动的参与度也很高。 这是第二起景区人流案件。 事实上，我们做过很多类似的项目。

在经历了上面的一些案例之后，我们已经证明了基于现有的技术支持能力，我们可以实现大型沉浸式互动游戏。

从前端的角度来看，很多硬件层面的东西都是支持的。 比如开源/第三方硬件有接口，可以使用； 再比如微信赋予的硬件能力，比如陀螺仪、加速。 而且最近流行AR的基础能力（小程序中的组件可以获取实时数据，为AR提供基础支持）。 这些想象的空间很大，我就不细说了。

从后端来看，云端也为我们提供了很多能力，比如基础存储，CRT、图形识别等远程AI接口，以及能力的封装。 基于这些，线下游戏可以玩出更多花样。

3. 案例三：大屏交互

这个case也是我们做的，在我看来是线下游戏中最好的case。 这是我们庞大的团队为龙之谷制作的离线游戏。 玩家通过小程序扫描二维码激活共享单车，利用共享单车与大屏互动，实现一起打怪的游戏。

自我意识

谈谈我的感悟吧。 来的时候看到门口的易拉宝上写着cloud+xx。 后面的两个字是什么？ 社区？ 如果我没记错的话，cloud+后面应该是“创业”二字，和我今天上一个主题有点相似。 我不想表达我想创业。 而是表达一种多年来的感悟。

无论身处何地，我们都要以创业的态度做每一件事。 我制作了一款游戏，我将以一种创造性和发明的态度将它推出市场。 所以从过去到现在，我带领的团队都是先挖掘技术，设想场景，制作demo，最后用技术+场景demo，在需求端推动新的产品形态。 我们一直认为自己是在创造产品，而不是流水线。 我们一直这样做。

老师您好，您以后会帮助开发者减少流程吗？

问题这么长，我给你总结一下：

第一，个体开发者。 据我所知，个人开发者应该无法进行应用内购买。 如果个人开发者不能进行应用内购买，那么你刚才提到的问题（其他资质难以申请的问题）就不存在了。

其次，柔软并没有你想象的那么难。 个人开发一个软件，我不只是说这是个小游戏，其他软件也一样，都需要软，只是软申请难度不是很大，没有你想象的那么麻烦，其实就是版权问题保护中心官方有教程，提交代码，填一些表格，做一些使用说明书就可以了。

至于你说的微信点评，腾讯各个部门都有分工。 我是在游戏市场工作的同学，所以关于复习攻略的问题我很难回答。

关于这篇文章

九软件 版权声明：以上发布的内容及图片均来源于网络，如有无意侵犯到您的权利，请联系我们及时删除！