`

游戏比较顺利公测初期记录

 
阅读更多

今天公司的D项目正式不限号测试,开了3组新服,每个服都达到了之前设定的人数,状态均良好。于是可以带着良好的心情,作为这半年的工作,可以适当的做个记录了。


我虽然才来了半年,D项目已经研发接近三年,但很幸运的是该项目框架是从头开始研发,并且比较密集的压力测试和问题等也都集中在这半年。不敢说获益许多,程序上的问题有多少记多少把。


首先从公测的推广手段说起。今天的公测跟以往不同,没有大规模的做广告,而是召集来了一个服务器上线人数的2-3倍人数,服务器组也准备2-3个。先确认好单点OK后,再进行大规模宣传。之所以这么做,我想说个案例。该公司之前的K项目,公测第一天就有10W人在线,结果压力问题、BUG问题,玩家急剧流失。即使把这些程序上的问题解决后,原本的玩家用户都已经成了脏用户。结果再也挽救不回来了。



其次是BUG,如我http://lin-style.iteye.com/blog/1208359 这篇帖子所说,普通的逻辑BUG尚可容忍,但是千万不要出现流程上的BUG.比如任务做不下去了,活动参加不了了等等这一类的。如果出现了刷钱、刷等级的问题,要能立刻从日志中找到玩家的行为,确定到问题发生点。

举个例子:游戏里面有些任务怪按正常流程下来会删除掉,但是总有不知道的意外发生,导致不删除,使其他玩家的流程无法进行下去。这时候首要之急是要加个定时的删除保护。虽然那个意外可能永远也找不到了。



然后是对性能的观测

1)网络带宽的利用。要搞清不同的业务占用了多少带宽。活动上的广播的占了多少,走路的占了多少,战斗占了多少。

2)CPU的利用。收发包占了多少,怪物逻辑占了多少,被玩家调用占了多少,跟脚本之间的交互占了多少,战斗计算占了多少

3)数据的存储。以前我一直对这块没怎么关注,但是发现实际上实现的方式会超出你的想象。这块的压力上倒不是特别大的问题,主要是在玩家数据存储正确性、回档上的问题。

4)完善的日志储备。如果可以的话,尽量做个日志服务器,有多少扔多少。这些日志都是你日后的救命福星。



最后再略提下压测

开机器人压测业务逻辑的问题不是主要要压的。主要是压网络带宽、登陆、下线保存、切服、广播等方面。

1)网络的话建议搭个模拟外网的环境,可以调节环境的丢包、抖动等等(软件名字我忘了,明天补上)。

2)下线保存和登陆,因为是机器人,所以你可以很变态的关、开、关、开。。。保准会发现很多问题。

3)广播主要是测试定点的扎堆情况,搭好机器人环境后,可以真人上去查看。


还有压测上的一些问题记录在这个帖子里:http://lin-style.iteye.com/blog/1268480





 

2
0
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics