在线网络游戏信息通信实现.docxVIP

  1. 1、本文档共8页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
在线网络游戏信息通信实现

近期完成一个稍稍涉及网络同步的游戏,结合网络上查到的一点资料和自己的心得做个小结。????? 游戏描述:略形象的归纳为地图中5个玩家在5个不同位置消息,地图中有20个道具,玩家选择出发时间,出发角度和出发速度去奔向某道具。现在玩家1向server发消息,准备从当前currposition出发,对应的currtime,currangle,currspeed都确定,假定前方有prop1,现在服务器收到消息currservertime,然后广播玩家1的出发,那么玩家2,玩家3,玩家4,玩家5可能又由于网络原因接收到消息的时间是time2,time3,time4,time5。如果玩家1发出消息时开始绘图,玩家2,3,4,5接收到消息时绘图,这里就会产生一个不同步问题,玩家1和玩家2,3,4,5对应有一个time2,3,4,5-currtime的时间误差。而且中间还可能有5个玩家的本地时间并不相同的情况。????? 首先可以通过服务器验证群发方式解决:玩家1发出消息的时候并不进行绘图,而是挂起等待服务器接收玩家1消息,广播给5位玩家之后大家一起绘图。考虑5个玩家本地时间不同的情况和网络延时时间,我们可以在玩家开始游戏的前进行一个玩家本地时间和服务器时间的误差比较,在服务器和5个客户端记录每个玩家和服务器的时间误差motifytime1,2,3,4,5。在服务器收到出发消息时,根据motifytime1,2,3,4,5确定玩家1,2,3,4,5每个人收到玩家1出发消息的绘图时间。这个方案在网络延迟很大发出消息的玩家会感觉极其不顺。很多并不是很需要及时通信的游戏会采用这种方式。????? 如果玩家1在发出消息时就绘图,也可以通过motifytime方式进行同步,在服务器收到玩家1消息时,通过motifytime1计算出服务器中的玩家1出发时间,进行广播后玩家2,3,4,5根据自己的motifytime2,3,4,5判断接收到消息的时间和服务器发来的时间是否满足motifytime2,3,4,5范围,超出范围则计算出超出的时间,*speed后可以得到实际玩家1已经走到的位置positon1,当然我们可以用一个稍微快一点的speed到达position1后面的一点位置。????? 还有一种好像是目前主流的解决方案,笔者没有实践拷贝网络资料:????? 首先客户端需要在登陆世界的时候建立很多张广播列表,这些列表在客户端后台和服务器要进行不及时同步,之所以要建立多张列表,是因为要广播的类型是不止一种的,比如说有local message,有remote message,还有global message 等等,这些列表都需要在客户端登陆的时候根据服务器发过来的消息建立好。在建立列表的同时,还需要获得每个列表中广播对象的TimeModified,并且要维护一张完整的用户状态列表在后台,也是不及时的和服务器进行同步,根据本地的用户状态表,可以做到一部分决策由客户端自己来决定,当客户端发送这部分决策的时候,则直接将最终决策发送到各个广播列表里面的客户端,并对其时间进行校对,保证每个客户端在收到的消息的时间是和根据本地时间进行校对过的。那么再采用预测拉扯中提到过的计算提前量,提高速度行走过去的方法,将会使同步变得非常的smooth。该方案的优点是不通过服务器,客户端自己之间进行同步,大大的降低了由于网络延迟而带来的误差,并且由于大部分决策都可以由客户端来做,也大大的降低了服务器的资源。由此带来的弊端就是由于消息和决策权都放在客户端本地,所以给外挂提供了很大的可乘之机。????? 基于这种方案的导航Dead Reckoning算法:????? 大家都知道,在网络传输的时候,延迟现象是很普遍的,而在基于Server/Client结构下的网络游戏的同步也就成了很头疼的问题,在保证客户端响应用户本地指令流畅的情况下,没法有效的保证的同步的及时性。首先,这套同步方案是基于客户端之间的同步的。下面我们先来说一些本文中将用到的名词概念:  网状网络:客户端之间构成的网络  节点:网状网络中的每个客户端  极限误差:进行同步的时候可能产生的误差的极值  恩,在探讨其原理的之前,我们先来看看我们需要一个什么样的环境。首先,需要一个网状网络,网状网络如何构成呢?当有新节点进入的时候,通知该网络里面的所有节点,各节点为该客户端在本地创建一个副本,登出的时候,则通知所有节点销毁本地关于该节点的副本。然后每个节点该保存一些什么数据呢?首先有一个很重要的包需要保存,叫做协议数据包(PDU Protocol Data Unit),PDU包含节点的一些相关的运动信息,比如当前位置,速度,运动方向,或者还有加速度等一些信息。除PDU之外,还有其他信息需要保存,比如说节点客户端人物的HP,MP

文档评论(0)

178****9325 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档