谈技术前，先来谈谈手机moba游戏的技术需求。1.手机moba游戏对延迟很敏感，因为延迟高低直接决定游戏对可操作性。2.由于手机游戏，所以流量能不能尽量少点 3.moba游戏要求可以对游戏进行回放，因为moba本质也是按‘局’为单位的游戏，玩家需要回放来观看上一局的对战情况，以及相对来说对数据一致性要求没那么高，万一出现一局中刷道具的情况，也只是影响一局的结果，通过看回放运营可以通过封号等手段来处理非法用户。
先谈谈第一个需求，moba游戏对延迟很敏感，延迟可以分为计算延迟以及网络延迟。如果战斗逻辑在服务器设计上选择尽量多局游戏可以负载到多个线程甚至多台机器中，尽量不要出现战斗计算导致的节点出现高负载的情况的发生，尽而影响整个游戏系统的性能，房间内的游戏actor模型是个较好的解决方案。代码的优化主要多个方面，首先战斗中，往往有很多buff的存在，选择高性能的定时器尤为重要。其次战斗中的复杂的几何运算的部分尽量要放到静态语言中去，比如引入c或者c++的so进行计算，剩下的很多部分和具体的技术选择有关有不同的优化方案了。
在来谈谈网络延迟，手机的网络相对来说不稳定，所以针对网络协议的选择，尽量选择udp，而不是tcp。当发生重传时tcp会以指数退避的方式重传，所以网络不稳定的时候，会很影响操作体验。不使用tcp，但是可靠性可以用应用层的自己实现的协议来保证。由于众所周知的原因，国内外通信丢包比较多，所以很多FQ软件由于，往往使用kcp协议，主要就是优化就是针对的tcp的指数退避的重传的问题来优化用户体验。虽然说了udp的好处，但是如果在应用层实现“重传确认”，“流量控制”，“收包后重排”，以及“冗余包来避免重传”这些功能确实比较麻烦，好在也有一些现成的协议可以使用，比如才用kcp+fec的解决方案。
现在来谈谈方便实现回放和流量大小这个需求，游戏的同步方案分为帧同步和状态同步，一般mmo中都会选择状态同步，状态同步如果要实现回放会比较麻烦，需要按时序记录服务器发往客户端的所有的消息包，整个回放文件也比较大。而帧同步只需要按时序记录客户端发完服务器的消息包，这样回放文件也比较小，毕竟操作有限。看起来帧同步比较方便的解决了moba游戏的需求的流量比较小以及回放比较方便实现。
帧同步需要把战斗逻辑写到客户端，开始时同步随机数种子，服务器每隔一段时间（比如100ms）收集玩家的操作，然后把操作广播给客户端。令输入为x，输出为y，战斗函数为f，那么f(x) = y。当随机数确定，每个客户端代码f函数一致，然后输入x一致，那么最后表现的结果y一定也是相同的。但是除了随机数种子要重置一样外这里需要注意的另外一个点是浮点数。不同cpu架构为了效率以及编译器优化等原因或者其他的原因，并没严格按照IEEE754的标准来实现浮点运算，所以战斗中尽量避免使用浮点数运算，改成定点数或者整数运算。帧同步有个问题就是断线重连时间比较长，尤其玩的时间越长，重连时间越长，上述用udp方案来替代tcp也是主要尽可能避免重连的问题。
在来谈谈安全性，服务器可以简单的做个仲裁投票机制，不同客户端的一些关键数据结构进行hash运算，服务器来仲裁，踢掉hash值不一致的玩家，甚至哪怕有玩家在一局中刷的情况，也很容易通过举报等方式，给运营处理非法玩家。
网友评论