Genie引擎运行良好,并且逐渐给予了单人玩家一个引人注目的游戏体验,Genie引擎是一个2d单线程游戏引擎,精灵图片绘制成256色,世界基于网格建立而成,随机生成的地图填满了成千上万的物体,从被砍伐的树木到跳跃的羚羊,对该引擎的主要运行任务粗略分解后(优化后)是这样的:30%的图形渲染,30%的ai及寻路,30%的运行逻辑。 在早期阶段,引擎已经很稳定,多人通讯需要工作于已经存在的代码,而非对已经存在的架构重新进行编码。 让事情更加复杂的是完成每个模拟步的时间有很大的不同:如果用户查看单位,滚动或者位于未探索的地形中,渲染时间会改变,另外Ai层面的大型的路径或者战略规划,都会使得游戏游戏回合波动相当的大(200ms左右)。 简单的一些快速计算就可知道,仅仅是传输一小撮单位的数据并保持实时更新,就会严重的限制与玩家交互的单位及物体的数量,即使仅传输x,y坐标,状态,动作,朝向及伤害,顶多也只能保证游戏中的移动单位到250个。 而我们想要做的是使用弩车,弓箭手,战士摧毁一个希腊城市,而同时它也被海上的战船围困,很明显,我们需要其他的方案。 同时模拟 相比于在游戏中传输所有单位的状态,我们更期望的是在每台机器运行同样的结果,在同一个时间传送每一个完全相同的指令集到每一台机器,pc们将会基本同步他们的游戏世界,允许玩家发布命令,然后用同样的方式,在同样的时间运行同样的命令,然后获得完全一致的游戏结果。 这种棘手的同步方案难以刚开始的时候就运行良好,但是确实相比其他方面有突出的优势。 改善基本模型 在最简单的概念层面,实现一个同时模拟似乎是相当简单,对于一些游戏来说,使用锁帧模拟及固定游戏时间甚至是直接可行的。 虽然这个方法能同时解决移动成千上万物体的问题,这个方案依旧需要面对互联网20到1000毫秒的延迟,及每帧处理的时间中解决这些变化。 发送玩家的指令,获取所有的消息,然后在进入下次回合前处理他们,这些导致的启停或者缓慢的指令周期,将会成为可玩性的梦魇,我们需要一套在后台等待通讯的同时继续处理游戏逻辑的方案。 Mark使用了一个标记命令系统,每条指令都将在两个通讯回合后执行(通讯回合在帝国时代中从实际的渲染帧中被分离出来)。
每台客户端计算一个平均帧率,他被统一的计算为若干帧的平均处理时间,由于随着游戏的进程,视角,单位数量,地图大小及其他因素都会被改变,所以这个数据将会在本次回合结束的消息包中被捎带上。 每台客户端也会定期的测量它与其他客户端一个往返的响应时间,他将会发送与其他客户端的最长的平均响应时间到回合结束的消息包中(总共两个字节被用在速度控制中)。
测量为王 你将会发现一个令人惊讶的事情,如果你更早的将测量数据对外,使得测试者可以看到该数据,可以帮助他们理解网络引擎底层所做的事情。 经验:当Mark过早的将测量数据移除,在最终代码加入后,一些帝国时代的通讯问题无法重新校验消息(长度及频率)层级,无法检测一些问题,比如偶然性的AI竞争条件,困难的计算路径,不良的结构命令包在一些被调优过的系统将造成巨大的性能问题 当越过一些边界条件的时候,你的系统是否会通知测试者及开发者?——当开发过程中某项任务对系统产生压力的时候,程序猿及测试人员将会观察到,并在早期就让你知晓,进而去做某些处理。 花些时间对你的测试人员进行一些培训,帮助他们理解你的通讯系统如何工作的,另外暴露及解释一些主要的测试数据给他们——当网络代码不可避免的遇到一些奇怪的错误时,你可能会受益于他们的一些发现。 总之,你的测量数据应该:
培训你的开发者 对于那些习惯于单机游戏开发的开发者,让他们开始思考关于命令发布,接收及处理的分拆,你发布的命令可能并不会发生,或者再几秒后发生,这个很容易忘记。命令必须在发送及接受的时候进行双重检测。 在同步模型中,编程人员也必须认识到,当运行游戏逻辑时,代码必须不依赖于本地因素(比如特定的硬件,设置等)。代码在所有机器上的结果必须匹配,比如游戏逻辑中的随机地形可能导致游戏行为不同(保存及重新生成随机种子负责这个事情,我们需要随机,但是不能改变游戏模拟)。 其他经验教训 这应该是常识——如果你依赖于第三方的网络库(我们这里用的是DirectPlay),编写一个独立的测试环境,检查该库所说的消息包保证抵达,保证包顺序等功能是没有问题的,另外测试该产品在处理消息通讯的时候是否有潜在的瓶颈或者奇怪的行为。 准备好创建模拟程序还有压力测试模拟,我们最终编写了三个不同的小的测试程序,每个测试软件都为了突出不同的问题,比如连接泛滥,同时配对连接,丢失保证抵达的包等。 开发过程中,尽早的用modem测试,并持续这个开发过程(这很痛苦)。因为很难隔离出问题(可能因为ISP,游戏,通讯软件,modem,配对服务或者其他可能的原因导致突然的性能下降),另外当用户习惯于实时的LAN连接速度后,真的不太愿意再使用拨号网络。你需要保证在局域网以及modem连接中投入一样的热情,这很重要。 帝国时代2的改进 在《帝国时代2:帝王世纪》中,我们增加了一些多人游戏的功能,比如游戏录像,文件传输,区域内的持续的状态追踪。我们还优化的原先的多人系统,比如DirectPlay的集成,修改速度控制的bug以及帝国时代1发布之后的一些性能问题。 游戏录像功能是一个本来你偶然发现“我可以用他来进行调试”的功能,后面变成了一个成熟的游戏功能,游戏录像在粉丝网站非常的流行,因为他们允许玩家交换及分析游戏数据,观看有名的对战,还有回看他们玩的游戏。作为一个调试工具,游戏录像非常有价值,因为我们的模拟是确定的,游戏录像与多人游戏的采用同样的方式,游戏录像提供给我们一个不断重试播放特定bug录像的机会,因为录像必须保证每次播放的内容都是一致的。 我们集成了一个区域内的比赛匹配系统,原来一代只能简单的运行多人游戏,在二代中,我们扩展了这个功能,允许增加运行参数控制,并且对数据报告进行存储。虽然没有一个完整的由内而外的系统,但是我们利用了DirectPlay的大厅启动功能,允许这个区域通过游戏前置表格控制某些特定的游戏设置,当游戏开始的时候,锁定这些功能。这允许玩家更好的寻找他们想要玩的游戏。因为他们可以在比赛匹配层看到这些参数,而不是直接进入游戏初始化的等待界面。在后台,我们实现了持久化的数据报告及追踪。我们为区域提供了通用的结构,这些数据在游戏结束之后被提交,这些数据用来记录玩家排名及等级,玩家可以通过区域网站观察到这些数据。 RTS3多人游戏:目标 RTS3是Ensembles的下一代策略游戏的内部代号,RTS3的设计基于成功的帝国时代系列设计理念,另外增加了一系列新的功能及多人游戏需求。
在RTS3早期中,我们做了一个决定,使用与帝国1代2代同样的网络模型——同步模拟——因为RTS3的设计以同样的方式能够发挥这种架构的优势。在一代二代中,我们依赖于DirectPlay来传输数据及会话管理,但是在RTS3中我们决定创造一个核心的网络库,用来作为我们最基础的socket库。 全3d的世界意味着我们不得不对帧频问题及多人游戏的模拟平滑更加的敏感,尽管如此,这也意味着我们的模拟更新时间及帧率更容易出现变化,我们可能需要花费更多的时间用来渲染。在Genie引擎中,单位转向是分面的,动画是帧率固定的——然而突然之间,我们突然被允许进行随意的单位转向以及平滑的动画,这意味着游戏将会对视觉更加的敏感(延迟的效果以及摇摆不定的帧频)。 二代开发完成后,我们想要总结出哪些是最重要的功能——那些预先规划设计还有工具化能对调试时间产生最大帮助的功能。我们也认识到迭代测试对于我们游戏的重要性,所以早早的将多人游戏的部分提到最高优先度。 RTS3通讯架构
点对点的劣势:
Net.lib 我们设计RTS3通讯架构的目标是适合于策略游戏的系统,但是同时我们也希望他能用来支持我们的内部工具以及我们将来的游戏。为了达到这个目标,我们创建了多层级的架构,它能够支持游戏级别的对象,比如Client或者Session,也能支持底层级的传输对象,比如一个链路或者一个网络地址。 RTS3基于我们的次时代BANG!引擎创建,该引擎是一个模块化的架构,由各种组件组成,比如音乐,渲染和网络,网络子系统在这里适合作为一个组件添加到BANG!引擎中(同时也是一个内部工具)。我们的网络模型分离为4个不同的服务器层级,看起来有点像,但不完全像OSI网络模型(见图8)。
多人游戏,第三层 多人游戏层是net.lib api中最高层级的对象,RTS3使用这个层级来组合低等级的api, 比如links为更有用的对象,比如Client或者Session。 在BAND!网络库中最有趣的对象可能就是这些在多人游戏层级的了,以下的API代表了与游戏层级交互的绝大部分对象集。然而实现上我们还是维持与游戏无关的方案。
游戏通讯,第四层 通讯层级是RTS3游戏逻辑的部分,它主要搜集了游戏与网络库接口的部分系统,他实际上存在于游戏代码中,通讯曾提供了许多有用的工具方法,用来创建及管理多人游戏层级的网络层级的网络对象,另外试图归纳游戏的联网游戏部分为一个易于使用的接口。 新的功能和更好的工具 改善同步系统 在帝国时代开发团队中没有人不需要可能的更好的同步工具,在任何项目中,当你回头整理开发过程的时候,某些区域总是花费你最多的时间,但是如果你做了更多预先的工作会省掉你非常多的时间。同步的调试工具可能是我们在开发RTS3中最重要的工具。RTS3同步追踪系统主要是为了快速定位每轮的同步问题,开发它的其他要点是开发者的使用上的易用性,它能够处理任意巨大数量的同步数据,也能够从发布版中不编入同步的那部分代码,最终能够通过某些变量或者配置文件随意修改这项配置,而不是重新编译。 RTS3的同步检查主要是采用两个宏
(每个同步“标签”都有一系列sync打头的宏,每个标签代表需要同步的系统,在这里例子中代表的随机数生成器cRandSync)这些宏都带着一个userinfo的字符串参数,这是一个名字或者显示需要同步的描述,比如,一次这样的调用
同步控制台命令和配置变量 这对于开发过程来说,意义重大(任何Quakemod的创造者都会证实这点)。控制台命令一般是简单的函数调用,可以通过启动配置文件,在游戏的控制台中, 或者UI 的钩子中, 调用任意的游戏功能。 配置变量被称为数据类型,通过简单的get, set, define和toggle 函数,来做各种测试和配置参数。 Paul 扩展了一个支持对人游戏的控制台命令和配置变量系统。我们可以很容易将一个普通的配置变量(例如, enableCheating), 通过添加一个标记, 加入到对人游戏的配置变量。如果使用了这个标记, 在多人游戏中就会传输这个配置变量,同步的游戏进程也会跟这个值有关(例如, 是否允许资源免费)。 多人游戏的控制台命令也是类似的概念: 调用一个多人游戏下的控制台命令, 会传输到网络中的玩家, 并同步执行。 通过应用这两个工具,开发者可以很简单的使用多人系统, 而不用写一行代码。他们能快速的添加测试工具和配置, 并加入到网络环境中。 总结 点对点的网络同步模型,在《帝国》系列游戏中获得了成功。关键之处在于明白花时间在创建工具和技术上的重要性(例如同步和网络测量)。证明了在实时战略游戏上应用这种架构的可行性。后续在RTS3 中做的改进, 保证了多人游戏的体验和单机时几乎没有区别,除非在最烂的网络环境下。 相关阅读:关于游戏开发中瓷砖贴图的过渡(tile) |
|