【游戏编程板块】关于游戏开发的客户端/服务器端的版本控制

写了个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处于追踪玩家状态，有定时器触发追踪者的选角切换

服务器端】 1.关于Go语言 我们的H5游戏服务器框架是用Go语言开发的。以前做页游的时候是用的php和Python，都是动态语言。在上线之后，高并发的时候，单机有性能问题，一直没有好的解决办法！ 13年的时候我原来的领导开始转用Go来开发手游的服务器端，所以我也跟着转型了！ 正如七牛的许世伟所说，用go开发，是可以降低程序员心智负担的！静态编译的优点不用赘述，语言简洁，开发效率高，特别是goroutine和chanel两大神器，专治各种疑难杂症。 Go语言这两年的发展非常迅猛，特别是在中国的很多重量级互联网公司得到大量运用。 而且语言本身已经发展到1.6版本，GC时间从原来饱受诟病的几秒下降到了1毫秒，除非是对延迟要求非常苛刻的应用场景，绝大部分的应用场景都能hold住！ 2.关于通讯协议 我们这套框架，最开始是手游的游戏服务器。所以只支持tcp socket。 后来转H5之后，又加入了对websocket协议的支持，两者放在一起，做了封装。 后来为了兼容不支持websocket协议的Android手机，又加入了对http协议的支持，因为http属于应用层协议，tcp是传输层协议，没法简单的封装在一起，所以就写了两套。 但是发送和接受的内容都是一样的：加密之后的自定义格式的二进制数据。 3.关于缓存和数据库 我们的数据库用的是MySQL，缓存同时支持memcache和redis。 在业务层和数据库之间，封装了一层k-v的cache，可以通过配置分别使用memcache或者redis。 每张数据表都有自增长的id主键，并且有一个类似Java bean的struct与之相对应. 针对单表的sql操作，根据类型不同有不同的处理机制： 1)select操作就根据id去缓存里面取值，没有就查mysql，然后缓存结果. 2)update/insert/delete操作，就直接操作mysql，同时删除对应缓存. 如果是对多表的联合查询，一般都是直接走sql，不走缓存。 这样就可以在高并发的时候，减轻数据库的访问压力。 目前是只用到一个主库。后期压力上来可以改成1主多从。 4.关于单元测试 Go语言对单元测试的原生支持，让测试驱动开发成为一种本能！ 但是单元测试也有不同的重量级，有的功能需要依赖项目启动时读取的配置文件，有的功能还需要玩家的特殊状态。 再加上多人协作开发的时候，需要控制每个人的私有单元测试边界和公用的单元测试范围，免得互相影响，因为引入不必要的测试而导致测试总时长增加！ 在项目开始的时候，强调单元测试的重要性，并做好整个项目的单元测试的组织规划和部署，非常重要，可以事半功倍，节省大量后期测试和纠错的时间！ 5.关于excel工具链 策划的数值表都是excel，我们用go写了个转换工具可以通过命令行把指定的excel转成服务器端需要的json格式文件。 其中有些json文件的内容是客户端需要的，于是又用python写了个转换脚本，提取和组合服务器端的json文件内容，生成客户端需要的json格式文件。 有了这两个工具，就可以实现自动化部署，方便测试在单独的数据测试服上调数据！ 6.关于服务器端AI 碰碰车的联网比赛场里的AI行为比客户端复杂，策划在AI行为数据表里进行配置，转成json，在比赛场里根据AI配置文件控制NPC的行为。 将计算之后的NPC的位置和角度等状态发送给客户端，客户端只负责呈现！ 7.关于联网纠偏 碰碰车的联网比赛，服务器端在房间里会模拟客户端的帧update事件，更新频率在80毫秒一次。 每次update的时候都需要计算房间内所有agent的位置，进行碰撞检测，以及其他逻辑。并把更新后的信息，通过纠偏事件下行给所有玩家。 这个更新频率太短和太长都不好。太短会造成服务器和客户端CPU压力太大和网络流量的增加，太长会造成客户端收到的位置和自身计算的位置差距太大， 如果不做线性补偿，直接以服务器端为准进行更新，会有跳跃感。 8.关于微服务和全球统一服 我们一开始做这套游戏框架的目标就是支持高并发的全球统一服。 单机的性能再怎么优化都有天花板，微服务和容器云是目前互联公司应对类似需求场景的通用解决方案！ 按计划分三步走： 第一步：单块系统，通过命令行来打包和发布。目前已在线上运行！ 第二步：通过Docker创建容器，实现自动化打包和发布。目前已经在本地mac实现docker创建容器和运行测试，还没有部署到线上！ 第三步：进行微服务拆分，通过docker容器云实现动态扩容，支持高并发，实现全球统一服。 9.关于服务监测 go是静态语言，所以编译运行的web应用如果出现panic，整个进程就退出了，所有连接都会被断开。 这跟php这种动态语言提供的web应用还不太一样，一个连接的服务挂了，其他连接不受影响。 所以必须充分的测试，尽量做到线上的服务不要panic。但是人难免会犯错，程序也不可能百分百没有bug，所以必须做好监控和预防措施！ 我们的解决方案是有个定时程序每分钟检查一次服务器程序的进程是否还在，如果没有就说明程序panic了，就重启服务器应用，将影响降至最低。 同时邮件通知相关技术。技术收到邮件之后可以通过日志查看panic的原因，解决bug之后，测试通过，再发布更新！ 10.关于压力测试 1）测并发链接数上限，并以此为参考，设定登录排队系统的人数限制！ 2）测比赛场的玩家数上限，这个需要提前准备足够的AI玩家数据，然后同时进入指定比赛场， 一是看自动分房间功能是否正常，而是看有没有并发死锁和chanel挂起等问题发生。这些问题在开发的时候，本地单元测试是发现不了的！