1 / 4
文档名称:

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

格式:doc   大小:39KB   页数:4页
下载后只包含 1 个 DOC 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

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

上传人:花开一叶 2018/10/29 文件大小:39 KB

下载得到文件列表

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

相关文档

文档介绍

文档介绍:网络游戏中服务器端与客户端分别处理哪些事情
用具体事例来说,举个例子:聊天。一个游戏如此设定,一个玩家当使用“当前频道”时,只能让周围50米的玩家收到。
于是。玩家A输入了一堆话,这个时候客户端接收,并立即发送到服务器端。
服务器端固定周期处理一次所有聊天信息,比如200毫秒,客户端送到时候,正好上一个200毫秒过去了,于是排在下一个200毫秒的队列里。
这个时候任何客户端是没办法看到聊天信息的,包括A端(假定是这么设定的,这个就是有的时候你网络卡的时候,明明按了回车,对话框却不冒出来任何聊天信息的原因)。
时间在流逝,服务器开始跑队列,并跑到这个地方了,于是它开始运算,第一是判断这句聊天对话是当前频道,世界频道还是其他,判定结果是当前,于是执行当前频道的处理:读取这个玩家所在位置,搜索这个位置方圆50米的其他玩家,向这些玩家包括A端广播聊天信息(假如还有黑名单功能,还要剔除黑名单玩家;假如付费用户字体还有特殊颜色,还有传播这个对话的风格)。
所有客户端收到信息,然后在聊天频道里播放这条信息。于是大家都看到了。
具体来说,理想上的网游(当然还包括股票交易是这种类型),个人倾向于所有逻辑处理全放服务器端,而客户端就像个媒体播放器。
这是因为如同某本书讲得,客户端是掌握在对手中,如果让你服务器只起到数据交换作用,那么***就可以彻底糟蹋你的游戏。
在理想基础上,客户端做的事就是表演,根据服务器和用户的输入处理,进行各种场景,动作与特效的播放。包括绘制角色(动态物件),绘制场景(相对静态物件),绘制光照,物件,光照排序,动态物件动画的播放。
当然这是基于理想基础之上的,实际上的制作会有很多变化。
比如休闲游戏,因为它要求响应比较迅速(比如泡泡堂,加速后的角色跑起来的速度飞快,你怎么保证其他客户端能够实时看到对方所在位置。不然就炸不到了),所以这种需求之下,客户端开始承接更多的活计,比如客户端不单是播放功能,还加上了判断,先执行了客户端的判断去追求表演的流畅性。
当然,为了安全,最后数据一样要通过服务器验证,验证不通过就纠正回来。又因为纠正很粗暴,所以还开始增加一些纠正机制,让纠正的过程看上去柔和些,比如WOW里面,有时候你会看到其他怪物或角色拖着速度线飞快的移动到其他地方,那就是柔和纠正机制。
根据情况不同,客户端做的事情都有不同。
服务至少要做验证。
网游一般来说数据传输量是几KB每秒呢?
答:
相对于网络游戏来说,数据传输量在一定程度上可以忽略,而更注重数据来回时间。在一般情况下,比如说WOW里面,200MS延迟就开始变黄。也就是说在一般时间要求不是很极端的,比如KOF97转到MMO,200可以默认为一个普通MMO的标准线。
而基本上这整个这个过程,包括玩家位置信息,包括玩家聊天内容,大小不可能超过1KB,就算是加密后,也是这种数据量在正常情况下是可以忽略的。这个也是一般网络游戏的传输数据标准。跟重要的是两个参数,第一玩家信息包传送到服务器并服务器返回的时间;第二服务器处理事件的周期。
而除了UI位置这些琐碎无关于角色的信息,其他信息都应该保存在服务器端。
保存在客户端的应该是资源,包括角色模型,动画,场景,特效等,部分游戏也将大量文本保存在客户端,比如任务对话。
而重要信息,特别是任何将对自己或其他玩家有影响有