文章还提到了两种与热有关的姿势。 首先是社交匹配。 在小游戏去中心化的背景下，将游戏内容与微信社交结合起来非常重要。 同时，开发者还需要利用社交来提升用户体验和群聊分享。 在造成用户骚扰和不要太过分之间选择一个平衡点。 其次是操作的便捷性，指的是游戏简单易用、易于操作。 这是我们在游戏火爆后根据观察得出的结论。 并不意味着具备这两个特征就一定能开发出一款热门游戏，新的爆款游戏也不一定符合这两个特征。 仅供参考。 。
如何快速开发一款热门小游戏？ “热”是一个注重运营的词。 小游戏上线120天后，“微信开发者”公众号上有一条推文。 里面有几个数字3D素材，可以用来形容“热”字。 距离微信小游戏正式获准第三方开发商发布已经过去了22天。 向外界发布的小游戏超过300款。 总注册用户数过亿的游戏有好几款，月收入过千万的Android游戏也有好几款。
文章还提到了两种与热有关的姿势。 首先是社交匹配。 在小游戏去中心化的背景下，将游戏内容与微信社交结合起来非常重要。 同时如何开发一个游戏，开发者还需要利用社交来提升用户体验和群聊分享。 在造成用户骚扰和不要太过分之间选择一个平衡点。 其次是操作的便捷性，指的是游戏简单易用、易于操作。 这是我们在游戏火爆后根据观察得出的结论。 并不意味着具备这两个特征就一定能开发出一款热门游戏，新的爆款游戏也不一定符合这两个特征。 仅供参考。 。
今天介绍的内容技术性比较强，所以标题中去掉了“热门”，并且不会介绍如何开发具体的游戏逻辑。 而是会更加关注如何利用好微信的开放能力来开发一款小游戏。 。
什么是“小游戏”？ 小游戏是什么？
首先给大家介绍一下什么是小游戏。 从普通用户的角度来看，小游戏是小程序的一个子类别，可以在微信内轻松获取和传播。 只需单击一下即可玩它们，并提供出色的用户体验。 小游戏是小程序，普通用户无法区分，也不需要区分。
小游戏运行时
如果放大小游戏的运行时间，你可以看到很多细节。 这是一个典型的分层架构：
上方蓝色部分是游戏代码，分为三个部分：游戏逻辑、游戏引擎、weapp-adapter。 大多数游戏开发都会使用一些引擎工具、工作流程以及引擎封装的高级API来实现游戏逻辑。 其次是weapp-adapter，因为一方面，小游戏的底层并不是webview，而可以简单地看成是webview的一个精简优化的平台； 另一方面，核心能力的实现参考了webview。 所以如果这里有一个适配器，将小游戏的底层API——wxAPI适配成接近webview的接口，那么上层引擎和现有游戏接入微信小游戏平台就会更容易。 这就是weapp-adapter效果。 其中只需要游戏逻辑。
可见，小游戏和小程序在架构上是有区别的。 小游戏没有页面概念，wxss/wxml已经不存在了。 其次，底层实现不是webview。 小游戏和webview的关系只能说是渲染相关的核心能力可以通过weapp-adapter的简单适配来保持界面一致，但同时webview上已有的很多功能并没有等价实现。 例如，小游戏没有 DOM/BOM 的概念，也没有全局的 document/window 对象。
小游戏的入口是gamejs文件，语言是Javascript。 但存在一些限制如何开发一个游戏，例如禁止执行动态代码，因此不支持 eval 和 newFunction 等功能。 配置为game.json，可以配置横竖屏、界面超时等参数。 wxAPI的能力可以在js中结合起来实现游戏逻辑。 非代码资源应尽可能放在CDN上，以减少打包后整个代码包的大小，以加快用户的首次进入速度。 微信目前限制首包大小为4MB。
Webview适配器
我们来谈谈WebviewAdapter。 它的初衷是为了让游戏开发者更加熟悉我们的平台，所以我们的平台在能力上会尽量去适配webview。 其实这个适配也很简单。 层。 例如，我们在浏览器中使用image对象创建图像，但在小游戏中是通过wx.createimage创建的。 需要在代码中进行简单的调整。
以此类推，常见的Canvas和文档对象都是通过Adapter中的简单适配来实现的。 您可以研究链接中的代码。 未来官方不会继续维护这个Adapter，我们会更加专注于底层能力的建设。
小游戏功能概述
下图是小游戏功能的概述。 小游戏能力迭代相对较快，部分能力尚未上市。 比如最近发布了一些游戏圈防沉迷、健康系统相关的接口。
我们先来看看基本能力。 渲染部分，同时支持WebGL1.0和Canvas2D。 这里的Canvas更接近浏览器中的标准。 同时，这里提到的可控帧率的概念是指如果小游戏在后台运行，则可以尽可能降低帧率。
在多媒体部分，小游戏还无法像小程序一样实现实时音视频流，未来我们会进一步支持。 网络IO部分与小程序类似。 我们还提供了一些UI组件，比如拉起键盘、模式对话框等。
小游戏的社交开放能力现已对外开放。 其中最重要的能力之一就是在开放域中开放微信好友关系供开发者使用。 考虑到保护用户隐私，会有一些设计限制。
由于小游戏的去中心化特性，这部分的共享也非常重要。 开发者必须考虑如何利用这个能力。 代码方面，由于首包限制为4MB，一些小游戏的代码量可能会比较大。 我们最近还计划提供一个分包功能，允许异步加载和执行代码，但这些代码必须经过我们的审查。
如何开发一款小游戏？
那么如何开发一款小游戏呢？ 因为我自己只开发过一些简单的游戏，对于游戏开发并不专业，所以接下来我会详细介绍一下如何利用微信的能力来开发小游戏。
选择迷你游戏引擎
微信也与引擎厂商有比较密切的合作。 一般来说，当前的游戏引擎都会支持发布到多个平台。 针对微信小游戏新平台，已经适配了一些引擎，如CocosCreator、EgretEngine、LayAirEngine等。 适配的主要工作和之前提到的weapp-adapter类似，将wxAPI的能力连接到引擎上。
例如，引擎通常会将小游戏平台与webview平台进行对标。 适配的过程就是将wxAPI映射到webview能力上，同时去掉只存在于webview能力上的依赖，比如不再依赖BOM和DOM。 适配引擎有相应的文章介绍如何将游戏发布到微信小游戏平台。
设备/环境适应
小游戏都会有API提供获取屏幕宽高、设备像素比等的能力。小游戏开发完成后，还可以在开发者中发起真机测试的请求工具。 微信针对不同设备提供了测试集群，帮助开发者提前发现问题。 基础库本身提供的wxAPI是一个不断迭代更新的过程。 对于使用新能力的小游戏，需要实现低版本兼容。
微信登录
小游戏的登录流程与小程序类似。 用户需要自行定义登录状态。 appsecret/session_key代表小游戏开发者与微信平台之间的信任协议，例如托管数据的支付、上报等。 平台需要验证access_token（只能交换appsecret），用户相关的也需要验证session_key。 签名可以确保请求来自小游戏开发者/用户，而不是恶意第三方或随机捏造的用户。
access_token是应用状态的access_token，与用户无关。 它需要确保在全球范围内维护一份副本。 应该有一个中央控制模块来保证access_token有效。 同时材质材料，本地缓存的access_token在有效期内直接使用，而不是每次使用都去。 生成新的access_token，否则可能会遇到调用频率限制错误，影响服务。 切记不要将appsecret/session_key放在前端代码中，否则可能会被不法分子利用，损害小游戏开发者/用户的权益。
缓存
缓存类型包括数据缓存和文件缓存。 数据缓存为key-value存储，适合结构化小数据存储，上限为10MB。 文件缓存提供了完整的文件系统API，包括目录/文件的添加、删除、修改和读取。 适用于频繁使用的网络资源的本地缓存，上限为50MB。
与浏览器不同，微信只提供基本的存储管理能力，不会对存储内容或存储满时删除内容进行任何操作。 开发者可以灵活地自行定义缓存和淘汰策略，例如将经常访问的资源存储在文件系统中，并在文件存储满时清除一些最近访问的文件。
开放数据域
开放数据域是一个封闭的、独立的 JavaScript 范围，与游戏逻辑执行的环境隔离——称为“主域”。 目的是向第三方开放用户数据，同时保证用户隐私，提高小游戏的整体用户体验。 下面是实物图。 主域的入口是game.js。 开放数据域是一个独立的目录，入口文件为index.js。
主域与开放数据域之间的通信受到严格控制，基本原则是只进不“出”。
?Only：允许外部数据进入开放数据域，即主域可以随时向开放域post消息，开放域可以引用主域准备的本地资源
?不“出”：开放数据域的数据不允许上传到第三方服务器。 因为在开放数据领域，index.js可以直接访问敏感的用户数据，比如玩好友的数据。 当然，数据域的最终开放需要index.js将各种数据整合后以图形图像的形式渲染到sharedCanvas上。 主题sharedCanvas允许绘制到主域的上屏幕Canvas，最终用户将在显示器上看到它。 game.js绘制的好友排名、群组排名、好友超越等社交互动信息。
对于开发数据域中的数据，开发者无法将其取出并与游戏数据关联起来。 因此，如果需要在开放域展示分数等游戏数据，开发者需要通过上报接口将数据上报给游戏数据。 托管到平台。 这样就可以在开发数据域中获取相关数据。 其应用场景包括好友排名、群组排名、超越好友提示等。
文章来源:https://zhidao.baidu.com/question/992758572156876979.html
