帧同步游戏的设计

从单机游戏到网络游戏的过程中，默认情况下玩家在同一虚拟环境中进行操作会带来一致性、响应性、带宽和延迟等问题。为了平衡这些因素并实现实时PVP游戏，《DOOM/QUAKE I/II/III》网络模型中的帧同步技术被广泛采用。该技术通过确保客户端输入的一致性和时机来保证显示的一致性，并通过锁步处理逻辑帧与渲染帧之间的关系来维持流畅的游戏体验。然而，在实际应用中由于网络延迟和技术限制（如丢包），可能导致画面卡顿或操作不及时反馈。为了解决这些问题，《ACT手游》采用基于UDP的定制方案以减少数据包丢失的影响，并通过动态冗余算法平衡速度与可靠性的关系，在保证低延迟的同时提升整体性能表现。

从单机游戏到网络游戏

独立单机游戏特指基于即时操作的设计模式，在这种模式下玩家通过终端执行特定的操作指令来完成游戏操作流程。当引入多端网络后这些操作不仅限于本地终端处理而是能够被分布在多个节点上实现分散计算从而让不同设备上的玩家能够在同一虚拟空间中同时进行互动这一特点为快节奏的动作类 multiplayer online games带来了新的挑战：保持一致性和快速响应（即响应速度）的同时保证足够带宽并有效降低系统延迟。为了实现上述四个关键要素的最佳平衡与协调网络游戏中的实时P2P战斗系统应运而生它的核心目标就是通过对这四个方面进行全面权衡来确保整个系统的稳定性和用户体验

帧同步的引入

帧同步作为一种引入多人游戏后能直观实现的最佳同步机制，在理想状态下能够提供理想的解决方案。然而，在现实应用中，
由于帧同步需传输大量游戏数据以驱动游戏逻辑运行，
客户端必须长时间保持稳定的网络连接（即低延迟和较少的网络抖动）。此外，
还存在状态同步技术，
其中，
帧同步是将玩家的操作指令直接传输至其他端设备，
并通过确定性的计算实现即时同步效果；
而状态
则是将所有客户端的操作指令发送至服务器端，
由服务器进行综合处理后将最终结果广播给各客户端。
已有大量对比分析这两种技术的特点与适用场景，
本节仅对
技术展开详细讨论。

帧同步的原理

了解帧同步技术并对其中的关键发展脉络进行深入研究是非常有必要的。

帧同步的响应性

在实时对战竞技游戏（PVP）中实现手顺流畅的操作体验至关重要。玩家的动作往往会在极短时间内即可呈现变化状态，在帧同步机制下，玩家的操作数据发送至服务器后需及时接收并反馈给客户端系统，在服务器端进行处理后才可通过网络返回给玩家视觉反馈效果。然而，在网络不稳定的情况下这一流程往往会出现波动性较大的延迟现象，在动作触发后的响应时间难以准确预判，在这种情况下很难保证操作执行后的即时效果表现得平滑自然。为了优化这一过程我们可以借鉴语音传输业务中的先进处理方法即在接收网络数据之前不立即进行解码处理而是建立一个固定的延迟缓冲区将所有的操作数据按固定的时间间隔进行批量处理这样能够有效平滑因网络抖动导致的数据包传输不稳定的状况其中添加的固定延迟可以根据当前局域网环境下的延迟状况动态调节以确保所有操作指令都能以稳定的时间间隔被处理从而实现系统运行的顺畅性保障游戏体验的质量

TCP还是UDP，这是一个问题

该方案不仅确保了系统设计的一致性和稳定性，并且实现了将单机游戏转换为多人联机游戏的可能性。在局域网环境中运行勉强能够接受，在广域网或互联网环境下则面临更大的挑战。
遗憾的是，在实际应用中我们主要集中在互联网游戏领域进行研究。
此外，在了解移动网络延迟情况之前，请先了解基础网络传输机制。
首先是基于可靠传输的TCP协议体系：它通过自动重传丢失的数据包来保证数据完整性，并且已经有人为我们实现了这一功能；这一解决方案不仅可靠而且经济实用。
诚然，在可靠性方面表现突出；然而，在处理丢包频繁导致断线的情况下，则需要额外的时间和资源。
TCP协议的工作原理是：当数据包丢失时会等待至少两个往返时延才会重新发送该数据包；如果丢包情况严重甚至会导致通信中断；一旦断线就会触发断线重连流程。
根据以下测试数据可以看出：

这是腾讯一款以忍者格斗为题材的ACT手游给出来的数据，可以看到在各种网络情形下，UDP的表现（延迟分布）基本上都优于TCP。
那么到UDP，非面向连接的传输协议，没有自动重传，没有拥塞控制，不能保证包序，甚至不能保证可到达，只保证了数据报完整的基础特性。优点是延迟小、数据传输效率高、资源开销小，如果用来作为网络游戏的传输方案，需要在应用层定制更多适用于网游的特性。在UDP基础上定制一个应用层的协议，难度比较大。基于UDP也有一个通用的解决方案UDT，保证了可靠性和包序，但是跟TCP类似的，UDT也是基于超时重传的方式保证可靠。下面我想把一些专用定制的方案拿出来讨论。
首先，帧同步需要每帧广播数据，广播的频率非常高，这要求每次广播的数据要足够小，最好每个网络帧在一个MTU以下，这样可以避免在IP层分片，降低延迟，互联网的MTU标准为576字节，有效载荷长度控制在(576-8-20)548字节以内。为了尽量避免重传，游戏里面可以用冗余的方式——每个帧数据包实际包含了过去2帧的数据，也就是每次发3帧的数据来对抗丢包。三个包里面只要有一个包没丢，就不影响游戏。另外，定制的方案还需要有一个请求“下载”丢失帧的特性，以防止连续3个包全丢的情况。对于“下载”特性，则可以考虑使用TCP。这是全冗余的做法，缺点是会导致流量增加2倍。还有一种动态冗余算法，根据客户端的丢包状况动态调整冗余倍数，上面介绍的那款ACT游戏就是用了这种方法，本质上还是用流量换速度。
接发包速率对一款PVP竞技型的商业游戏来说至关重要，目前还只是学习到皮毛，以后深入了解后再补充。除此之外，后续还需要服务器介入，解决断线重连和反作弊等问题，先写到这里。