关于帧同步和网游游戏开发的一些心得计划

关于帧同步和游游戏开发的一些心得

实在不行就像魔兽争霸一样打GG！ 从今年下半年开始制作一款实时对战游戏以来，就在着手写一个帧同步的游戏框架，其中包含了服务器框架和客户端框架，该框架目前已经开源。

期间踩过无数的坑，充分领略到了国内中文技术文档十分稀少和零散的问题，所以在这里想写下走过的路，以便于后来者参考。首先，希望写一个前后端能统一语言的框架，以至于在前端写好的游戏逻辑，拿到后端就可以直接使用。其次，目标是写一个同步框架，在框架层面解决同步问题，在此之上写游戏逻辑的时候不需要再考虑游戏同步的问题。目前看来，这两个目标都得到了比较好的完成。下面是解决方法。首先要解决的是前后端语言一致的问题这里我使用了一个c#服务器框架 SupperScoket遇到的几个坑是:1.导出这个框架到在Mono上运行时报一个找不到window API的错误，解决方法是使用.Net 4.0以上版本的SupperSocket2.框架在使用TCP模式时，有时会报出一个Send byte Time out 的异常，解决方法是使用TrySend方法，并在返回false时关闭连接。第二个要解决的是同步框架的问题这个问题比较复杂，如何在书写游戏逻辑的时候感受不到同步问题的存在？如果每个事件都要等服务器的回包，还要体验流畅，只能从预处理和追赶两个角度入手。预处理就是，这个事件还没有发生，但是考虑到络延迟的存在，提前先把结果发送给每个客户端，然后客户端到了这个时刻再把这个事件表现出来，典型的例子就是皇室战争。如果说没有办法做到预处理呢，比如说玩家的操作需要立即响应，那么其他玩家收到这个事件的时候必然已经迟了，所以就要做追赶，比较典型的就是影子跟随算法。但是这两种做法必然要在游戏逻辑中做对应的处理，开发者要时刻清醒此时是预测还是追赶，增加逻辑的复杂性，而且游戏的表现可能也参差不齐，有些地方也许同步的好，有些地方可能不好，要调优需要在每个地方都下功夫，增加开发时间。那么应该怎么办呢，最理想的方法当然是全部当成本地计算，这样就无需考虑是追赶还是预测的问题了，那么络游戏怎么全当成本地计算呢？当然就是帧同步了。关于帧同步上已经有很多资料，在此不再赘述，但是关于帧同步有一个核心的问题，那就是它在络差的时候表现很差，这一点我们可以从星际争霸和魔兽争霸这些游戏中看出来，一旦有人卡顿，所有人都要停下等这个人的消息，但是我们知道手游《王者荣耀》这款游戏就是帧同步做的，他是怎么解决这一问题的呢？在《王者荣耀》负责人在unite 2017大会分享中我们没有看到这一解决方案，这可能是他们的商业机密，但是在看了暴雪分享的守望先锋同步机制之后，我得到了一个我自己的解决方案。那就是预测回滚和解。原理很简单，游戏开始时，每个客户端按照帧同步的方案推进着游戏，但是如果遇到服务器没能及时返回其他玩家操作的时候，给对应的玩家预测一个操作(复制该玩家最后一次操作),并继续推进游戏，如果在其后收到了服务器玩家关于这个人的操作，则把游戏回滚到预测开始的那一帧重新计算一遍，然后和现在游戏世界的表现和解。如果服务器迟迟没有收到某个玩家的消息，则会给这个玩家预测一个消息(复制该玩家的最后一次操作)然后推送给所有玩家，包括那个掉线的玩家。其他玩家会以这个预测操作为准计算接下来的游戏世界，而这个掉线玩家也会收到这个预测操作，并且替换掉玩家实际进行的操作，重新计算一遍游戏世界。保证每个客户端的输入一致。