ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 游戏引擎剖析(七)(转)

游戏引擎剖析(七)(转)

原创 Linux操作系统 作者:jcszjswkzhou 时间:2019-03-15 07:21:06 0 删除 编辑
第7部份: 网络和连线游戏环境


网络游戏
  我记得一些年前坐在GDC(游戏开发者大会)听负责开发X-Wing Vs TIE Fighter的家伙们题为“淹没在Internet” 的演讲,全是关于让网络游戏实时地在Internet上工作的东西。他们选择那个题目是多么的正确啊。当它开始处理数据包的丢失,乱序,潜伏(一个数据包发送到它的目的地所花的时间)等等时,它确实淹没了。然而它是可能的。对于Internet需要一些聪明和经验,但它是肯定可能的。看看今天大量的连线游戏,从Quake III,Unreal Tournament,Counter Strike一直到EverQuest和Ultima Online。

  如今大多数真正有长久生命力的游戏都至少有一些连线成分。最纯粹的单人游戏容易玩一次,也许两次,或者甚至三次如果它是非常好的游戏,但一旦游戏结束,就被束之高阁了。如果你想要有任何长久生命力,那么多人连线游戏就是形势的核心所在,并且那意味着和Internet打交道,为编码者打开了那个潘多拉的盒子。

  那么跟Internet打交道包括些什么呢?首先是要理解Internet是怎么工作的,和点对点与客户机/服务器体系结构的快速讨论。点对点就是你在两台机器上运行游戏,并简单地在它们之间共享输入。每个单独的游戏假定它是正确的,并仅仅在它一幀接一幀的刷新中合并来自另外一台机器的输入。客户机/服务器是一台机器有效地运行游戏,别的机器仅仅是一个终端,接受来自玩家的输入,并渲染服务器让它渲染的任何东西。

  客户机/服务器的优点是每台机器都将会展现相同的游戏,因为所有的处理都在一个地方完成,没有跨越多台机器,你可以不用考虑每台机器相互之间的同步问题。不足之处是,服务器本身需要有一些重要的CPU可用时间来处理每一个连接的客户机,和一个合适的网络连接来确保每一个客户机及时地接收到它的更新。


了解IP
  我们都已经听说过TCP/IP(传输控制协议/网间协议)和UDP(用户数据包协议), 在Web网络上有大量关于这些协议的深奥的技术资讯。实际上,在Cisco网站上有一些极好的TCP/IP指导。我们将在较高层面上介绍一些TCP/IP的基本知识,目的是让你更好地了解使用这些标准协议的网络游戏设计者面临的挑战。

  TCP/IP和UDP/IP是两层的通信协议系统。IP层负责网际数据包的传输。UDP或者TCP层将大的数据包传给IP,IP将数据包分割为小的子数据包,为每个数据包加上一个信封,计算出目的地的IP地址,应该如何到达那里,然后将数据包发送到你的ISP,或者不管怎样你连接到网络。 这实在象是在一张明信片上写下你要发送的,贴上邮票,写上地址,塞进一个邮箱,它就送走了。

  UDP和TCP是从你编码者或者游戏接收数据包的高层协议,并决定该如何处理这些数据包。UDP和TCP的区别在于TCP保证数据包的传送和有序,而UDP不保证。UDP是一条直接和IP对话的小路,而TCP是在你和IP之间的一个接口。它像是在你和你的邮件之间有一个管理员助手。使用UDP你会自己为你的信打字,把它们放进一个信封等等。使用TCP你会仅仅向你的管理员口授信稿,管理员会做全部的工作并追踪确认信件送到了。

  然而,所有这些令人惊奇的为你完成的工作伴随着代价。为了确定数据包通过Internet完好无损地送到了目的方,TCP期待从目的方为它发送的每个数据包发回一个应答包(网络用语是ACK)。如果它在一定时间内没有收到ACK,它就停止发送任何新的数据包,重新发送丢失的数据包,并且将继续这样做直到收到目的方的回应。当你访问一个网页时,我们都已经看到了这种情形,在半途中下载停止了一会然后又重新开始了。可能是一个数据包在什么地方丢失了(假定不时ISP的问题),在任何更多的数据包被发送以前TCP要求重新发送它。

  这一切的问题是,在认识到出了差错的发送者和实际上正在送达的数据包之间出现了延迟。有时这能花上数秒钟,如果你仅仅只是下载一个文件或一个网页,这不是什么大碍,但如果这是一个游戏数据包而且每秒至少有十次,那么你真的是遇到麻烦了,尤其是因为它停止了其他一切事情。实际上就是这个问题所以几乎没有游戏选择使用TCP作为它们主要的Internet协议,除非它不是一个实时动作游戏。大多数游戏使用 UDP--他们不能保证有序或可靠送达,但它确实很快—或者结果是至少通常比TCP/IP更快。现在我们了解这些了,接下来呢?


客户端预测
  因为 UDP 明显的是快速响应游戏的方式,我们将必须自己处理数据包的丢失和乱序。边而且这是技巧所在。不用说出太多的代码秘密,我就能说有方法。作为开始,有客户端预言,一个被谈论得相当多的词语。当你作为一个客户端连接到一个大的服务器,但是不能连贯地看见来自服务器的更新,客户端预言开始起作用了。正在你的电脑上运行的游戏部分看着你正给它的输入,并在缺乏来自服务器的任何弃绝信息的情况下,对它认为将继续进行的事情作出‘最好的猜测’。它将会显示被猜测的数据,然后当它得到来自服务器的世界的最新状态时,改正它自己,如果需要。你可能会对这个方法的效力感到惊讶。大体而言,大部分时间数据包不容易丢失—大多数时候是一秒的几十分之一,这种情况下游戏没有太多的时间偏离服务器实际上认为正在发生的事情。偏离确实会随着时间变的比较大,大多数游戏里面有一个超时功能,当出现很长时间没有来自服务器的联络时就停止游戏。

  你正在创造的游戏类型在这里有关系 -- 第一人称射击游戏不需要这样有效的客户端预言,因为它多数情况下仅仅处理“我在哪儿,我是否要射击?”。在第三人称游戏中,你必须更加精确,因此你能够正确地预测你的角色正在播放的动画,并且动作流畅。在这种情形中流畅的动画是完全必要的。Heretic II在这方面有很大的问题,并且是当它开始网络编码时Raven一直不得不处理的最困难的事情之一。

  当然如果你有一个很不错的网络连接,比如宽带连接,那么这个问题就远没有那么重要。对比较大的数据包有一个更宽的管道,对你的网络连通时间更快速。事实上,宽带对于游戏的主要优点不比较胖的管道多,但大大减少了延迟,特别是你到ISP的第一跳上。对于56K 调制解调器,第一跳典型的延迟是100ms,这已经严重地增加了你到网络上任意一台游戏服务器的潜在连通时间。对于宽带连接比如像DSL,第一跳的延迟。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10294527/viewspace-126663/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2007-08-29

  • 博文量
    1354
  • 访问量
    915968