浅谈moba游戏的技术和需求(2)

主流的moba在传输层协议上采用udp，上层实现tcp的一些功能，以及通过一定的冗余数据保证尽量少的重传发生，如果非要才用tcp，也有一些对优化办法，
其次很多都是建议moba采用定点，但是定点的数学库麻烦，很多都要自己重写，如果非要采用浮点也有一些办法。
下面主要针对这2点进行讨论。

• 网络
  由于tcp经典重传算法是指数退避的形式，当丢失包时，重传很慢，导致延迟很高。但是tcp也提供了快速重传方法，dupAck几次后，不等定时器到期就立马传送。但是没在移动端找到对应api，一般客户端只支持开启TCP_NODELAY来关闭negal算法，其他一些tcp选项并没移植过来，但是服务器开启快速重传起码可以保证服务器到客户端传输的效率提升，就可以保证总体延迟的降低。还有因为移动端的api不支持sack重传，否则还可以继续提升传输效率。用tcp限制实在很大，可优化的空间极其有限，而且现在有成熟udp的kcp+fec的解决方案，所以推荐用udp来解决。

• 浮点定点
  在帧同步中，网上很多解决方案都是基于定点的，而且校验客户端的作弊行为，通过把地图中所有实体的属性求去哈希值，发给服务器，然后服务器判定不一致的客户端为作弊客户端，这个是基于大部分客户端不作弊的情况，当然如果有多个作弊客户端匹配进入地图，这种办法就失效了，不过避免多个可能的作弊客户端进入地图，那是匹配模块该考虑的事情，不是战斗模块该考虑的了。这种防作弊方法如果其中一台机器浮点标准不一致，会把正常客户端误判成为作弊客户端的。
  做游戏本质是做工程并不是做科学，所以允许部分误差，比如怪物血量100，最终浮点计算伤害出了99.999还是100.000，这个都算怪物死亡，并不会影响游戏的进程，除非浮点误差积累了很多，然后导致影响游戏进程了，不过这个是小概率事件，可以不用考虑。但是一旦有了浮点误差后，上述通过计算哈希值的办法就失效了，所以判断客户端是否作弊就应该换个方法了。可以通过用“伪随机数”的方法，随机算法固定，随机种子固定，那么产生的随机序列一定是一样的。
  每个客户端的随机种子一致，因为服务器下发的，然后每次在游戏进程改变(比如怪物死亡，人物死亡，添加技能，或者添加buff之类)的地方调用一次随机，那么在一定的帧数调用一次随机数然后上传给服务器，服务器来判断作弊玩家。这种做法也是基于“有玩家作弊，一定会导致游戏进程发生变化，然后导致每个客户端在特定帧，随机的次数不一致，最终产生的随机数不同”。通过这种办法算比较完美的解决了客户端使用定点数的问题，客户端开发可以很开心的用各种系统自带的数学库了。
  上述的防作弊方法是针对修改属性之类的作弊方法，由于帧同步所有的逻辑和数据都在客户端，但是一些只是修改客户端显示的作弊方法(比如moba全图挂，fps的透明挂)就比较难防。所以特定的时刻，比如被举报过的玩家或者ip，下次在开游戏时，服务器一定要跑逻辑，客户端变的纯显示，当然服务器跑战斗逻辑对服务器负担是很严重的，一般一局moba中，最高的实体个数有几十个，没做aoi的情况，战斗的计算以及网络消息的广播多会导致cpu负担很大，战斗用c++来编写单cpu只能同时跑十几局战斗，在优化也只能通过改变更合适的战斗算法以及使的代码的局部性更高来优化了。不过这个也基本足够了，16核心机器，一次可以跑几百局逻辑了，而且这个只是针对作弊玩家的在次校验。