我目前正在计划一个简单的在线多人游戏。这是问题。在服务器上进行整个游戏逻辑并仅将输入从客户端发送到服务器是否有意义?优点和缺点是哪些?为什么我不应该这样做?
我目前正在计划一个简单的在线多人游戏。这是问题。在服务器上进行整个游戏逻辑并仅将输入从客户端发送到服务器是否有意义?优点和缺点是哪些?为什么我不应该这样做?
Answers:
您不想将播放器输入发送到服务器。您可能想做的就是将玩家想要做的事情的抽象表示发送到服务器,然后在服务器上运行逻辑。
同样,您不一定要发回客户端需要做的所有事情。例如,您可以发送某种消息,说“ NPC X死亡”,然后客户端确定要播放的动画/声音。像这样的东西。
诀窍是通过防止人们作弊来找到带宽(和服务器上的处理能力)被压倒的线路。通常,您只能在服务器上做出改变游戏规则的权威决定,而将所有辅助视觉内容留给客户端。
在整个站点上,都有很多关于此主题的更具体的问题。例如:
好吧,您得到了答案,但真正的答案是“尝试一下”。事情因游戏而异。
我为一些分布式网络游戏设计课程做了几款多人游戏。最具挑战性的是制作一个实时动作游戏,许多玩家参与其中,并发送诸如地狱之类的输入。谈到这一点,一切都会变成问题。如您所见,Tetrat发送了第一个链接,即使确定串通也成为问题。而且您会听见诸如滞后,内插,外推,预测之类的术语。但是,如果您从未尝试过从头开始编码,那么您只会接受这些单词,而不会知道它们的真正含义。
我的建议是:
第1步现在
就开始基于完全授权的服务器设计。如您所说,只需将用户输入发送到服务器,然后让服务器执行所有操作,客户端即可获得结果。您的游戏将完全一致。但是,当您查看客户时,您会注意到一些滞后,一些传送问题,而不是平稳的移动...等。
步骤2
开始在客户端修复问题。例如,传送问题。您的角色在(0,0),服务器说您现在在(100,100)。你的角色会传送到(100,100),这不好。插值来了。您应该在客户端有一个代码,该代码可以使字符从(0,0)滑到(100,100)。是的,您将角色从(0,0)移至(100,100),但是速度有多快?现在,您只需使用每个服务器更新之间的时间差即可。如果您的服务器在一秒钟内发送10个数据包,这意味着每个数据包之间的延迟为100毫秒。
第三步
现在,您的游戏已经对延迟(1-50)ms的快速网络非常有用。但是,如果发生丢包,高延迟或服务器中的计算时间过长等问题,它注定会失败。在这种情况下,当您按向左箭头时,您会注意到您的角色向左移动200毫秒。数据包之间的延迟将到达服务器,计算时间,并返回到您的最后位置。这很不好,这是服务器授权设计的最大缺点。玩家希望他的角色一按下就向左移动,就不能让他等待。幸运的是,客户端也具有与服务器相同的代码,那么为什么不立即在客户端上执行它并使用服务器的答案来修复最终结果呢?多数民众赞成在根本上输入预测是。客户向左按,他旁边的代码会将他向左移动,假设200毫秒后,实际位置来自服务器,客户端使用它来校正其位置。如果一切顺利,客户将不会注意到任何事情,“第2步”也将为我们提供帮助。
好了,net有很多关于该主题的教程和内容。但是我真的很喜欢2个:
真的很不错,涵盖了黑点:Valve-Source Engine多人网络
有点历史,有趣的阅读和值得一试:28.8年有1500名弓箭手,
优点:
缺点:
取决于要创建的游戏以及游戏的哪个部分。如果要开发RTS(或任何带有锁步模型的游戏),那么您绝对应该只发送输入以及接收到哪个模拟步骤。
如果您想进行射击,则可以同时使用输入和抽象功能。如果您以《虚幻竞技场3》为例,他们主要通过复制函数调用来创建多人游戏。
对于移动,他们将玩家输入(每个动作压缩为一个比特)的增量旋转,加速度和时间戳记,并将其发送到服务器。
对于其他目的(例如武器),它们在您射击时会同步(AFAIK,尚未深入研究此部分)。
对于更多的静态/不经常更改的值(例如运行状况),它们会根据程序员指定的内容将变量发送到客户端或服务器。
对于非RTS游戏,请记住客户预测。