写了下列这些后，终于，游戏离正式大规模公测还有一个月多点，做个这个月的流水笔记。好坏不评说，等正式公测了，再回头总结
MMO游戏终极内测开服一周，问题记录
游戏服务器压测的一些记录
游戏比较顺利公测初期记录
4月份：
公测顺利！
3月份第四周：
1)一些零碎的小单(貌似bug永远不完)
2)我建议主程加个命令，可以查看玩家当前信息状态。比如坐标，身上的状态，等等，这些信息都由服务器发送。因为有时候出问题再去定位问题，针对性的加日志，我觉得太迟了。比如以前有个问题，组队进不了副本，后来找到是状态问题。如果事先有这个命令，把人物当前状态都打出来，会不会更好？再比如现在坐公交车经常卡主，如果能把坐标信息打出来，状态打出来，就可以更精确定位是客户端问题还是服务端问题，会不会更好？
3)想到了一种团队建设的方法，有时间单开帖写。
4)公司内部又进行了一次真人压力测试。性能指标还好，意外发现，写多线程写日志的函数居然影响到了性能，而且还是在运行一个多小时后。
3月份第三周：
如果我第一周所说，不可能没有需求，所以原本的轮休一周也不可能，起码现在为止已经超出了预定的时间。这周团队主要做了如下：
1）广播范围的优化。一开始是九宫格，优化成以人物为中心的四个格子。
2）怪物需找目标，一开始也是九宫格怪物数量全部遍历，我提出的方案是做成长条状管理，比如
======
|| ||
|| 怪 ||
|| ||
======
注意，这不是小正方形格子，而是长条。这是最近的一层，外层还是这样包围着，找怪的时候先从里自己最近的一层找起。
跟把格子划小不同，格子划小越往外层，格子数越多。但同时我自己也有个疑问
1)越往外层，说明怪物越稀疏，多点遍历也没什么。
最后主程觉得稳定为主，不采取这样修改。其实我我自己觉得这个只是虚拟了个管理器出来，不会有什么BUG，就跟1）广播范围的优化代码架构一样，1）都能做为什么2）不能做。
思考，这种问题为什么现在才冒出来。。前面7、8次的测试难道都没发现吗？
3月份第二周：
1）并服需求被取消了，呵呵，意料之中。
2）防私服跌跌撞撞还是上了。
3）对warning扫描了一遍，发现不少错误，比如&&写成&, -写成=, =写成==，而且由于一些运算规则和运气，居然没出问题。后来把warning等级都提高了。
两个查询warning的MSDN地址
http://msdn.microsoft.com/en-us/library/t7ab6xtd.aspx
http://msdn.microsoft.com/en-us/library/19z1t1wy.aspx
4）对新手流程又重新测试了遍，看看有什么玩法在压力下导致无法进展下去。上回压测就出现过
5）建议日志多打，这东西在我看来是投入成本最小，解决问题最有效的东西。
6）发现执行策划还是没能理解，一个团队里面，不同的工种所对应的效率。比如一个BUG，由于数据配置有问题，QA测试出来，策划就直接转给程序了。程序就傻乎乎的开始跟调。。最后才知道是数据配置有问题。我认为的团队里面，程序是最后一张底牌，对于程序所开发出来的工具、接口，其他人应该玩得很透才对
3月份第一周：
如所有人明白和口头述说的一样，要临近公测，游戏尽量不做大功能单，只做一些修改。但是往往这只是一条准则，所谓的准则，就是准备往上面加需求的原则。
服务器小组有7个人，做了如下安排：
1）2人测试上回公测到现在中间新加的业务压力
2）2人对外服(有3个服在运营)的日志进行检查，是否有异常和报错
3）3人玩游戏的业务，检测有哪些业务会引起流程异常
就如同我开头所说，还是有几个大的功能被加了进来
1）同步问题。
2）防私服的一些设置
3）并服工具。做这个原因，是想把在运营的几个服人数提一提，尽量早暴露问题。
4）策划想加一个怪物生怪物的功能（一生二，二生四）