内容简介:这其实是一篇个人的2018年度总结。整个2018年我基本都投身到小游戏的开发制作当中,游戏先后上线了上述的三个平台分别对应微信平台,QQ空间平台,手Q平台,对于详细介绍这里就不累述了,相信网上的很多文章肯定比我介绍的好。
这其实是一篇个人的2018年度总结。
整个2018年我基本都投身到小游戏的开发制作当中,游戏先后上线了 微信小游戏 , QQ空间小游戏 ,同时预开发了 厘米游戏 版本。所以这篇总结我会站在开发的角度谈一谈在这三个平台开发的经验,以及趟过的坑。
上述的三个平台分别对应微信平台,QQ空间平台,手Q平台,对于详细介绍这里就不累述了,相信网上的很多文章肯定比我介绍的好。
小游戏C/S连接
这里谈的是客户端与开发者(自建)服务器的网络连接,三个平台都可以采用WSS连接方式,即在TLS之上的Websocket。
所以整个接入层方案可以做成统一的,具体实现可以采用:Nginx作Https解析代理,然后转发Websocket到自定义的接入服务。
优点是:
- 不用重新造WSS解析的轮子;
- Nginx可以方便的对域名、证书进行管理,并支持热加载和负载均衡;
缺点是:
- 对于延迟敏感的游戏有一定影响,毕竟网络包多传递了两次;
客户端资源存放
小游戏的客户端包一般分为二部分:一部分是编译后的打包包体(主要是代码逻辑、部分配置)、另外一部分就是各种素材资源(UI、动画、配置等)。
三个平台对资源的管理方案如下:
打包资源 | 素材资源 | |
微信小游戏 | 上传平台 | 自建CDN |
QQ空间小游戏 | 自建CDN | 自建CDN |
厘米游戏 | 上传平台 | 自建CDN |
QQ空间小游戏比较特别,所有资源都是自己管理,担心页面并发大服务器撑不住可以采用CDN+COS(腾讯云COS、阿里云OSS)静态网站的方式,让用户直接通过CDN访问你的游戏,将页面负载的压力交给第三方。微信小游戏和厘米游戏则不用担心这个问题,平台都帮你处理好了。
微信小游戏有8M上传包的限制,厘米游戏是10M。如果你的游戏比较大、资源比较多,那么8/10M肯定是不够用的,可以把资源放入CDN。
小游戏登录鉴权
- 微信小游戏鉴权(Api:code2Session)是根据客户端code码,传递到服务端,服务端根据code和其他信息换取open_id与session_key,若能成功换回则登录有效;
- QQ空间小游戏(Api:/v3/user/is_login)和厘米游戏(Api:apollo_verify_openid_openkey)是客户端直接持有open_id,open_key,服务端去验证是否登录;
注意点:
微信小游戏的code码有效期,官方给的说明是:属性code,用户登录凭证(有效期五分钟)。开发者需要在开发者服务器后台调用 code2Session,使用 code 换取 openid 和 session_key 等信息。
在实际使用中,如果每次登录/重连,客户端都获取新的code,服务端调用code2Session会有小概率失败(无效的code)。失败流程都是走官方登录文档流程:客户端获取code,服务端校验,并且参数传递正确,至于为何出错失败官方未给出有意义的提示。
那么怎么解决?
微信小游戏还提供了一个接口checkSessionKey(客户端和服务端都有,但是在登录文档里未提及)
官方说明是:校验服务器所保存的登录态 session_key 是否合法。为了保持 session_key 私密性,接口不明文传输 session_key,而是通过校验登录态签名完成。
我们可以利用这个接口进行容错检查:
这里对code进行了double check, 主要是因为在客户端checkSession通过后,服务端仍有小概率会失败 ,所以为了进一步容错,右侧图多加了一个客户端过期更新流程。
小游戏核心逻辑
社交关系与排行
三个平台社交关系实现如下:
平台支持 | 数据上报 | 数据拉取 | |
微信小游戏 | 是 | 客户端 | 客户端 |
QQ空间小游戏 | 是 | 服务器 | 服务器 |
厘米游戏 | 是 | 客户端 | 客户端 |
值得注意的是微信小游戏有 开放数据域 的概念,这个域和主游戏完全隔离,意思就是里面的数据不可能对其取出二次加工。
每个平台对社交榜单的种类有限制,如果需要世界榜,需要开发者服务器自行支持。
支付
三个平台支付方式相似,都是通过客户端拉起支付界面进行RMB支付换取游戏币。
不同的是,我以游戏中钻石(游戏币)为例:
- 微信小游戏和厘米游戏平台支持托管钻石数据;QQ空间小游戏托管的是星币/秀币(全局性游戏代币,在其平台上的每个游戏通用),开发者需要用自己的逻辑把星币/秀币再换成钻石。
- 微信小游戏和厘米游戏有接口支持支付回滚; QQ空间小游戏不支持支付回滚: 星币/秀币一旦换成钻石,这个就是不可逆的,这点需要特别注意。
微信的getAccessToken
access_token是微信特有的一个变量:
官方说明是:获取小程序全局唯一后台接口调用凭据(access_token)。 调调用绝大多数后台接口时都需使用 access_token,开发者需要进行妥善保存。
它会引发二个问题:
- 游戏开发一般会分为开发/测试环境,正式环境;不同环境间怎么共享一个access_token?
-
access_token出问题怎么办,过期?平台侧异常?
首先解决第一个问题: 需要一个全局拉取access_token的模块 ,由正式环境负责与微信接口服务交互,拉取成功后落日志,开发/测试环境通过脚本把日志拉取到本地读取有效信息。模块功能与微信接口交互还是读取文件可以通过环境配置来实现。其他需要使用access_token的模块可以定期(30秒)去向全局拉取access_token模块同步一次access_token。
第二个问题比较麻烦,现在微信接口返回的expire_in=7200秒。在开始的使用中我们平均1小时主动刷新一次,但是发现偶尔会“提前过期”,于是乎把更新时间缩短到了15分钟,发现还是会偶尔“提前过期”。自身确认过逻辑,找不到原因(没有其他地方调用过接口导致提前过期),在社区寻求帮助也没有有效回复。 所以这里加了一层容错:在微信接口返回过期提示时,主动告诉全局拉取access_token模块触发更新,能够做到微信那边出了异常也能自动的进行容错。
当然这里做的好一点可以再加一个下发机制:由全局拉取access_token模块下发最新的access_token。
总结
总的来说三个平台对小游戏的接入大体相同,细节不同:
- 从微信小游戏来看,他们更注重用户数据的保护,利用开放数据域保护用户和社交的私有数据,游戏作弊成本会比较高;
- QQ空间小游戏则有些类似传统页游的做法,客户端不可信,绝大部分用户和社交信息通过开发者服务器拉取,支持PC web端直接访问,游戏作弊成本比较低;
- 厘米游戏则有点像微信小游戏和QQ空间小游戏的结合,一些地方像微信做法,一些地方像QQ空间的做法;
因为平台历史、文化、产品/技术侧重点等原因导致平台间存在差异,我们不好说孰好孰坏,比如微信小游戏更注重隐私,数据安全和程序安全,会限制开发方的部分想法;QQ空间小游戏则比较粗放,社交好友的数据你都可以直接取到,任意进行二次加工,对开发方想法限制会较少。
所以一切都是权衡,不仅仅体现在程序开发上经典思想 – 空间换时间,也体现在产品/平台属性 – 自由度与隐私的权衡,更体现在生活 – 过年怎么探亲访友:D。
最后,祝2019一切安好。
(全文结束)
转载文章请注明出处: 漫漫路 - lanindex.com
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。