首页 文章

MMORPG客户端/服务器编码[关闭]

提问于
浏览
12

如何在MMORPG客户端/服务器通信中使用UDP和TCP协议?

例如:

客户端是否通过UDP向服务器广播(播放器位置等)?或相反亦然?

或者更像是使用TCP,其中客户端请求服务器移动播放器 . 服务器接收请求,移动播放器并将播放器发送回客户端,播放器现在位于xyz位置?

聊天 Channels 必须使用TCP实现?

这有什么好文章/书吗?我发现了点点滴滴,但似乎真正的肉和土 beans 都是从经验中获得的 .

9 回答

  • 4

    许多游戏都使用UDP进行与运动相关的活动 - 因此,当你走路时,很可能会发送一堆UDP请求 . 服务器仍然最终控制它是否有效,但您不必关心每个数据包是否都到达服务器 . 这就是许多游戏客户端也使用某种预测机制的原因 .

    就你的第二次提及而言,是的,所有控件都由服务器管理是很常见的 . 您不希望客户端向服务器广播任何内容;你应该做错误和输入处理服务器端,以防止人们黑客入侵 . 您可能还限制每秒输入 .

    无论如何,UDP和TCP的组合是合适的 - 你只需要问自己,“我想要可靠性还是速度?”

  • 0

    有许多不同的可能实现,但在大多数情况下,它们看起来像这样 . 几乎在游戏世界中的任何动作都重复这种模式 .

    • 客户端与服务器通信,玩家想要移动 .

    • 客户端根据其认为应该发生的事情显示播放器 .

    • 根据播放器的位置,服务器验证移动是否可能发生 .

    • 服务器更新客户端,了解播放器所在的位置 .

    • 客户端更新玩家位置以反映服务器的世界状态 .

  • 0

    您不能依赖客户传递真实信息 . 有人会破解协议并作弊 . 加密数据不会阻止这一点 - 只是让它变得更难 .

    客户端应仅发送移动请求等,服务器需要检查请求以确保它们不违反游戏规则 . 服务器应该只返回客户端绝对需要的数据 - 你不能依靠客户端来获取一大块世界数据,只过滤掉玩家目前无法观察到的所有内容 . 有人会掌握额外的信息并利用它 .

    如果游戏需要“实时”,那么客户端需要假设服务器将允许移动请求并相应地更新显示 - 如果服务器稍后更正它,则回滚移动 . 在大多数情况下,客户端和服务器都会同意,一切都会顺利进行 . 当客户试图欺骗时他们不会同意(这无论如何都是他们的错) - 或者由于连接不良而导致客户端严重滞后(你可以做的不多) .

  • 8

    您可以通过安装wireshark并查看流量来回答您的问题的一半(使用的传输层协议) .

  • 4

    可能感兴趣:Project Darkstar . 它是一个开源的MMO框架 .

  • 0

    我想你可以通过阅读其他人如何实现这些类型的系统来学习 a lot . 这是徒劳的,我可以指出Tim Sweeney和The Croquet财团的工作

    Tim Sweeney的论文改变了我对编程的看法 . 我不能推荐他们 .

  • 1

    除了作为玩家的观察之外,我不知道任何其他细节,但大多数游戏绝对不会等待服务器回复移动角色,这会破坏用户体验,除非它是基于回合的 . 看起来发生的事情是移动在客户端完成并发送到服务器,然后服务器将这些消息发送给其他玩家 . 至少在魔兽世界中,如果一个玩家滞后,你可能会看到他们仍然向前移动,然后神奇地出现在另一个位置,这告诉我客户端收到的不仅仅是位置数据,还有他们正在移动的方向以及他们移动的方向然后在没有进一步数据的情况下推断运动 .

  • 1

    你最好的选择可能是看一下Planeshift的网络代码,它是一个开源的MMO . 我相信这是在现场最发达(最后我检查) .

  • 1

    我不认为对这个问题有一个简短的单一答案,它的范围很广 . 还有几点:

    • 有's no need to 1813340 just because you'重新使用UDP . 根据我的经验,UDP在大多数情况下都是点对点的 .

    • 它's perfectly possible to do your own 1813342 communications over UDP, you don' t必须使用TCP . 这不是神奇的,只是......聪明而复杂 . :)但在大多数情况下,正如你所暗示的那样,TCP不适合游戏中的实时通信 .

    • 有一些方法可以使TCP更合适,例如搜索"Nagle algorithm" .

    • 如果你已经在它上面推出了自己的无损传输协议,你可以通过UDP进行聊天 . 许多游戏都是这样的 .

    在Gamasutra有关于网络的文章,但我现在没有任何方便的链接 . 不确定他们是否仍然公开可用,对不起 .

相关问题