游戏开发中服务端与客户端的分工.docVIP

网络游戏中服务器端与客户端分别处理哪些事情 用具体事例来说，举个例子：聊天。一个游戏如此设定，一个玩家当使用“当前频道”时，只能让周围50米的玩家收到。 于是。玩家A输入了一堆话，这个时候客户端接收，并立即发送到服务器端。 服务器端固定周期处理一次所有聊天信息，比如200毫秒，客户端送到时候，正好上一个200毫秒过去了，于是排在下一个200毫秒的队列里。 这个时候任何客户端是没办法看到聊天信息的，包括A端（假定是这么设定的，这个就是有的时候你网络卡的时候，明明按了回车，对话框却不冒出来任何聊天信息的原因）。 时间在流逝，服务器开始跑队列，并跑到这个地方了，于是它开始运算，第一是判断这句聊天对话是当前频道，世界频道还是其他，判定结果是当前，于是执行当前频道的处理：读取这个玩家所在位置，有哪些信誉好的足球投注网站这个位置方圆50米的其他玩家，向这些玩家 包括A端广播聊天信息（假如还有黑名单功能，还要剔除黑名单玩家;假如付费用户字体还有特殊颜色，还有传播这个对话的风格）。 所有客户端收到信息，然后在聊天频道里播放这条信息。于是大家都看到了。 具体来说，理想上的网游（当然还包括股票交易是这种类型），个人倾向于所有逻辑处理全放服务器端，而客户端就像个媒体播放器。 这是因为如同某本书讲得，客户端是掌握在对手中，如果让你服务器只起到数据交换作用，那么外挂就可以彻底糟蹋你的游戏。 在理想基础上，客户端做的事就是表演，根据服务器和用户的输入处理，进行各种场景，动作与特效的播放。包括绘制角色（动态物件），绘制场景（相对静态物件），绘制光照，物件，光照排序，动态物件动画的播放。 当然这是基于理想基础之上的，实际上的制作会有很多变化。 比如休闲游戏，因为它要求响应比较迅速（比如泡泡堂，加速后的角色跑起来的速度飞快，你怎么保证其他客户端能够实时看到对方所在位置。不然就炸不到了），所以这种需求之下，客户端开始承接更多的活计，比如客户端不单是播放功能，还加上了判断，先执行了客户端的判断去追求表演的流畅性。 当然，为了安全，最后数据一样要通过服务器验证，验证不通过就纠正回来。又因为纠正很粗暴，所以还开始增加一些纠正机制，让纠正的过程看上去柔和些，比如WOW里面，有时候你会看到其他怪物或角色拖着速度线飞快的移动到其他地方，那就是柔和纠正机制。 根据情况不同，客户端做的事情都有不同。 服务至少要做验证。 网游一般来说数据传输量是几KB每秒呢？ 答： 相对于网络游戏来说，数据传输量在一定程度上可以忽略，而更注重数据来回时间。在一般情况下，比如说WOW里面，200MS延迟就开始变黄。也就是说在一般时间要求不是很极端的，比如KOF97转到MMO，200可以默认为一个普通MMO的标准线。 而基本上这整个这个过程，包括玩家位置信息，包括玩家聊天内容，大小不可能超过1KB，就算是加密后，也是这种数据量在正常情况下是可以忽略的。这个也是一般网络游戏的传输数据标准。跟重要的是两个参数，第一玩家信息包传送到服务器并服务器返回的时间；第二服务器处理事件的周期。 而除了UI位置这些琐碎无关于角色的信息，其他信息都应该保存在服务器端。 保存在客户端的应该是资源，包括角色模型，动画，场景，特效等，部分游戏也将大量文本保存在客户端，比如任务对话。 而重要信息，特别是任何将对自己或其他玩家有影响有改动的信息都应该放在服务器端。比如角色的经验，甚至比如你接到的任务（如果你保存在客户端，你换台机，以前接到的任务就都没了）。 至于客户端向服务器什么时候发送消息，多少频率，那一般是个长连接，只要信息量没超过KB，影响都不太大。实际上，只要你登录以后，服务器端和客户端就一直在相互通信，哪怕你不动，服务器都会因为你有可能接受到聊天信息而不停的给你塞消息。所以这个还是让程序去头疼，他们是专业。 事情大体上就是这样。 但是两者之间的数据是不能忽略的。如果两个人都进入了对方的视野而且做了动作，那服务器就要向每个人发送两个人物的状态数据。同样的，如果视野内有N个人，就要发送N*N个人物状态数据。 有两件事很考验服务器的网络带宽： 视野内有上百人在边跑边放技能。 N多人刷世界频道。 网络游戏的高延迟是由带宽不足引起的数据阻塞造成的。我知道400人在线的RO私服用10Mbps带宽就足以保证不卡，但动辄几千人的网游需要多少带宽还真不好说。 上面的表述还要纠正一下 嗯，量的积累确实是一个问题。 你的例子中：N*M的状态数据，首先，所有状态数据不一定要提前发送，可以即查即发，比如玩家在查看其他人的状态才查得到他的状态，再次，那也是KB档次而已，即使个别漏包都不成问题。 最重要的一点就是无限多人会战，先拖当的必然是客户端。这个例子比较极端了。N多人刷世界频道，那也不是很严重的问题，如果真觉得有压力，可以限制说话间隔。何况这个问题解决还可以通过机