来自 游戏 2019-09-20 06:24 的文章

游戏设计中真实时间定时器是什么?急要

  尽管如今游戏类型多种多样,各种玩法层出不穷,各种平台不断延伸,从游戏后台程序的角度来看,还是可以发现很多相通的地方。从数学模型上讲,任何程序都是一个状态机,准确的说是一个图灵机,总是在一边读写纸带一边机械地改变自身状态。

  驱动游戏Server这台“机器”不断运转的因素,主要有两个方面,一个是消息,一个是时间。消息主要体现于客户端侧的玩家操作,同时也有Server之间的交互,以及对进程的信号控制等。时间方面,一种是固定间隔或时间点上的特定逻辑触发,另一种则是由事件动态诱发的时延逻辑,如玩家进入某种状态,持续几秒后消失。

  时间触发逻辑的常用解决方案是定时器,大家应该也比较熟悉,无论系统层还是应用层都有很多优秀的实现。虽然本质上定时器并不是唯一解决方案,但引入定时器概念,可以将时间控制的实现界面统一起来,同时相比传统的轮询Check方式,具有更加灵活简洁的使用方式。

  本文将主要结合游戏中实际概念与需求,介绍下在以往项目中,定时器系统的设计和实践。

  从游戏后台的真实需求来讲,定时事件的触发一般不需要过高时间精度,为了既能满足精度要求,又能清晰刻画游戏时间概念,这里抽取出了Tick的概念,亦可称为游戏逻辑帧。按以往的经验,通常将1秒划分为20个Tick,即每个Tick占时50毫秒。相较于真实时间,以Tick描述时间还有一个好处,就是具有连续性和单调性,无论是对于定时器系统自身的实现,还是应用层的某些特定需求场景,连续时间系统都是极其良好的特性。

  Timer结点即是对定时器本身的属性描述,包括作用间隔,作用次数,触发时的行为,以及支撑该行为的相关数据。与常规定时器的定义并无大异。

  值得一提的是本文定时器系统是支持使用共享内存的,Timer结点使用了定长数据结构,为了合理有效地对内存进行利用,实际应用中,Timer结点通常只存放相关标识和索引数据。如Player定时存盘Timer,其结点内实际上只存放了Timer类型和玩家ID,待存盘的数据始终是位于Player身上。这里也体现出时间触发本身才是定时器的核心作用,而不是维护各种事件的具体数据状态。

  关于结点触发的执行行为,常见的设计是设置一个回调函数指针,这也是纯C中的常用方式。当使用C++进行实现时,也可以稍微优雅一点,利用多态的特性,将行为制定成一个virtual函数,不同类型的Timer结点实现各自的具体行为。如下:

  然而考虑到Timer结点位于SHM,函数指针和虚函数可能都不是完美的方式,需要在基于SHM重启进程时进行重设。目前项目索性直接使用了根据Type显式强制转换,并没有使用虚函数。示意如下:

  如所有ID的含义一样,TimerID作为对一个Timer结点的唯一标识。设置Timer成功后会返回一个TimerID,通过TimerID可以执行结点的删除,变更等逻辑。

  这里提出了属主这样一个概念。在实际应用中,我们提倡每一个定时器都有其属主,也即其归属对象。比如玩家相关的Timer其属主为Player对象,怪物相关Timer的属主为Monster对象。属主对象身上,存有其所有Timer结点的ID。当属主对象释放时,其负责释放所占的Timer资源,以防止Timer泄露。另一方面Timer触发时,如果找不到属主,也会主动释放自己。本质上属主并非每个Timer的必要属性,比如一些全局唯一Timer,但实际应用中我们提倡这样的使用方式,在获得到了Timer的动态特性同时,避免产生资源泄露问题。