网络傍克隆

我具有TCP套接字，UDP通信等基础知识，但是在如何将它们应用于实时游戏环境方面找不到很多。

我有一个Pong克隆，有4个播放器，并且需要在三个客户端和服务器（服务器是第四个播放器）之间同步桨位置。目前，我使用UDP发送实时更新（桨式运动），并使用TCP设置游戏大厅等。

散发大量UDP流量是否是坏事？我是否应该研究类似DCCP的拥塞功能？还是这样的小规模项目真的不是问题吗？

客户端/服务器之间何时应发送同步消息？目前，服务器正在以其可以管理的最快速度向UDP数据包发送垃圾邮件，而客户端也在以最快的速度向其服务器发送垃圾邮件位置。这是最好的方法吗？我是否应该添加某种延迟，以便每X毫秒发送一次消息，还是仅在事件发生时才发送消息？（例如，桨叶速度由于用户输入而改变）

使客户端之间的点对点交流更好吗？

我在Pong的背景下问这些问题，但也对在其他游戏或通用解决方案中如何克服这些问题感兴趣。

有一个可配置的更新间隔（因此您可以调整并尝试每秒5个数据包或20个数据包），并且每个帧都查看是否该发送更新了。您可以使用一个简单的游戏为每个事件发送数据包，但是在更复杂的游戏中，这是不切实际的。还请记住，这会有数据包开销，因此，如果要发送一堆小数据包，则会浪费带宽。

每个更新间隔使每个客户端将其桨叶位置发送到服务器或每个客户端（对等）。让服务器还发送球的位置和速度矢量。每个客户都可以像在单人游戏中一样运行相同的屏幕绘图代码，因此球的移动将变得流畅。在多人游戏中，尽管您只有服务器以固定的时间间隔（以及如果您喜欢每次击球，都会发送球的位置/速度更新）。

让球的位置更新参考所有客户端的游戏时间，这样您就可以丢弃乱序的数据包，甚至可以使球的位置插值更加准确（您可以知道过去特定时间的位置和速度，从而可以插值新的位置）。

使用这种带有落后游戏的模型，您可能会看到球有时向后移动或略微跳动。但是，如果连接得体，它应该会非常平滑。

关于流量问题-您希望避免每个对等点每秒发送20-30个以上的数据包。在一般情况下，如果发送的数据包较小，数据包较少，则（略有）延迟会减少，丢包的机会也会减少。

您绝对不希望以比帧速率更快的速度发送更新，因为播放器将无法分辨出差异-实际上，如果您仅每秒发送10次数据包并在接收端内插/外推结果，大多数玩家不会注意到差异。

这是一个相当广泛的问题，但我将尝试总结重要方面。

在您的游戏的网络代码中做出的第一个决定是，是否要设置对等安排的客户端/服务器。大多数游戏（可能只有RTS是例外）可能使用客户端/服务器体系结构。主要优点是这种安排具有更高的容错能力，并且可以更好地控制每个客户端接收的数据。点对点允许发送少得多的数据，但要求每个对等点像其他对等点一样完全模拟整个世界。如果一个同位体出现滞后或不同步，则每个人都必须等待它们恢复，否则就迷路了。

UDP通常也是正确的选择，当然对于任何客户端/服务器模型而言。TCP对于点对点游戏可能是实用的，但是即使那样，UDP还是一个更好的选择。基本上，UDP可以为您减少处理，这意味着需要付出更多的努力，但也可以更好地控制故障的处理方式。

对于Pong，我要选择的是客户端/服务器，因为这是一款面向动作的游戏。这里要注意的一件事是，即使您说一个播放器是“服务器”，但最好还是对代码进行结构化，以使它们本质上运行本地服务器并将其作为客户端连接。

您当然也不想在任何方向进行“垃圾邮件”更新。每帧仅需要从服务器进行一次更新，并且服务器应以固定的帧速率运行。这取决于您，但是没有必要过高。50ms帧（20 FPS）足以获得流畅的游戏效果。为了使事情顺利进行，您需要使用插值。客户端应该在服务器帧快照之间不断转换，但是这很容易成为一个单独问题的主题。

客户端更新也应受到限制，但是如果客户端以适当的帧速率运行，则每帧更新可能会太多。

你在乎作弊吗？

如果不是这样，点对点将使您的延迟减半，因为它是A <-> C而不是A <-> B <-> C。如果是这样，则为了保持同步的公平性，您可能希望使本地玩家的响应或某些大多数游戏所做的有些滞后-让玩家在本地执行任何操作，然后在服务器的结果与本地模拟的结果不同时迅速返回。

乒乓克隆实际上有点棘手，因为与大多数游戏不同，您（作为开发人员）不能通过一方看到击中而另一方看不到作弊来作弊。

至于一般化的东西，我听说过但没有发现必要的一种技术（虽然可能是动作游戏）是保持动作具有其真实时间戳（接收时间-ping / 2），并使服务器回滚（快照）（如果发生了较早的事件，则重新应用以后的操作）。这样，每个人在本地都是一致的，除非由于不同玩家的互动而存在一些冲突。唯一的危险是如果他们伪造过时的连接，则会“回滚时间”。

谷歌推算。发送4位玩家的更新不会很重要。发送的数据量将约为字节数。因此，这意味着经常更新应该可以。通过推算，您可以在客户端和服务器上移动播放器。服务器是授权者。当客户端的位置与服务器的同步变得太不同步时，它必须重新回到对齐状态。 http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking 使用UDP是可行的方法。Bupdates将频繁发送，丢失的数据很快将被传入的数据替换。TCP的数据包重传对于播放器位置来说不值得。请参阅本文，以获取有关如何使客户端和服务器保持同步的更多信息。

几周前，我编写了一个2人本地网络乒乓球游戏，方法如下：

-一侧打开服务器，另一侧自动连接-它们都以60 fps或更低的速度向彼此发送桨x的位置[UDP]-如果一侧击球，则他们决定球的新速度和位置并发送传给另一个[TCP]-如果球飞过桨，错过球的球员会与另一个得分增加消息联系，并且球被重置[TCP]-球一直在独立进行模拟，适合乒乓球的简单球物理

这以60fps的速度产生大约0.3到0.5 KByte / s的流量，并且玩家的感知能力没有任何滞后，但是只有当ping低于某个阈值时，才需要发送球的新位置。

使用该系统作弊也很容易，而且由于连接损耗很大，很可能会不同步，但是谁会在意乒乓球作弊呢？