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


24

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

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

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

Answers:


21

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

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

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


24

因此,这里有一些答案。

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

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

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

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

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


3

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

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

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


1
尽管问题不在于玩家与暴民/玩家碰撞是否是不良的游戏设计,但我还是建议您看《暗黑破坏神》这样的游戏,这些游戏一切都很好。它为游戏增加了新的维度,并允许您在游戏中做非常有趣的事情。我不会担心玩家会在游戏中阻塞银行之类的东西,因为玩家始终可以看到一个很小的间隙以打开物体。
BarakatX2 2010年

您可能会让玩家被可能攻击的任何事物以及他们无法攻击的任何事物所阻碍,而这些攻击他们都可以简单地通过。例如,玩家将无法穿过小怪,因为他们可以攻击小怪。由于将他们标记为PVP,因此在标记为PVP的情况下,他们也无法漫游玩家。没有标记为PVP的玩家可以穿过任何玩家,即使没有标记为PVP的玩家也可以,因为他们无法攻击那些玩家。
2012年

2

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

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

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.