在我的第一个网络游戏中阅读了很多内容，我理解了有保证的交付与TCP v UDP交付时间的核心差异。我还阅读了截然相反的观点，即实时游戏应该使用UDP还是TCP！ ;）
没有人能够解决的问题是如何处理丢弃数据包的问题。
TCP：使用TCP为只推荐使用TCP的FPS阅读文章。使用TCP客户端输入的权威服务器如何处理数据包丢失和滞后突然的史诗峰值？游戏暂停一会儿然后从停止的地方继续游戏吗？ TCP数据包丢失是如此罕见，以至于它不是那么多问题而且TCP上的FPS实际上运行良好吗？
UDP：另一篇文章建议只使用UDP。很明显，像“投掷手榴弹”这样的一次性UDP事件不够可靠，因为它们不会在某些时候发射。您是否必须手动实现消息接收，重发协议？还是其他一些解决方案？
我的游戏是一个基于刻度的权威服务器，从服务器到客户端进行1/10秒更新，本地模拟可以使事情看起来更具响应性，尽管这个问题适用于更多应用程序。
答案 0 :(得分：2)
我做了一个实时电视编辑系统。所有实时通信都是通过UDP进行的，但是没有实时使用TCP，因为它更简单。使用UDP，我们将每帧发送一个状态包。例如start video in 100 frames, 99,98,…3,2,1,0,-1,-2,-3所以即使没有消息通过直到-3，接收器也会在第4帧开始（只是跳过前3帧），希望没有人会注意到，并且知道这比从这里开始落后更好in。我们甚至从大约+ 1/4秒开始倒计时（因为没有人会注意到），这种方式几乎没有丢弃的任何帧。
总而言之，我们每帧都发送了相同的状态包。它包含有关过去，当前和未来事件的所有实时数据。
诀窍是保持这个数据集很小。因此，我们发送视频ID，帧号，开始屏蔽和结束屏蔽，而不是发送播放按钮按下事件（存在未绑定的数量）。 （开始/停止掩码是帧编号，如果开始掩码为正，则停止掩码为负，则显示视频，帧帧编号）。
现在，我们需要能够在另一个视频或停止视频后不久启动视频。因此，我们考虑可以同时播放多少连续视频。我们需要每个插槽，但我们可以立即重用它们吗？如果我们已按下停止，那么在此之前不知道停止掩码，然后重复使用插槽将视频停止。那个视频没有插槽，所以我们应该停止它。所以，我们可以立即重用插槽，只要我们使用唯一ID。
其他提示：请勿发送+1事件而是发送当前总数。如果两个玩家必须更新一些总数，那么每个玩家应该有自己的总数，在使用点总计所有总数，但永远不要编辑别人的总数。