Unity游戏开发之网络游戏中服务器端Server与客户端Client分别处理哪些事

 

本篇unity3d教程,我们来探讨下unity网络游戏中服务器端Server与客户端Client职责,分别处理哪些事,根据情况不同,客户端做的事情都有不同。服务器至少要做验证。相对于网络游戏来说,数据传输量在一定程度上可以忽略,而更注重数据来回时间。在一般情况下,比如说WOW里面,200MS延迟就开始变黄。也就是说在一般对时间要求不是很极端的,比如KOF97转到MMO,200可以默认为一个普通MMO的标准线。
具体来说,理想上的网游,个人倾向于所有逻辑处理全放服务器端,而客户端就像个媒体播放器。这是因为如同某本书讲得,客户端是掌握在对手手中,如果你让服务器只起到数据交换作用,那么外挂就可以彻底糟蹋你的游戏。
在理想基础上,客户端要做的事就是表演,根据服务器和用户的输入处理,进行各种场景、动作与特效的播放。包括绘制角色(动态物件)、绘制场景(相对静态物件)、绘制光照、物件、光照排序、动态物件动画的播放。
当然这是基于理想基础之上的,实际上的制作会有很多变化。比如休闲游戏,因为它要求响应比较迅速(比如泡泡堂,加速后的角色跑起来的速度飞快,你怎么保证其他客户端能够实时看到对方所在位置。不然就炸不到了),所以在这种需求之下,客户端开始承接更多的活计,比如客户端不单是播放功能,还加上了判断,先执行了客户端的判断去追求表演的流畅性。当然,为了安全,最后数据一样要通过服务器端验证,验证不通过就纠正回来。又因为纠正很粗暴,所以现在还开始增加一些纠正机制,让纠正的过程看上去柔和些,比如WOW里面,有时候你会看到其他怪物或角色拖着速度线飞快的移动到其他地方,那就是柔和纠正机制。
用具体事例来说,举个例子:聊天。一个游戏如此设定,一个玩家当使用“当前频道”时,只能让周围50米的玩家收到。
于是。玩家A输入了一堆话,这个时候客户端接收,并立即发送到服务器端。

服务器端固定周期处理一次所有聊天信息,比如200毫秒,客户端送到的时候,正好上一个200毫秒过去了,于是排在下一个200毫秒的队列里。这个时候任何客户端是没办法看到聊天信息的,包括A端(假定是这么设定的,这个就是有的时候你网络卡的时候,明明按了回车,对话框却不冒出任何聊天信息的原因)。
时间在流逝,服务器开始跑队列,并跑到这个地方了,于是它开始运算,第一是判断这句聊天对话是当前频道、世界频道还是其他,判定结果是当前,于是执行当前频道的处理:读取这个玩家所在位置,搜索这个位置方圆50米的其他玩家,向这些玩家包括A端广播聊天信息(假如还有黑名单功能,还要剔除黑名单玩家;假如付费用户字体还有特殊颜色,还要传播这个对话的风格)。
所有客户端收到信息,然后再聊天频道里播放这条信息。于是大家都看到了。
而基本上这整个过程,包括玩家位置信息,包括玩家聊天内容,大小不可能超过1KB,就算是加密后。也就是这种数据量在正常情况下是可以忽略的。这个也是一般网络游戏的传输数据量标准。更重要的是两个参数,第一玩家信息包传送到服务器并由服务器返回的时间;第二服务器处理事件的周期。
而除了UI位置这些琐碎无关于角色的信息,其他信息都应该保存在服务器端。保存在客户端的应该是资源,包括角色模型、动画、场景、特效等,部分游戏也将大量文本保存在客户端,比如任务对话。而重要信息,特别是任何将对自己或其他玩家有影响有改动的信息都应该放在服务器端。比如角色的经验、甚至比如你接到的任务(如果你保存在客户端,你换台机,以前接到的任务就都没了)。
至于客户端向服务器端什么时候发送消息,多少频率,那一般是个长连接,只要信息量没超过KB,影响都不太大。实际上,只要你登录以后,服务器端和客户端就一直在相互通信。哪怕你不动,服务器都会因为你有可能接受到聊天信息而不停的给你塞消息。所以这个还是让程序去头疼,他们是专业。
事情大体上就是这样。好了,本篇unity3d教程到此结束,下篇继续!