分类目录归档:网络编程

[译]帝国时代中的网络编程

原文地址:

1500 Archers on a 28.8 Network Programming in Age of Empires and Beyond

概述

本文解释了在制作帝国时代1&2多人(网络)游戏中使用的设计架构,实现及经验,另外讨论了Ensemble Studios在他的游戏引擎中使用的当前及未来的网络方案。

帝国时代多人游戏:设计目标

在1996年早期帝国时代网络代码开始编写的那个时候,为了实现设想中的游戏体验,我们不得不面对了很多特定的任务。

  • 大量单位参与的历史史诗级战役
  • 支持8个玩家多人游戏
  • 确保平滑的模拟,无论是基于局域网,modern还是互联网
  • 支持目标平台:16MB Pentium 90 with a 28.8 modem
  • 通讯系统需要与现有的游戏引擎协同工作
  • 在最低的机器配置中仍能保持统一的15fps

Genie引擎运行良好,并且逐渐给予了单人玩家一个引人注目的游戏体验,Genie引擎是一个2d单线程游戏引擎,精灵图片绘制成256色,世界基于网格建立而成,随机生成的地图填满了成千上万的物体,从被砍伐的树木到跳跃的羚羊,对该引擎的主要运行任务粗略分解后(优化后)是这样的:30%的图形渲染,30%的ai及寻路,30%的运行逻辑。

在早期阶段,引擎已经很稳定,多人通讯需要工作于已经存在的代码,而非对已经存在的架构重新进行编码。

让事情更加复杂的是完成每个模拟步的时间有很大的不同:如果用户查看单位,滚动或者位于未探索的地形中,渲染时间会改变,另外Ai层面的大型的路径或者战略规划,都会使得游戏游戏回合波动相当的大(200ms左右)。

简单的一些快速计算就可知道,仅仅是传输一小撮单位的数据并保持实时更新,就会严重的限制与玩家交互的单位及物体的数量,即使仅传输x,y坐标,状态,动作,朝向及伤害,顶多也只能保证游戏中的移动单位到250个。

而我们想要做的是使用弩车,弓箭手,战士摧毁一个希腊城市,而同时它也被海上的战船围困,很明显,我们需要其他的方案。

同时模拟

相比于在游戏中传输所有单位的状态,我们更期望的是在每台机器运行同样的结果,在同一个时间传送每一个完全相同的指令集到每一台机器,pc们将会基本同步他们的游戏世界,允许玩家发布命令,然后用同样的方式,在同样的时间运行同样的命令,然后获得完全一致的游戏结果。

这种棘手的同步方案难以刚开始的时候就运行良好,但是确实相比其他方面有突出的优势。

改善基本模型

在最简单的概念层面,实现一个同时模拟似乎是相当简单,对于一些游戏来说,使用锁帧模拟及固定游戏时间甚至是直接可行的。

虽然这个方法能同时解决移动成千上万物体的问题,这个方案依旧需要面对互联网20到1000毫秒的延迟,及每帧处理的时间中解决这些变化。

发送玩家的指令,获取所有的消息,然后在进入下次回合前处理他们,这些导致的启停或者缓慢的指令周期,将会成为可玩性的梦魇,我们需要一套在后台等待通讯的同时继续处理游戏逻辑的方案。

Mark使用了一个标记命令系统,每条指令都将在两个通讯回合后执行(通讯回合在帝国时代中从实际的渲染帧中被分离出来)。

1

所以在回合1000运行的命令将会预定在1002回合中被运行(见图1),回合1001运行的是回合0999的命令,这样就能允许消息在被接收,确认及准备运行的阶段,游戏仍然在动以及运行游戏模拟。

回合通常设定为200ms,将这个回合中的所有命令发送出去,200ms后,回合结束,另外下一个回合开始,在游戏的任何时间,仅仅会执行一个回合的命令,接收及存储下一回合的命令,以及发送未来两个回合后的命令。

速度控制

由于模拟必须总是拥有相同的输入,游戏实际上只能与最慢的机器运行的一样快,速度控制就是我们可以动态改变回合的长度,为了在通讯延迟及处理速度不一致的情况下,保证动画及玩法更为平滑。

  • 如果一台机器掉帧,而其他的机器将会处理他们的命令,渲染分配时间的所有东西,然后继续等待下一个回合,哪怕是微小的停顿都会立即注意到;
  • 通讯延迟,由于网络延迟及丢包也会让玩家需要等待足够的数据包来完成本次回合。

每台客户端计算一个平均帧率,他被统一的计算为若干帧的平均处理时间,由于随着游戏的进程,视角,单位数量,地图大小及其他因素都会被改变,所以这个数据将会在本次回合结束的消息包中被捎带上。

每台客户端也会定期的测量它与其他客户端一个往返的响应时间,他将会发送与其他客户端的最长的平均响应时间到回合结束的消息包中(总共两个字节被用在速度控制中)。

绘图1

每个回合,被指定的主机将会分析回合结束的消息包,计算出一个目标帧率及网络延迟的调节因素,主机将会发送一个新的帧率及通讯回合长度给所有客户端使用,图3到图5显示了通讯回合在不同条件下的分解情况。

QQ截图20150827193001

通讯回合粗略的预估为一个消息往返的响应时间(RTT),这个响应时间分分解了若干的模拟帧,执行这些模拟帧的时间需要在最慢的机器中也能完成。

通讯回合的时间跨度会被加权,这样才能保证在网络延迟时动态变化,慢慢趋向于一个可以保证游戏持续的最佳稳定速度。游戏只会在最糟糕的峰值出现停顿或者减缓)——命令延迟将会上升,但是保持平滑(每回合进调整少量的毫秒数)以逐渐调整到最好的游戏速度。这个方案给予了适应环境变化的同时提供最平滑的游戏体验。

保证送达

网络层使用了UDP,因而命令顺序,丢包检测及重传在每个客户端自行处理,每个消息使用了一系列字节用来标示即将被运行的回合数及每个消息的序列号,如果一个需要被之前回合数被执行,他会被丢弃,否则将会存储给将来的回合运行,由于UDP的性质,Mark假定消息接收规则为“当消息被怀疑的时候,就丢弃它“,如果一个消息不是按顺序被接收,接收方会立即发送一个重传请求给被丢弃的消息,如果一个确认包比预期的晚送达,发送方会预期到这个消息可能已经丢失,重新发送这个消息包,而不需要接收方请求。

潜在的好处

由于游戏的结果取决于所有玩家运行同样的结果,所以修改及欺骗客户端变为极其困难,任何不同的模拟结果都会被标记为“不同步“,然后游戏停止,当然,欺骗本地客户端用来显示更多的信息还是可能的,但是这些轻微的问题相对来说很容易处理,可以由后续的补丁及修订版本修复,安全上无形中已经获得了巨大的胜利。

潜在的问题

起初看起来,让两块相同的代码运行相同的结果应该是相当容易及直接的,然而事实并非如此,微软的产品经理Tim Znamenacek在很早的时候就告诉Mark:“在每个项目中,总有一个顽固的错误影响了所有的地方——我想“不同步”就是这个顽固的问题。“, 他是对的,找出不同步错误的困难点在于每个微小的差异都会随着时间不停的被放大,一只小鹿在生成地图的时候轻微的不对齐,都会导致搜寻饲料的时候有轻微的不同,然后几分钟过去后,村民的路径也会有轻微的偏差导致他的长矛可能会刺不中,然后回家的时候没有食物,所以当由于不同的食物数量的校验和不同时,有时候你很难追溯到造成该问题的本源。

我们差不多校验了世界,物体,寻路,目标及其他所有系统,但似乎总有一些事情被漏掉,巨大的消息(50MB)追踪及世界物体转存进行筛选让这个问题愈发困难,部分的困难是概念上的——程序员们不习惯于编写某些代码,比如不得不使用同样数量的调用来随机游戏模拟。(是的,随机数种子也需要同步)。

我们获得了哪些经验?

我们在开发帝国时代的多人游戏中,获得了一些重要的经验,这些经验也适用于开发其他游戏的多人系统。

了解你的用户。了解用户的期望对于多人游戏的性能,感知延迟及命令延迟至关重要,每个游戏类型都是不同的,你需要理解哪些东西对于你特定的玩法及控制是正确的。

在开发的早期,Mark与主设计师坐在一起,原型化了通讯延迟(这个是贯穿我们开发阶段不断重试的部分),从单人游戏出发,很容易模拟不同区间的命令延迟来获取玩家反馈,什么时候感觉正确、缓慢、急促或者很糟糕。

对RTS游戏而言,250毫秒的命令延迟并不会被察觉,250至500毫秒延迟是可玩的,而大于500毫秒延迟开始能被玩家察觉到,这里也有件有趣的事情值得注意,玩家会自行脑补出一种“游戏节奏”,这是当他们点击直到获得响应精神期望上的延迟。一个始终如一的慢响应比一个忽快忽慢的命令延迟好得多(比如80到500毫秒的延迟),在这个例子中,保持在500毫秒延迟更可玩,而变化的延迟会感觉很卡且难以使用。

实际上这导致了大部分的编程重点转移在了平滑上——选择一个的更长的回合长度肯定会比尽快运行加上一些偶然的减慢更一致也更平滑。任何速度上的改变都应该逐渐缓慢的改变。

我们也计算过系统上玩家的主要数据——他们平均每1.5到2秒的时间发布一次命令(移动,攻击,砍树),在剧烈的战斗中,会提升到每秒3到4个命令的峰值,由于我们游戏的行为是逐渐复杂起来的,所以最大的通讯需求往往在游戏的中后期。

当你花时间学习你的用户行为时,你将会注意到他们怎么玩游戏,这将会帮助你处理网络问题,在帝国时代中,当玩家兴奋的攻击时,他会不停的点击,这些行为会每秒发布非常多的命令,造成短暂的峰值,如果他们对一个巨大的群组进行寻路是,也会产生巨大的网络峰值需求。一个简单的过滤器可以丢弃在同一个位置的重复性命令,这样能大幅度的减少这个行为的影响。

总之,观察用户行为可以帮助你:

  • 明白玩家的延迟期望
  • 尽早原型化多人游戏的部分
  • 观察会影响多人游戏性能的行为

测量为王

你将会发现一个令人惊讶的事情,如果你更早的将测量数据对外,使得测试者可以看到该数据,可以帮助他们理解网络引擎底层所做的事情。

经验:当Mark过早的将测量数据移除,在最终代码加入后,一些帝国时代的通讯问题无法重新校验消息(长度及频率)层级,无法检测一些问题,比如偶然性的AI竞争条件,困难的计算路径,不良的结构命令包在一些被调优过的系统将造成巨大的性能问题

当越过一些边界条件的时候,你的系统是否会通知测试者及开发者?——当开发过程中某项任务对系统产生压力的时候,程序猿及测试人员将会观察到,并在早期就让你知晓,进而去做某些处理。

花些时间对你的测试人员进行一些培训,帮助他们理解你的通讯系统如何工作的,另外暴露及解释一些主要的测试数据给他们——当网络代码不可避免的遇到一些奇怪的错误时,你可能会受益于他们的一些发现。

总之,你的测量数据应该:

·对于测试人员更加可读及易于理解

·暴露瓶颈,速度降低及问题

·不占用太多性能,并保持运行

培训你的开发者  对于那些习惯于单机游戏开发的开发者,让他们开始思考关于命令发布,接收及处理的分拆,你发布的命令可能并不会发生,或者再几秒后发生,这个很容易忘记。命令必须在发送及接受的时候进行双重检测。

在同步模型中,编程人员也必须认识到,当运行游戏逻辑时,代码必须不依赖于本地因素(比如特定的硬件,设置等)。代码在所有机器上的结果必须匹配,比如游戏逻辑中的随机地形可能导致游戏行为不同(保存及重新生成随机种子负责这个事情,我们需要随机,但是不能改变游戏模拟)。

其他经验教训 这应该是常识——如果你依赖于第三方的网络库(我们这里用的是DirectPlay),编写一个独立的测试环境,检查该库所说的消息包保证抵达,保证包顺序等功能是没有问题的,另外测试该产品在处理消息通讯的时候是否有潜在的瓶颈或者奇怪的行为。

准备好创建模拟程序还有压力测试模拟,我们最终编写了三个不同的小的测试程序,每个测试软件都为了突出不同的问题,比如连接泛滥,同时配对连接,丢失保证抵达的包等。

开发过程中,尽早的用modem测试,并持续这个开发过程(这很痛苦)。因为很难隔离出问题(可能因为ISP,游戏,通讯软件,modem,配对服务或者其他可能的原因导致突然的性能下降),另外当用户习惯于实时的LAN连接速度后,真的不太愿意再使用拨号网络。你需要保证在局域网以及modem连接中投入一样的热情,这很重要。

帝国时代2的改进

在《帝国时代2:帝王世纪》中,我们增加了一些多人游戏的功能,比如游戏录像,文件传输,区域内的持续的状态追踪。我们还优化的原先的多人系统,比如DirectPlay的集成,修改速度控制的bug以及帝国时代1发布之后的一些性能问题。

游戏录像功能是一个本来你偶然发现“我可以用他来进行调试”的功能,后面变成了一个成熟的游戏功能,游戏录像在粉丝网站非常的流行,因为他们允许玩家交换及分析游戏数据,观看有名的对战,还有回看他们玩的游戏。作为一个调试工具,游戏录像非常有价值,因为我们的模拟是确定的,游戏录像与多人游戏的采用同样的方式,游戏录像提供给我们一个不断重试播放特定bug录像的机会,因为录像必须保证每次播放的内容都是一致的。

我们集成了一个区域内的比赛匹配系统,原来一代只能简单的运行多人游戏,在二代中,我们扩展了这个功能,允许增加运行参数控制,并且对数据报告进行存储。虽然没有一个完整的由内而外的系统,但是我们利用了DirectPlay的大厅启动功能,允许这个区域通过游戏前置表格控制某些特定的游戏设置,当游戏开始的时候,锁定这些功能。这允许玩家更好的寻找他们想要玩的游戏。因为他们可以在比赛匹配层看到这些参数,而不是直接进入游戏初始化的等待界面。在后台,我们实现了持久化的数据报告及追踪。我们为区域提供了通用的结构,这些数据在游戏结束之后被提交,这些数据用来记录玩家排名及等级,玩家可以通过区域网站观察到这些数据。

RTS3多人游戏:目标

RTS3是Ensembles的下一代策略游戏的内部代号,RTS3的设计基于成功的帝国时代系列设计理念,另外增加了一系列新的功能及多人游戏需求。

  • 基于帝国一二代的功能集,网络设计需要支持互联网游戏,各式各样大型的地图,数以千计的可控制单位;
  • 3d-RTS3是一个全3d游戏,拥有动画补间及非分面的单位位置及专项;
  • 更多的玩家——可能支持多于8个玩家;
  • TCP/IP支持,56k的TCP/IP互联网连接是我们的主要目标;
  • 家庭网络支持——支持终端用户的家庭网络配置(包含防火墙及NAT设置);

在RTS3早期中,我们做了一个决定,使用与帝国1代2代同样的网络模型——同步模拟——因为RTS3的设计以同样的方式能够发挥这种架构的优势。在一代二代中,我们依赖于DirectPlay来传输数据及会话管理,但是在RTS3中我们决定创造一个核心的网络库,用来作为我们最基础的socket库。

全3d的世界意味着我们不得不对帧频问题及多人游戏的模拟平滑更加的敏感,尽管如此,这也意味着我们的模拟更新时间及帧率更容易出现变化,我们可能需要花费更多的时间用来渲染。在Genie引擎中,单位转向是分面的,动画是帧率固定的——然而突然之间,我们突然被允许进行随意的单位转向以及平滑的动画,这意味着游戏将会对视觉更加的敏感(延迟的效果以及摇摆不定的帧频)。

二代开发完成后,我们想要总结出哪些是最重要的功能——那些预先规划设计还有工具化能对调试时间产生最大帮助的功能。我们也认识到迭代测试对于我们游戏的重要性,所以早早的将多人游戏的部分提到最高优先度。

RTS3通讯架构

6

一个OO的方案,RTS的网络架构是一个强面向对象的方式(见图6),强面向对象的设计抽象化了特定的平台,协议、拓扑结构及系统,有助于我们支持不同的网络配置。特定的协议以及特定版本的网络拓扑结构采用尽可能少的代码。大多数的功能被抽离到了高层的逻辑中。实现一个新的协议,我们仅仅需要扩展那些网络对象,实现特定的网络协议代码(比如Client、Session,这些需要基于不同的协议做不同的处理),系统中的其他对象不需要进行修改(比如Channels,TimeSync等),因为他们仅与Client及Session的高层抽象接口调用。

7

点对点的拓扑结构。Genie引擎支持点对点的拓扑结构(所有的客户端直连其他客户端,星形的网络结构),RTS3我们继续使用这个结构,因为这种结构在使用同步模拟的时候有一些与生俱来的优势。点对点的拓扑结构意味着在一次会话中已连接的客户端是一种星形的配置(见图7)。也就是说,所有客户端都连接了其他所有客户端。这是一代二代采用的设置。

点对点的优势:

  • 减少网络延迟,客户端直连比客户端-服务端-客户端需要更少的往返时间。
  • 没有中心点故障为题-如果客户端掉线(哪怕是主机),游戏还可以继续进行。

点对点的劣势:

  • 更多的活动连接数——意味着更多的潜在失败节点及潜在延迟
  • 没办法支持某些NAT配置

Net.lib 我们设计RTS3通讯架构的目标是适合于策略游戏的系统,但是同时我们也希望他能用来支持我们的内部工具以及我们将来的游戏。为了达到这个目标,我们创建了多层级的架构,它能够支持游戏级别的对象,比如Client或者Session,也能支持底层级的传输对象,比如一个链路或者一个网络地址。

RTS3基于我们的次时代BANG!引擎创建,该引擎是一个模块化的架构,由各种组件组成,比如音乐,渲染和网络,网络子系统在这里适合作为一个组件添加到BANG!引擎中(同时也是一个内部工具)。我们的网络模型分离为4个不同的服务器层级,看起来有点像,但不完全像OSI网络模型(见图8)。

8

Socks,第一层

第一层,sock层,提供基本的socket c api,它抽象化为不同的操作系统提供通用的底层网络接口,这个接口类似于berkley socket,这个层级的代码主要为更高等级的网络库使用,而不打算用直接在应用层代码。

链接,第二层

链接层提供传输层级的服务,这个层级的对象,比如Link,Listener,NetWorkAddress,Packet代表着用来连接和发送消息的有用对象。

  • Packet:我们的基本消息结构——一个可扩展的对象,它通过link对象发送消息的时候,会自动处理序列化及反序列化(通过纯虚方法)
  • Linker:两个网络终端的连接,这也可以是一个回路(loopback)连接,即两端都为同一台机器,Linker上的Send和Receive方法用来处理消息,另外有个void*的数据缓冲对象
  • Listener:Link生成器,这个对象监听一个连入的连接,当连接完成后生成一个Link对象
  • Data Steam:这个是一个任意长度的数据流,用来通过一个给定的Link——比如用来实现文件传输
  • Net Address:与协议无关的网络地址对象
  • Ping:一个简单的Ping类,用来报告给定Link的网络延迟

多人游戏,第三层

多人游戏层是net.lib api中最高层级的对象,RTS3使用这个层级来组合低等级的api, 比如links为更有用的对象,比如Client或者Session。

在BAND!网络库中最有趣的对象可能就是这些在多人游戏层级的了,以下的API代表了与游戏层级交互的绝大部分对象集。然而实现上我们还是维持与游戏无关的方案。

  • Client:它是最基本的网络节点的抽象,它可以配置为一个远程客户端(Link)或者本地客户端(loopback Link),Clients无法被直接创建,但是可以由Session生成。
  • Session:这个对象用来创建,连接,收集及管理各种Client,Session包含了所有其他多人游戏层级的对象,想使用这个对象的话,应用程序简单的调用host或者join,给它一个本地或者远程地址,然后Session就会处理好剩下的。它的责任包含了创建及销毁Clients,通知Session事件及派发到合适的对象。
  • Channel及Ordered Channel:改对象代表了一个虚拟的消息管道,通过某个Channel发送的消息将会自动的分离及接收到远程节点对应的通道对象上。一个Ordered Channel与TimeSync对象协同工作,保证所有客户端在Channel上收到的消息次序是相同的。
  • Shared Data:代表着通过所有客户端共享的一些数据,你可以扩展这个对象来创建特定的实例(包含你自己的数据类型)。使用内建的方法可以通过网络自动同步更新这些数据。
  • Time Sync:管理在Session中的所有客户端同步网络时间的平滑过程。

游戏通讯,第四层

通讯层级是RTS3游戏逻辑的部分,它主要搜集了游戏与网络库接口的部分系统,他实际上存在于游戏代码中,通讯曾提供了许多有用的工具方法,用来创建及管理多人游戏层级的网络层级的网络对象,另外试图归纳游戏的联网游戏部分为一个易于使用的接口。

新的功能和更好的工具

改善同步系统 在帝国时代开发团队中没有人不需要可能的更好的同步工具,在任何项目中,当你回头整理开发过程的时候,某些区域总是花费你最多的时间,但是如果你做了更多预先的工作会省掉你非常多的时间。同步的调试工具可能是我们在开发RTS3中最重要的工具。RTS3同步追踪系统主要是为了快速定位每轮的同步问题,开发它的其他要点是开发者的使用上的易用性,它能够处理任意巨大数量的同步数据,也能够从发布版中不编入同步的那部分代码,最终能够通过某些变量或者配置文件随意修改这项配置,而不是重新编译。

RTS3的同步检查主要是采用两个宏

#define syncRandCode(userinfo) gSync->addCodeSync(cRandSync, userinfo, __FILE__, __LINE__)

#define syncRandData(userinfo, v) gSync->addDataSync(cRandSync, v, userinfo, __FILE__, __LINE__)

(每个同步“标签”都有一系列sync打头的宏,每个标签代表需要同步的系统,在这里例子中代表的随机数生成器cRandSync)这些宏都带着一个userinfo的字符串参数,这是一个名字或者显示需要同步的描述,比如,一次这样的调用

SyncRandCode(“syncing the random seed”, seed);

同步控制台命令和配置变量

这对于开发过程来说,意义重大(任何Quakemod的创造者都会证实这点)。控制台命令一般是简单的函数调用,可以通过启动配置文件,在游戏的控制台中, 或者UI 的钩子中, 调用任意的游戏功能。 配置变量被称为数据类型,通过简单的get, set, define和toggle 函数,来做各种测试和配置参数。

Paul 扩展了一个支持对人游戏的控制台命令和配置变量系统。我们可以很容易将一个普通的配置变量(例如, enableCheating), 通过添加一个标记, 加入到对人游戏的配置变量。如果使用了这个标记, 在多人游戏中就会传输这个配置变量,同步的游戏进程也会跟这个值有关(例如, 是否允许资源免费)。 多人游戏的控制台命令也是类似的概念: 调用一个多人游戏下的控制台命令, 会传输到网络中的玩家, 并同步执行。

通过应用这两个工具,开发者可以很简单的使用多人系统, 而不用写一行代码。他们能快速的添加测试工具和配置, 并加入到网络环境中。

总结

点对点的网络同步模型,在《帝国》系列游戏中获得了成功。关键之处在于明白花时间在创建工具和技术上的重要性(例如同步和网络测量)。证明了在实时战略游戏上应用这种架构的可行性。后续在RTS3 中做的改进, 保证了多人游戏的体验和单机时几乎没有区别,除非在最烂的网络环境下。

DOOM3网络同步体系

概述

由于doom3是开源的,另外网页上有大量研究doom3的文章,所以分析起来难度比较小,值得注意的是Valve公司旗下的source引擎的基础也是类似这套体系,所以也可以从中得到不少东西,包括他在source sdk上的一些介绍文章,目前的文章还在草稿期,比较乱,后期我再进行整理。

简单的一句话介绍doom3的网络体系就是基于客户端预测及快照的网络同步方式c/s网络拓扑结构udp作为底层网络协议

基本代码分析

相关文件
AsyncClient.*
AsyncServer.*
AsyncNetwork.*
每帧逻辑位于Common::RunFrame
如果是多人游戏,则代码走
idAsyncNetwork::RunFrame();
if (idAsyncNetwork::isActive()) {
     session->GuiFrameEvents();
     session->UpdateScreen(false);
}
单机游戏的话 ,代码走
session->Frame(); // 最终也是调用Game::RunFrame
session->UpdateScreen(false)
idAsyncNetwork::RunFrame()代码中,如果是服务端,则走AsyncServer::RunFrame逻辑,如果是客户端则走AsyncClient::RunFrame()逻辑
AsyncServer::RunFrame最终调用的逻辑是执行Game::RunFrame,另外在代码最后发送了当前的系统快照。系统快照的发送时间限制了最大比特率为 16000 bytes / s 即大概16k每秒,如果上次发送时间与本次发送时间超过了1秒或者小于每秒的比特率,则发送快照及本帧的指令信息(注意这里的指令信息会额外多发送之前的一些指令,因为udp不可靠,另外如果进行重发及验证,还不如每次都额外多发一些)。
AsyncClient::RunFrame的逻辑最重要的是客户端预测的逻辑,客户端预测的在本玩家PVS下的所有实体(玩家,怪物,投射物灯),不仅仅是本地玩家,另外预测是有一个最大预测时长的,默认的预测时间为c->s的延迟时间,预测的本地玩家直接使用的就是当前的操作指令,而其他玩家,使用的是之前的指令,这样的话本地玩家是完全没有延迟反应的。
关于客户端预测的细节,客户端预测的初始值是往返的响应时间,假设为100ms,首次执行的时候,ClientPredictTIme为100ms,gameTimeResidual为16.67ms,假设客户端机器性能非常好,没有任何掉帧,则本次RunFrame会一次性执行 (100 + 16.67) / 16.67 次模拟,及玩家位置会在这帧内多次执行到7帧后的位置(即客户端预测服务端收到包并返回给自己时 ,自己应该处于的位置) ,
下一帧,如果还是没有收到服务器返回,则本次只执行一次,而非多次,因为由于上一帧的预测影响,导致gameTimeResidual已经是负数了。所以本次只累加了16.67ms。
由于出现延迟的下一帧就会移动预测到延迟时间后的游戏时间,之后每帧实际上都也是步进一次,所以实际上并不会出现预测自己的情况出现,只有在第一次会出现一次跳跃。
注意,客户端预测不仅仅是基于之前指令进行计算,同时也发送了本机之后的指令给服务端,否则服务端会一直接受不到最新的指令,毕竟两者之间是有延迟存在的。

攻击相关的本机预测

查看Weapon::Event_LaunchProjectiles可知,目前联机的时候,甚至连投射物都没有做预测播放,投射物的产生以服务端的快照为准,由于doom3是fps游戏,所以攻击流程为player::Weapon_Combat -> weapon::BeginAttack(); ->weapon脚本调用Event_LaunchProjectiles状态,注意整个过程中,人物,武器的动画状态都是预测的,即立即显示出开火的相关状态,但是伤害的投射物及最终伤害都未预测
投射物由服务端快照创建,当投射物遇到障碍物时,预测爆破及特效。
最终的伤害及效果都有player::readFromSnapshot处理,比如当前血量比原来血量少,则播放受击动画,反馈等,如果死亡,则播放死亡。

关于指令及快照的发送及接收

玩家指令,还有快照信息都是通过不可靠的消息传递的
指令包是不管是否有无收到的,默认doom会复制之前的5条指令,因为就算你保证发送成功了,服务端时间也未必恰好用你发的指令进行计算。当有延迟的情况出现时,延迟的客户端会体验发送预测延迟时间内的指令,为了后期恰好给服务端使用。
服务端的指令包及snapshot也不是保证一定收到的,反正如果没收到,收到最新的时候都会从lastsnapshot从头开始计算
所以在doom中不会出现等待的情况,只会回拉

关于平滑拉扯

由于客户端预测的存在,另外客户端并不会等待服务端指令,服务端也不会等待客户端指令,所以整个客户端及服务端都是异步的,这样肯定会出现不一致的情况,这种情况的处理需要做一些平滑,否则感受会比较差,doom3是这么做平滑的。
其他玩家的渲染位置与当前真实渲染位置是会做平滑的,即当前逻辑位置虽然是直接拉到了理想的服务器位置,但是渲染位置用了smooth做了慢慢平滑
代码在 idPlayer::GetPhysicsToVisualTransform
及 idPlayer::ClientPredictionThink均有涉及,这里的平滑只涉及到了其他玩家。
注意渲染位置并不会立即改变,只会每帧改变一次(smoothedOriginUpdated),免得出现位置跳跃。
因为玩家本身的指令应该与服务端的指令几乎是完全一致的,不应该出现偏差,仅当服务端没有收到指令包(因为这里是UDP)超过两次时,才会进行一次平滑到真实位置(因为udp并不可靠)。
另外还有一个平滑是关于玩家的视角,即玩家的那个晃动视角
其他玩家的攻击指令没有做预测

真实主客机的测试

主机无延迟
客机有200ms单向延迟,400ms往返延迟
现象为
在客机屏幕,由于有400ms延迟及客户端预测的存在,所以主机的玩家一旦移动就会出现尽量同步到400ms后的位置,所以一旦开始移动就有个快速拉扯,停止的时候也会回拉。
在主机屏幕,由于延迟为0,所以客户端移动虽然有延迟,但是不会出现加速及回拉的情况。
比较出乎我意料的是,在客机屏幕的客户端预测,居然不会影响到本地玩家,我一直以为本地玩家也会有快速拉扯,实际上完全没有。不管在主机还是客机屏幕,本地玩家的行为都完全正常。
与之前的代码分析完全一致。

使用该做法的游戏

http://dev.dota2.com/showthread.php?t=527&page=7&p=4253&viewfull=1#post4253

dota2这篇论坛上的资料透露, Counterstrike, Left 4 Dead, Team Fortress 2等游戏都采用了该技术,而dota2在此技术的基础上,去掉了客户端预测,减少了拉扯现象,不过玩家的控制信息得不到立即反馈,该文章也是为了解答玩家关于控制延迟的疑问。

网络游戏的移动同步(五)帧同步算法

发了部分移动同步类的文章后,有一些朋友加了我的联系方式,也进行了一些探讨,在这中间,有个朋友跟我聊了另外一种同步方式,即这种帧锁定的变种算法,帧同步算法,基本是思路是这样的。

算法流程

1.服务器同步随机种子,初始帧索引等会造成每个客户端运算不一致的初始数据;

2.客户端发送指令,比如(选中,移动,攻击目标等),指令包含当前帧索引;

3.服务器每隔一段时间(假设是100ms)发送帧更新包,该更新包将客户端逻辑心跳步进,并且处理当前帧索引的指令,当前帧索引步进1;

这里有一些术语需要解释,比如逻辑心跳,大抵的意思就是,比如移动,攻击等比较高层的逻辑行为,而譬如动画等行为不属于逻辑行为。

也就是在这种情况下,因为所有指令都是等到服务器发送的帧更新包才进行处理,所以所有客户端处理的时间线是完全一致的,虽然服务端到每个客户端的时间不一致,但是并不会出现帧卡住的现象,因为哪怕某个客户端没收到更新包,他所看到的屏幕也仅仅是玩家,怪物不移动,而非锁帧。

另外这种处理方式也解决了另外一个问题,就是延迟以最高延迟的客户端为主,这种情况下,服务器是不等待所有客户端的控制指令到达的,到达时间就发送帧步进。

另外,初始我对该同步方式的担忧是担心流量太大,但是仔细考虑了一下,由于发送的协议仅仅是指令,结果的处理完全由客户端模拟,所以少了需要状态同步的协议,而这些状态同步的协议往往非常大,因此这种方式可能整体流量还会少许多。

参考文献

  1. 帧同步在竞技类网络游戏中的应用
  2. 网络层+架构层 : 自研游戏帧同步方案
  3. 「译」Unity3D中实现帧同步 – Part 1

网络游戏的移动同步(四)帧锁定算法

引言

我一直想了解早期游戏的网络同步,特别是早期的很多对战平台,做了很多单机游戏的对战,而这些同步又可以达到很不可思议的效果。从网络上我得知这种方案叫帧锁定,即保证每帧都是一致的。否则就锁定。比如玩dota时出现的万恶的等待框,本篇文章就希望简单的从客户端代码层面模拟这个过程(实际上到最后,我觉得纯粹用客户端模拟还是不足),另外作为整个网络同步系列的最后一个章节。

基本原理

对于单机游戏或者可联网的局域网游戏来说,大部分是没有服务器的,所有的游戏逻辑都放在客户端中处理,这导致的,只要每个用户所给的输入一致,时间一致,就能达到同样的模拟效果,所以帧锁定的基本原理便是如此。

算法流程

1.客户端定时(比如每五帧)上传控制信息。

2.服务器收到所有控制信息后广播给所有客户。

3.客户端用服务器发来的更新消息中的控制信息进行游戏。

4.如果客户端进行到下一个关键帧(5帧后)时没有收到服务器的更新消息则等待。

5.如果客户端进行到下一个关键帧时已经接收到了服务器的更新消息,则将上面的数据用于游戏,并采集当前鼠标键盘输入发送给服务器,同时继续进行下去。

6.服务端采集到所有数据后再次发送下一个关键帧更新消息。

C/S逻辑

客户端逻辑:

1. 判断当前帧F是否关键帧K1:如果不是跳转(7)。

2. 如果是关键帧,则察看有没有K1的UPDATE数据,如果没有的话重复2等待。

3. 采集当前K1的输入作为CTRL数据与K1编号一起发送给服务器

4. 从UPDATE K1中得到下一个关键帧的号码K2以及到下一个关键帧之间的输入数据I。

5. 从这个关键帧到下 一个关键帧K2之间的虚拟输入都用I。

6. 令K1 = K2。

7. 执行该帧逻辑

8. 跳转(1)

服务端逻辑:

1. 收集所有客户端本关键帧K1的CTRL数据(Ctrl-K)等待知道收集完成所有的CTRL-K。

2. 根据所有CTRL-K,计算下一个关键帧K2的Update,计算再下一个关键帧的编号K3。

3. 将Update发送给所有客户端

4. 令K1=K2

5. 跳转(1)

客户端模拟代码

// 如果当前是关键帧
if (Global.frame == keyFrame) {
    // 查看是否有服务器的更新包,当前关键帧编号,下一关键帧编号,所有玩家的控制信息
    // 获取更新包
    var rp:PlayerInputPack;
    while (client.packets.length > 0) {
        rp = client.packets.shift();
        if (rp.frame == keyFrame) {
            break;
        }
    }
    // 如果等不到当前帧的控制数据,则返回
    if (rp && rp.frame == keyFrame) {
        var nextFrame:int = keyFrame + 5;
        // 采集当前的输入作为包发送
        var p:PlayerInputPack = new PlayerInputPack();
        p.frame = nextFrame;
        p.input = InputManager.instance.keyStatus;
        client.send(p);

        // 以rp.input做输入数据
        // 模拟移动本地及网络客户端
        // 每个客户端的逻辑一致
        var players:Array = [localPlayer, netPlayer];
        for each (var player:Player in players) {
            player.velocity.x = 0;
            player.velocity.y = 0;

            if (rp.input[Keyboard.LEFT]) {
                player.velocity.x = -player.speed;
            }
            if (rp.input[Keyboard.RIGHT]) {
                player.velocity.x = player.speed;
            }
            if (rp.input[Keyboard.UP]) {
                player.velocity.y = -player.speed;
            }
            if (rp.input[Keyboard.DOWN]) {
                player.velocity.y = player.speed;
            }
        }

        // 下一个关键帧
        keyFrame = nextFrame;
        waitTime = 0;
    } else {
        waitTime += Global.elapse;

        // 等待太久了,类似魔兽争霸的那个超时面板
        if (waitTime > 1000) {
            trace('等待不到控制包信息', keyFrame);
        }
    }
} else {
    // 当前帧步进
    Global.frame++;
}

// 更新场景
localScene.update();
netScene.update();

演示

Get Adobe Flash player

总结

可以从flash演示中看到,两个场景在低延迟的情况下同步效果非常理想,甚至远远超过之前的客户端预测例子,不过这种做法的缺点就是当延迟过大时会极大的影响控制手感,另外延迟受最慢的客户端影响。

当服务器迟迟没有收到每五帧的所有控制输入时,就会发送通知给所有客户端,出现dota或者war3联网时的那个网络延迟框。在war3中,因为没有专门服务器,所以这个责任是由主机承担的。

对于游戏中的随机元素,则可以在游戏初始化时,由主机同步随机种子到所有客户端中。

参考文献

网络游戏的移动同步(三)平滑算法

引文

本篇文章想解决的是引入航位预测后,预测位置与当前位置出现偏差的平滑处理算法,如第一篇所做的简单跳跃的话,会出现很不舒服的跳跃,这里用一些常用的插值方法解决那些生硬的跳跃。

一些问题

插值平滑就是处理p0插值到p1的问题,但是在游戏中,这难免会出现一些问题,比如我们在处理位置插值时,如何处理p0到p1与碰撞检测系统的冲突?如何选择更为合适的插值方法?

线性插值

我们先选择简单的线性插值,在代码中做如下更改,记录下目标位置,初始位置及时间。

var delta:Number = (getTimer() - rp.time) / 1000;

netPlayer.targetPos = new Vector2().addVectors(rp.position, rp.velocity.clone().multiply(delta).add(rp.acceleration.clone().divide(2).multiply(delta * delta)));
netPlayer.startPos = netPlayer.position.clone();
netPlayer.velocity = rp.velocity.clone();
netPlayer.acceleration = rp.acceleration.clone();
netPlayer.method = 2;
netPlayer.smoothTick = netPlayer.smoothTime = delta;

这里我做了一下比较特别的处理,首先目标位置并不是发来的位置,而是发来的位置加上延迟时间内又移动的距离,所以目标位置稍微远一些,另外平滑时间我设置成于延迟时间相关,所以延迟越大平滑时间越长。

在玩家类中,需要通过平滑计时来判断当前在平滑阶段,还是普通的预测阶段,代码如下。

if (smoothTick > 0) {
    smoothTick -= Global.elapse / 1000;
    var dt:Number = 1 - smoothTick / smoothTime;
    position.x = startPos.x + (targetPos.x - startPos.x) * dt;
    position.y = startPos.y + (targetPos.y - startPos.y) * dt;
} else {
    if (! acceleration.isZero()) {
        velocity.x += acceleration.x * Global.elapse / 1000;
        velocity.y += acceleration.y * Global.elapse / 1000;
    }
    if (! velocity.isZero()) {
        position.x += velocity.x * Global.elapse / 1000;
        position.y += velocity.y * Global.elapse / 1000;
    }
}

从代码中可以看到,位置可以从两个阶段得到,当在插值阶段时,使用的是插值计算出的值,如果不在插值阶段,则为状态计算出的值。最终效果如下。

Get Adobe Flash player

可以看到有了平滑的算法后,网络场景的物体看起来不那么生硬了,不过平滑的时候,你会发现平滑的方向跟速度方向不一致,看起来很不自然。下面的平滑算法会做得更好一些。

立方样条插值

选择使用这种插值方式的原因是,这种插值使得插值路径更加真实,自然,可参加如下图

cube_splines

这里可以看到当前速度,期望最终速度都位移插值路径的最终切线上,与期望值一致。

实现这个插值需要4个坐标值。

坐标1:开始位置(即本地当前位置)

坐标2:坐标1经过一定时间后的位置(速度为当前速度)

坐标4:最终位置(即网络协议发送的最新位置加上一定的延迟时间后的位置)

坐标3:坐标4反向移动一定时间后的位置(速度为网络最新速度)

插值坐标公式为:

x = At3 + Bt2 + Ct + D

y = Et3 + Ft3 + Gt + H

其中

A = x3 – 3x2 +3x1 – x0

B = 3x2 – 6x1 + 3x0

C = 3x1 – 3x0 D = x0

E = y3 – 3y2 +3y1 – y0

F = 3y2 – 6y1 + 3y0

G = 3y1 – 3y0

H = y0

cube_spline2

代码修改

var delta:Number = (getTimer() - rp.time) / 1000;
// 预测点,在延迟时间5倍以后
// 延迟越严重,预测越远
var scheduled:Number = delta * 5;
scheduled = Math.min(scheduled, 0.8);

var pos1:Vector2 = netPlayer.position.clone();
var pos2:Vector2 = new Vector2().addVectors(pos1, netPlayer.velocity.clone().multiply(0.1));
var pos4:Vector2 = new Vector2().addVectors(rp.position, rp.velocity.clone().multiply(scheduled).add(rp.acceleration.clone().divide(2).multiply(scheduled * scheduled)));
var pos3:Vector2 = new Vector2().subVectors(pos4, rp.velocity.clone().add(rp.acceleration.clone().multiply(scheduled)).multiply(0.1));

netPlayer.smoothTick = netPlayer.smoothTime = scheduled;
netPlayer.A = pos4.x - 3 * pos3.x + 3 * pos2.x - pos1.x;
netPlayer.B = 3 * pos3.x - 6 * pos2.x + 3 * pos1.x;
netPlayer.C = 3 * pos2.x -  3 * pos1.x;
netPlayer.D = pos1.x;

netPlayer.E = pos4.y - 3 * pos3.y + 3 * pos2.y - pos1.y;
netPlayer.F = 3 * pos3.y - 6 * pos2.y + 3 * pos1.y;
netPlayer.G = 3 * pos2.y -  3 * pos1.y;
netPlayer.H = pos1.y;

// 插值位置
position.x = A * dt * dt * dt + B * dt * dt + C * dt + D;
position.y = E * dt * dt * dt + F * dt * dt + G * dt + H;

示例

Get Adobe Flash player

加权平均插值

这个在之前的插值介绍中提过,这种插值方式最简单,不需要记录dt,只需要记录期望位置即可。至于具体实现及方案,我将与下面的碰撞检测检测冲突一起给出。

碰撞检测冲突

目前插值的目标都是position,但是如果仅仅是对此值进行插值会存在一些问题,比如position.x = 1,期望位置为position.x = 3,而恰巧position.x = 2的位置是一个障碍点,那插值会导致与碰撞检测代码冲突,这种情况非常容易出现。

我处理这个问题的方案是,插值对象更改,更改为一个修正值modify。而在最终位置的选取上position要加上这个modify,这样插值可以跟碰撞检测规避开。

具体的实现如下

// 设置修正只
netPlayer.modify.x = netPlayer.x - rp.position.x;
netPlayer.modify.y = netPlayer.y - rp.position.y;
//如果位置偏差实在过大,直接跳跃
if (netPlayer.modify.lengthSQ > 50 * 50) {
    netPlayer.modify.set(0, 0);
}
// 注意这里直接设置到了期望位置
netPlayer.position.x = rp.position.x;
netPlayer.position.y = rp.position.y;
netPlayer.velocity = rp.velocity.clone();
netPlayer.acceleration = rp.acceleration.clone();

// 玩家更新代码
var smoothFactor:Number = 0.075;
// 修正值平滑
modify.x *= (1 - smoothFactor);
modify.y *= (1 - smoothFactor);

// 显示位置
x = position.x + modify.x;
y = position.y + modify.y;

这个很酷的方案最终效果如下

Get Adobe Flash player

这种方案的好处是更新过程不需要区分插值过程与预测计算过程,也不需要记录dt,代码显得比较间接,过渡相对比较平滑,不会与游戏其他系统相互冲突。

停止的不自然

之前的例子因为都有延迟波动的影响,所以停止过程经常出现不舒服的回拉,这个解决方案比较简单,如果停止时位置波动在某个阈值内,则不进行插值平滑即可。

最终效果全集

Get Adobe Flash player

参考

网络游戏的移动同步(二)状态更新及航位预测法

引言

前一篇文章将基本的网络同步例子制作出来,虽然还有很多问题,但是我们已经在网络问题很简易的摆放在我们面前,不需要经过服务器,就可以简单的模拟经常出现的网络延迟现象,那对于之前演示的问题,如何解决呢?今天就解决第一步,发包的问题。如果能够节省发包量?

状态更新

因为每个客户端都有自己的逻辑运算,所以我们很明显的就可以想到,只需要在状态更新时发送即可,对于一般的游戏这个方案都可以解决,比如我们修改速度的时候,游戏点击目标点的时候,这些时间点发送即可,对于之前的例子,我们只需要做如下判断就可以节省大量的通讯量。

// 获取输入
// 在通过键盘获取输入更新最新速度前
var lastVelocity:Vector2 = localPlayer.velocity.clone();
var lastAcceleration:Vector2 = localPlayer.acceleration.clone();

if (lastVelocity.x != localPlayer.velocity.x ||
    lastVelocity.y != localPlayer.velocity.y ||
    lastAcceleration.x != localPlayer.acceleration.x ||
    lastAcceleration.y != localPlayer.acceleration.y) {
    update = true;
}

if (update) {
    var p:PlayerStatePack = new PlayerStatePack();
    p.velocity = localPlayer.velocity.clone();
    p.position = localPlayer.position.clone();
    p.acceleration = localPlayer.acceleration.clone();
    p.time = getTimer();
    client.send(p);
}

我们再看现在的demo,通讯量明显下来了,而且网络场景走得也不差。

Get Adobe Flash player

当然,这个方案也是有其局限性的,比如如果加速度存在的话,那速度每时每刻是不一样的,所以发包频率还是非常频繁,还有一种更极端的情况,如果你加入了物理引擎,或者使用了自治智能体,此时连加速度都每时每刻在变化的,有没什么更好的方式来优化通讯量呢?下面引出下一个优化方案,航位预测法(DeadReckoning)。

航位预测法(DeadReckoning)

这种算法比较的主要是位置,而非上面的速度以及加速度,所以从通用性上来说,会好很多。具体的细节为,当本地个体与记录的上次本地个体(即其他网络场景看到的自己)的位置超过某个阈值,则发送更新状态包,当此阈值越小,则发送包频率越快,此阈值越大,则发送包频率越慢,也越节省。

基本的原理可参考如下图(从网络获取)

dr

基本实现代码如下

// dr位置
var drPosition:Vector2 = new Vector2();
if (lastState) {
    var e:Number = (getTimer() - lastStateTime) / 1000;
    // s = v0t + 0.5 * a * t^2;
    drPosition.addVectors(lastState.position, lastState.velocity.clone().multiply(e).add(lastState.acceleration.clone().divide(2).multiply(e * e)));
}
// 阈值
var threshold:Number = 5 * 5;
if (localPlayer.position.distSQ(drPosition) > threshold) {
    update = true;
}

代码很简单,就是牛顿力学的内容,位移,加速度,速度的公式,然后算出dr位置(即网络位置),如果超过阀值,则发送更新包,另外记录上次发送状态(为了计算下一次dr位置)。

演示如下

Get Adobe Flash player

应用

在游戏中,状态更新及航位预测可混合使用,如在键盘更新时,即可将状态更新包发出,而非一定要等到位置偏移超过一定值,这样网络网络场景看到的会更即时些。本章将发包的问题解决了,但是你可以在演示中看出,当网络延迟波动较大时,网络场景的物体拖拉很生硬,因为我们直接设置了网络场景的位置到了当前位置,下一部分介绍如何用插值平滑将网络延迟做进一步的遮掩。

参考文献

网络游戏的移动同步(一)网络同步演示

引言

网络游戏的同步处理是在制作网络游戏中独有的处理方案,现在网络游戏几乎都是C/S架构,也就是说需要同步其他主机发送给服务器,并转发回本机的包,这里就涉及到如何发包给服务器,发哪些包,另外就是接收到这些包之后,客户端如何处理这些包的问题。

在不进行示例之前,如果简单的思考一下这些问题,一般人都会想到的是,其实只需要发布初始状态,然后每次变更发送更新状态即可。为了使这个问题简单化,本文的处理主要是移动同步,这个也是最常见,并且包量最大的一个协议,下面我们先创建这个更新包。

简单的更新协议

public class PlayerStatePack
{
	public var velocity:Vector2;
	public var position:Vector2;
	public var acceleration:Vector2;
	public var time:uint;
}

3个2维向量分别是位置,速度,加速度,此示例以2维为主,一般游戏可能用加速度比较少一些,但是为了更好的模拟更多的游戏,比如一些赛车或者炮弹之类的,这里的更新包中还有加速度。时间是发送包的时间,加这个主要是为了接收方能预知此时的真实位置。因为接收到的时候,发送方实际已经不在那个位置。

虚拟服务器

为了在客户端中直接模拟服务器延迟,可以直接做个简单的类模拟延迟。

public class Client
{
	// 模拟收到的网络包
	public var packets:Vector.;

	public function Client()
	{
		packets = new Vector.();
	}

	public function send(p:PlayerStatePack):void {
		// 延迟加入队列
		var delayTime:int = MathUtil.rand(Global.delay - Global.range, Global.delay + Global.range);

		setTimeout(sendNow(p), delayTime);
	}

	private function sendNow(p:PlayerStatePack):Function
	{
		return function():void {
			packets.push(p);
		}
	}
}

类的功能很简单,就是发送的时候增加setTimeout,另外这里有两个配置量,延迟量以及延迟波动量,这两个即可比较好的模拟出真实的网络环境,接收方处理的时候,直接从packets数组中获取包处理即可。

第一次尝试

假设这是一个简单的键盘移动游戏,因为鼠标移动同步相对比较简单,甚至于包都可以不需要那么复杂,只需要目标点就可以。
我们开始写发送及接收处理的代码。主循环代码如下

// 一般的线性移动
localPlayer.velocity.x = 0;
localPlayer.velocity.y = 0;
if (InputManager.instance.keyDown(Keyboard.LEFT)) {
	localPlayer.velocity.x = -localPlayer.speed;
}
if (InputManager.instance.keyDown(Keyboard.RIGHT)) {
	localPlayer.velocity.x = localPlayer.speed;
}
if (InputManager.instance.keyDown(Keyboard.UP)) {
	localPlayer.velocity.y = -localPlayer.speed;
}
if (InputManager.instance.keyDown(Keyboard.DOWN)) {
	localPlayer.velocity.y = localPlayer.speed;
}
// 发送协议
var p:PlayerStatePack = new PlayerStatePack();
p.velocity = localPlayer.velocity.clone();
p.position = localPlayer.position.clone();
p.acceleration = localPlayer.acceleration.clone();
p.time = getTimer();
client.send(p);

while (client.packets.length > 0) {
	var rp:PlayerStatePack = client.packets.shift();
	// 直接拉扯
	if (smoothMethodCb.selectedIndex == 0) {
		netPlayer.position.x = rp.position.x;
		netPlayer.position.y = rp.position.y;
		netPlayer.velocity = rp.velocity;
	}
}

// 更新场景
localScene.update();
netScene.update();

看这个简单的游戏主循环,主要的流程是获取输入->本地玩家更新->发送更新包->接收更新包->处理游戏逻辑。为了使整个游戏代码清晰,我清理了不太需要的细节代码。

这个简单的网络同步演示如下

Get Adobe Flash player

这个演示明显有几个问题,比如发送包太频繁(停止也在发送,因为是每帧发送),另外接受包的处理也很生硬,当网络延迟波动过大,拉扯现象非常明显。