H5游戏开发的架构总结(一) 客户端

【客户端】
1.关于游戏引擎
在15年3月开始准备做h5游戏的时候,首先遇到的问题就是引擎选型的问题。
当时市面上的2d引擎主要有3个:白鹭egret,layabox和cocos2d-js。
一方面,是因为我以前用cocos2d-x(c++)做了一年多的手游客户端,所以,很自然就选择了cocos2d-js。另一方面,是因为当时市面上其他两个引擎的成功项目还不多。
cocos引擎的每一次版本更新,我们都会第一时间在我们的游戏里面进行测试。
如果发现游戏在android手机上的性能有明显提升,我们就会跟着引擎版本一起升级。站在巨人的肩膀上,我们可以事半功倍。
从15年3月的v3.5,到15年9月的v3.8,到15年11月的v3.9,直到最近16年7月的v3.12。我们一共更新了3次游戏引擎!
PS:js-tests里面的OpenGl Test直到v3.12才在android真机上能看到运行效果,泪流满面!


2.关于数据加密和通信协议
因为是强联网游戏,所以只能是websocket。因为我们原来的手游客户端和服务器之前是tcpsocket,传输的内容是sha1加密过的自定义格式的二进制数据。
所以项目的第一个难点就是怎么用js实现json字符串的二进制编码和解码,以及sha1加密和解密。
TODO:其实没有必要每一条上下行都加密和编码解码,这会造成客户端和服务器端cpu压力过大。只需要保护一些重要的事件(如登录、充值、扣金币等)即可!


游戏的第一个demo做好了,上线一测试,问题来了:有些android手机的默认浏览器根本不支持websocket!
最开始我的解决办法比较简单粗暴,不支持就弹提示:"你的手机浏览器不支持websocket,请换chrome浏览器!"
市场表示接受不了:真实玩家都跑了!除了公司的测试人员,谁都不会为了玩一个h5游戏还去专门下载一个浏览器!更何况除了浏览器,还有微信和qq,怎么破?
最终的解决办法,就是通信层从websocket改成websocket+http双协议,对外封装成Net。业务层对websocket的调用都改成对Net的调用。
Net默认连websocket,如果不支持,就自动切换到http长轮询。不管是websocket还是http,传输的内容还是之前加密过的二进制数据。
虽然http的长轮询在实时战斗的时候,会有卡顿,但是聊胜于无,至少这部分玩家能进到游戏里面,可以玩单机副本,和其他系统。不会因为不支持websocket而进不来!
根据我们的数据分析统计,这部分玩家居然有10%。可能不同渠道导入的用户,这个值会有不同!而且随着时间的推移,这个比例应该越来越少!
PS:不支持websocket的android手机,跟IE6一样令人讨厌,都是阻碍生产力发展的,必将被历史淘汰!

3.关于android和微信
中国的市场现状就是,H5游戏必须考虑android手机,必须考虑微信和qq这两个传播渠道。只关注用pc浏览器开发和苹果手机测试没问题,是不明智的,也是对公司的不负责任。
开发的时候可以用pc浏览器调试,但是发布之前必须在android手机的微信里面,打开游戏看是否有兼容性问题,同时确认流畅度。
如果pc和苹果手机都能跑到50~60帧,但是android的微信就只有10多帧,那就必须在图片尺寸和动画效果等方面做取舍。
我们的标准是保证游戏在android中端机的微信里面打开,最低25帧。
今年4月份微信的浏览器内核自动从webkit升级成Blink,这是对H5整个行业的重大利好!
窃以为,白鹭、layabox和cocos2d,包括unity,虚幻,这几个游戏引擎之争,现在来看,都是在争VR和3D,但是最终是看谁对奇葩辈出的android的全覆盖支持最好,谁就能最终占领中国乃至全球市场!


4.关于音乐和音效播放
cocos2d-js引擎自带的CocosDension有bug,不能同时播放一个以上的音乐。而且在中低端的android的微信里面,声音品质会变差(像破锣一样发呲)
我们的解决方案就是引入第三方的howler.js


5.关于资源分场景加载
cocos2d-js默认的resource.js里面,所有资源都是在一个数组里面,所以预加载的时候必须全部都加载完了才能进游戏!刚开始开发的时候,这样没有问题。
但是到了后期,随着系统的增加,资源文件也越来越多,对第一次玩游戏的玩家来说,因为浏览器没有缓冲,需要全部加载,在wifi环境都需要等待1分钟以上,这会导致大量的新玩家流失!
我们的解决办法是,分场景加载资源。在resource.js里面,将资源按场景分成N个数组,每次加载某个场景的时候,只预加载对应数组里面的资源。


6.关于json文件压缩
随着游戏开发的进行,场景越来越多,ccs生成的json文件也越来越多,同时各种地图、商品、道具、奖励等数据的完善,对应的json文件内容越来越多,文件大小越来越大!
最后游戏发布的时候,发现居然有70个场景json文件,合计1.3M。有27个配置json文件,合计755K。等待这几十个文件加载的时间可不短!
解决办法,引入第三方的jszip,可以将多个json文件合并成一个zip,文件大小只有原来的8%。

写了个python脚本,把ccs和configs两个目录下的json文件先转成一个一行,再用jszip打包成2个zip文件,游戏一开始先用jszip加载这两个zip,解压的json放到全局数组里面。

注意这里面有个坑,策划的excel里面不能出现半角逗号,否则jszip打包会报错。强制策划不输入半角逗号不太合理,解决办法是go生成json的时候替换半角逗号为全角逗号。

然后复写了引擎的cc.loader.loadJson这个函数,对打包的json文件特殊处理(不用额外发起http请求,直接从全局数组里面拿)
有了5、6这两步的优化,现在新手在第一次Loading页只需要等待4秒就能进入游戏。




7.关于混淆
cocos封装了google的混淆编译脚本,但是这里面有个坑:就是加了--advance参数之后,所有变量名都会被混淆,包括object的内部函数名称和变量。

解决办法就是在你不想混淆的函数或者变量(object{}对外暴露的public函数和变量 以及 引用的第三方库的函数 )前面加上一行:

/** @expose */

注意:千万不要xxx.yyy 和 xxx['yyy'] 混着用!否则加/** @expose */也没用,必须全部统一成其中一种写法!



8.关于上线发布流程和cdn缓存
1)本地运行publish.sh:本地混淆编译,本地测试publish/html5/index.html是否正常
2)本地运行oline_t1.sh:根据当前时间生成版本号,publish/html5目录下的res和game.min.js和index.html里面的相对路径都改成http://cdn域名/版本号的文件地址,
  将res和game.min.js加上版本号之后,上传cdn服务器。更新测试服t1的index.html,通知测试!
3)本地运行online_s1.sh:更新正式服s1上的index.html。发布完毕。


说明:
1)客户端和服务器端程序员都是mac开发环境,每人的机子上都有一套完整的前后端游戏环境。本地开发,本地调试,没有问题之后通过git提交代码到公司内网git服务器。这样可以最大限度保证多人协作的同时,互不影响开发进度!
2)因为cdn加了时间版本号,所以每一次的发布都是马上生效,不需要等缓存过期。也不担心多人各自发布覆盖对方的代码。发步完马上可以查看效果,大大提高生产效率。以cdn的空间换效率,非常划算!

3)python的fab包是个好东西,可以远程登录服务器执行shell命令,实现本地一键发布。不需要在服务器上通过git的钩子来实现自动发布!


9.关于断线重连(websocket)
1)客户端每隔58秒有一个心跳上行,保持与服务器的链接
2)多标签的浏览器在切换tab或者浏览器进入后台的时候或者断网,都会导致心跳失效
3)每次客户端发送上行的时候,先判断Net.isConnect()是否为true。如果false就先保存上行事件和数据,然后重连,然后重新登录,然后发送保存的上行事件和数据。这些都是在后台进行,如果重连失败则弹出提示,点击确认之后刷新页面。

10.关于运营商的域名劫持和移动端js加弹出广告
运营商耍流氓,中国又是一个"法制"国家,除了上https,没有别的办法!
我们选择的是沃通的超安SSL,单域一年4888元 http://www.wosign.com/price.htm


11.关于客户端AI

碰碰车只实现了简单AI,就是在单机比赛场里:
1)NPC碰到障碍物之后会固定角度转向,避免卡死在角落。其他时间会随机转向。
2) 自动添加NPC,保证房间内NPC的最低数量
3)同一时刻只有一个NPC处于追踪玩家状态,有定时器触发追踪者的选角切换

H5游戏开发的架构总结(二) 服务器端


你可能感兴趣的:(Cocos2d-js)