游戏后台定时器系统设计与实现

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

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

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

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

一．概念抽取

1.Tick，游戏逻辑帧

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

2.Timer结点

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

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