冲突检测应该在服务器端还是在客户端/服务器之间协同进行？

我正在开发一个在线游戏，该游戏将具有非常重的碰撞检测处理。播放器模型将与仅存在于服务器端（不存储在客户端数据文件中）的其他播放器，生物，建筑物，地形和实体对象发生冲突。

为了安全起见，我应该在服务器端进行所有冲突检测吗？还是应该让客户端进行检测，然后让服务器以某种方式进行跟进？我觉得服务器本身无法完成太多工作（我正在为一台服务器上的数百个播放器设计引擎）。

有谁知道主流MMO如何做到的？我知道目前几乎所有MMO都容易受到物理攻击，并且通常通过检测黑客和禁止人员来对其进行处理。我希望这些技巧根本不起作用，至少对于物理组件而言。

似乎最明显的答案是在客户端进行大部分检测（以确保平滑性），然后在客户端距离太远的情况下，内插到服务器显示的内容。服务器将以比客户端更低的频率打钩（例如10hz），并且可能需要具有一些基本的“该播放器能否到达他说的当前位置（来自他的最后一个已知位置）”代码，这意味着某种导航网格类型的解决方案和寻路。

根据您的需求，该速度可能会过慢。例如，您可能会做出设计决定，以不关心服务器上的玩家与玩家之间的冲突。据我所知，大多数游戏甚至都不关心客户端。这实际上取决于您的需求。

但是经验法则是您永远不应该信任客户。如果影响游戏玩法，则必须至少在服务器上进行验证。

因此，这里有一些答案。

• 从性能角度和玩家感觉角度来看，客户端碰撞是理想的选择。您不想让碰撞变得迟钝，而是希望玩家撞到一个固体物体并停下来。如果在服务器端进行操作，那么您要么是在各地寻找橡皮筋球员，要么是当他们尝试移动时给他们明显的滞后。两种情况下都不好用。

• 从安全角度来看，服务器端冲突是理想的。您的客户越接近“哑终端”，您的游戏的利用就越少。有一个原因，没有一个玩基于文本的MUD的人不必担心wallhacks或speedhacks-这是因为客户端没有做任何值得一提的事情。

• 几乎在每种情况下，两者都做是“理想的”。让客户来做他们的事情，然后仔细检查服务器以确保人们没有作弊。的缺点是复杂性，同步（究竟做怎么做，如果这两个不同意），和纯粹的服务器CPU使用率。

• 我建议几乎完全在客户端执行此操作。就像在完整的客户端系统中一样，客户端对自己的位置具有权威性，并执行所有自己的处理。最重要的是，您会随机让服务器不时地检查各种玩家。保持服务器负载较低，但这会以惊人的速度消除骗子。

或者，现在在客户端进行操作，如果您的游戏变得足够流行而人们在其中作弊，则在将来的某个时候添加服务器端验证。坦白地说，这可能不会，因此现在没有必要花费编码器时间。

魔兽世界不会在玩家/小怪之间进行碰撞检测。该决定背后可能存在或可能没有技术原因，但实际上，这更多的是游戏设计决策，而不是技术决策：

想象一下在玩家对玩家的情况下它有多大的可利用性。或者，如果其他（经常是闲置）玩家阻止了您的活动，那么使用银行/拍卖行/邮箱将有多困难！

至于基于客户端与服务器的冲突检测-实际上，除非移动非常缓慢，否则它必须主要是客户端，因此对每个客户端来说都是正确的。延迟/延迟的碰撞响应，和/或与“不可见”物体碰撞将是非常不愉快的。

如果您担心黑客行为，并且会对游戏产生重大影响，那么答案是肯定的。

在我的基于浏览器的游戏中，它是一种“城市建筑”游戏，我对这些黑客并不感到困扰，因为当我布置已保存的游戏状态时，客户端引擎不会失败。

但是，它可能会滥用游戏玩法，因为玩家需要花费游戏币（或高级现金）来扩大可玩区域，以建造更多房屋/建筑物。因此，我将对新添加的建筑物占用的瓷砖数量进行简单检查，再检查多少个可用瓷砖。