2018年小游戏开发总结

这其实是一篇个人的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,开发者需要进行妥善保存。

它会引发二个问题:

  1. 游戏开发一般会分为开发/测试环境,正式环境;不同环境间怎么共享一个access_token?
  2. 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

Leave a Comment

Your email address will not be published.