loop in codes

Kevin Lynx BLOG

谈谈我们的游戏逻辑服务器实现(一)

我们的逻辑服务器(Game Server,以下简称GS)主要逻辑大概是从去年夏天开始写的。因为很多基础模块,包括整体结构沿用了上个项目的代码,所以算不上从头开始做。转眼又快一年,我觉得回头总结下对于经验的积累太有必要。

整体架构

GS的架构很大程度取决于游戏的功能需求,当然更受限于上个项目的基础架构。基础架构包括场景、对象的关系管理,消息广播等。

需求

这一回,程序员其实已经不需要太过关心需求。因为我们决定大量使用脚本。到目前为止整个项目主要还是集中在技能开发上。而这个使用脚本的度,就是技能全部由策划使用脚本制作,程序员不会去编写某个具体技能,也不会提供某种配置方式去让策划通过配置来开发技能。这真是一个好消息,不管对于程序员而言,还是对于策划而言。但后来,我觉得对于这一点还是带来了很多问题。

实现

基于以上需求,程序员所做的就是开发框架,制定功能实现方案。脚本为了与整个游戏框架交互,我们制定了“触发器“这个概念,大概就是一种事件系统。

这个触发器系统,简单来说,就是提供一种“关心“、”通知“的交互方式,也就是一般意义上的事件机制。例如,脚本中告诉程序它关心某个对象的移动,那么当程序中该对象产生移动时,就通知脚本。脚本中可以关心很多东西,包括对象属性,其关心的方式包括属性值改变、变大、变小,各种变化形式;对象开始移动,移动停止;对象碰撞,这个会单独谈谈;定时器等。

除了触发器系统外,还有个较大的系统是游戏对象的属性系统。对象的属性必然是游戏逻辑中策划最关心最容易改动的模块。既然我们程序的大方向是尽可能地不关心策划需求,所以对象属性在设计上就不可能去编写某个具体属性,更不会编写这个属性相关的逻辑功能。简单来说,程序为每个对象维护一个key-value表,也就是属性名、属性值表。该表的内容由脚本填入,脚本享有存取权限。然后脚本中就可以围绕某个属性来编写功能,而程序仅起存储作用。

第三,怪物AI模块。AI模块的设计在开发周期上靠后。同样,程序不会去编写某类AI的实现。程序提供了另一种简单的事件系统,这个系统其实就是一个调用脚本的方案。当关于某个怪物发生了某个事件时,程序调用脚本,传入事件类型和事件参数。这个事件分为两类:程序类和脚本类。脚本类程序不需关心,仅提供事件触发API。程序类事件非常有限:怪物创建、出生、删除。

除了以上三块之外,还有很多零散的脚本交互。例如游戏对象属性初始化,角色进入游戏,角色进入场景等。这些都无关痛痒。

接下来谈一些关键模块的实现。

定时器

整个GS的很多逻辑模块都基于这个定时器来实现。这个定时器接收逻辑模块的注册,在主循环中传入系统时间,定时器模块检查哪些定时器实例超时,然后触发调用之。这个主循环以每帧5ms的速率运行,也即帧率1000/5。

这个定时器是基于操作系统的时间。随着帧率的不同,它在触发逻辑功能时,就必然不精确。游戏客户端(包括单机游戏)在帧率这块的实现上,一般逻辑功能的计算都会考虑到一个dt(也就是一帧的时间差),例如移动更新,一般都是x = last_x + speed * dt。但,我们这里并没有这样做。我们的几乎所有逻辑功能,都没有考虑这个时间差。

例如,我们的移动模块注册了一个固定时间值的定时器,假设是200ms。理想情况下,定时器模块每200ms回调移动模块更新坐标。但现实情况肯定是大于200ms的更新频率,悲剧的是,移动模块每次更新坐标都更新一个固定偏移。这显然是不够精确的。

更悲剧的是,定时器的实现中,还可能出现跳过一些更新帧。例如,理论情况下,定时器会在系统时间点t1/t2/t3/t4分别回调某个逻辑模块。某一帧里,定时器大概在t1回调了某逻辑模块,而当该帧耗时严重时,下一帧定时器模块在计算时,其时间值为t,而t大于t4,此时定时器模块跳过t2/t3。相当于该逻辑模块少了2次更新。这对于移动模块而言,相当于某个对象本来在1秒的时间里该走5格,但实际情况却走了1格。

当然,当游戏帧率无法保证时,逻辑模块运行不理想也是情有可原的。但,不理想并不包含BUG。而我觉得,这里面是可能出现BUG的。如何改善这块,目前为止我也没什么方案。

移动

有很多更上层的模块依赖移动。我们的移动采用了一种分别模拟的实现。客户端将复杂的移动路径拆分为一条一条的线段,然后每个线段请求服务器移动。然后服务器上使用定时器来模拟在该线段上的移动。因为服务器上的阻挡是二维格子,这样服务器的模拟也很简单。当然,这个模块在具体实现上复杂很多,这里不细谈。

碰撞检测

我们的技能要求有碰撞检测,这主要包括对象与对象之间的碰撞。在最早的实现中,当脚本关心某个对象的碰撞情况时,程序就为该对象注册定时器,然后周期触发检测与周围对象的距离关系,这个周期低于100ms。这个实现很简单,维护起来也就很简单。但它是有问题的。因为它基于了一个不精确的定时器,和一个不精确的移动模块。

首先,这个检测是基于对象的当前坐标。前面分析过在帧率掉到移动更新帧都掉帧的情况下,服务器的对象坐标和理论情况差距会很大,而客户端基本上是接近正确情况的,这个时候做的距离检测,就不可能正确。另一方面,就算移动精确了,这个碰撞检测还是会带来BUG。例如现在检测到了碰撞,触发了脚本,脚本中注册了关心离开的事件。但不幸的是,在这个定时器开始检测前,这两个对象已经经历了碰撞、离开、再碰撞的过程,而定时器开始检测的时候,因为它基于了当前的对象坐标,它依然看到的是两个对象处于碰撞状态。

最开始,我们直觉这样的实现是费时的,是不精确的。然后有了第二种实现。这个实现基于了移动的实现。因为对象的移动是基于直线的(服务器上)。我们就在对象开始移动时,根据移动方向、速度预测两个对象会在未来的某个时间点发生碰撞。当然,对于频繁的小距离移动而言,这个预测从直觉上来说也是费时的。然后实现代码写了出来,一看,挺复杂,维护难度不小。如果效果好这个维护成本也就算了,但是,它依然是不精确的。因为,它也依赖了这个定时器。

例如,在某个对象开始移动时,我们预测到在200ms会与对象B发生碰撞。然后注册了一个200ms的定时器。但定时器不会精确地在未来200ms触发,随着帧率的下降,400ms触发都有可能。即便不考虑帧率下降的情况,它还是有问题。前面说过,我们游戏帧保证每帧至少5ms,本来这是一个限帧手段,目的当然是避免busy-loop。这导致定时器最多出现5ms的延迟。如果策划使用这个碰撞检测去做飞行道具的实现,例如一个快速飞出去的火球,当这个飞行速度很快的时候,这5ms相对于这个预测碰撞时间就不再是个小数目。真悲剧。

技能

虽然具体的技能不是程序写的,但正如把几乎所有具体逻辑交给策划写带来的悲剧一样:这事不是你干的,但你得负责它的性能。所以有必要谈谈技能的实现。

技能的实现里,只有一个技能使用入口,程序只需要在客户端发出使用技能的消息时,调用这个入口脚本函数。然后脚本中会通过注册一些触发器来驱动整个技能运作。程序员一直希望策划能把技能用一个统一的、具体的框架统一起来,所谓的变动都是基于这个框架来变的。但策划也一直坚持,他们心目中的技能是无法统一的。

我们的技能确实很复杂。一个技能的整个过程中,服务器可能会和客户端发生多次消息交互。在最初的实现中,服务器甚至会控制客户端的技能特效、释放动作等各种细节;甚至于服务器会在这个过程中依赖客户端的若干次输入。


下一篇我将谈谈一些遇到的问题。

Comments