如何快速写游戏服务器业务逻辑

0. 背景

服务器框架设计者，若是设计的好，考虑到了这几种状况，不管是对于游戏服务器逻辑清晰度，仍是对于写业务逻辑的程序员来讲，是很是友好的。游戏服务器业务逻辑写多了，一个游戏策划提出的需求概括到服务器业务逻辑开发上面，也就无非几种状况须要处理。

1. 业务逻辑模板

下面给出代码模板，不管何种语言开发，大致都相似。

-- 数据结构

-- tbPlayer 常见字段
tbPlayer = {
    dSocketId = 0,
    time_rec  = {    -- 常见时间
        birth        = 0,
        login       = 0,
        offline     = 0,
        dailyResets = {[{H,M}] = V, ...}
        weeklyReset = 0,
    },
    sysA = tbAInfo, -- 某系统
    sysB = tbBInfo, -- 某系统
}

-- 业务系统常见字段
tbAInfo = {
    lastTime = 0, -- 上一次刷新时间
}


function born(tbPlayer)
    -- todo 建立
    -- 初始化数据，预处理数据
end

function loadData(tbPlayer)
    -- todo 获取数据
end

function saveData(tbPlayer)
    -- todo 保存数据
    -- 定时？即时
end

function onLogin(tbPlayer)
    -- todo 登陆数据预处理
end


function offline(tbPlayer)
    -- todo 下线数据处理
    -- 登出/离线
end

function sendOnLogin(tbPlayer)
    -- todo 登陆协议同步
    -- 一般 dailyReset也会默认调用该函数
end

function dailyReset(tbPlayer, tbTime={dHour, dMinute})
    -- todo 每日重置
    -- 0点，也有其余时段的需求
end

2. 数据结构

通常游戏服是将数据直接存在内存里面，可能有些作法是即时保存，有些是定时保存。也有跟传统网站开发相似的，每次业务逻辑须要数据的时候，从数据库取出来，修改以后再存进去。毕竟游戏类型颇多，不一样的游戏采用不一样的持久化策略是很常见的。以上说的三种，再项目中，笔者都见到过。

关于游戏业务的数据结构的设计，我的经验说下。首先跟时间相关的数据主要有：

• birth 建号时间
• login 上线时间
• offline 下线时间
• dailyResets 每日重置时间，存在多个时间点
• weeklyReset 每周重置时间

大多数业务逻辑都须要围绕在以上几个时间点来进行。这几个地方处理的好，是可以大幅度提升程序员的开发效率的。
dailyResets和weeklyReset时间点记录都是为了实现每日重置，每周重置的逻辑。
每日重置须要注意下，可能存在多个时间点。凌晨0点是进行每日重置最多见的时间点。可是也有些游戏为了照顾玩家休息，或者为了下降服务器在0点的压力，将部分或所有重置设置为其余时间点的，例如凌晨3点，凌晨5点。
每周重置的状况比较少存在多个的，通常选择周一凌晨0点。

不少游戏都会为了前期的七日留存作不少工做，建号时间也每每在这些地方须要。固然这是个颇有用的字段，不管是对于业务逻辑，仍是对于游戏数据分析，都须要建号时间。

上线时间是最多见的时间了，通常游戏只在玩家在线的时候处理逻辑。玩家一旦下线，不多再会对玩家数据进行处理。等到玩家再次上线的时候，才会对数据进行处理计算。补回那些玩家不在线，而又须要执行的数据。如每日邮件，每日奖励这种，咱们不会真的天天都会将玩家数据从数据库取出来进行处理，并且等到玩家上线的时候再运算那些不在线时期发生的事情。而这些处理，都依赖于玩家的上次上线时间来计算。

下线时间用的没有上线时间那么多，可是也很多。

3. 常见逻辑

3.1. 建号 born

玩家的一切都起源于建号。建号须要进行一些数据初始化，如一些基础装备，基础属性。

3.2. 持久化 loadData和saveData

玩家登陆的时候，咱们须要把数据从数据库拿出到游戏服务器的内存里面。再数据发生改变以后，又须要存储到数据库进行存档，以防服务器崩溃发生数据丢失。可是每次发生改变若是都进行存储的话，无疑对数据库的压力会很大。为了权衡性能和数据安全，通常须要制定存储策略，如定时存储，或者定时存储加部分数据即时存储。不一样的数据重要程度不同，能够采用不一样的存储策略。

3.3. 玩家上线 onLogin和sendOnLogin

为何须要将上线的操做拆分onLogin和sendOnLogin两个函数。二者的区别是，前者用于进行数据预处理。补回相似刚刚说的，每日邮件啊，每日奖励那些处理。后者是再数据预处理执行完了以后，进行该业务逻辑的协议同步。将数据预处理和协议同步分开是很是有必要和方便的。另外若是某个系统依赖于别的系统，该系统的onLogin操做须要放在别的系统的onLogin以后。

3.4. 玩家下线和断线重连 offline和reconnect

玩家下线每每存在很是规操做，因此下线通常没有协议同步，只有数据处理。下线通常放在与客户端socket断开的地方处理。下线也能够决定是否进行存档。须要特别注意的是，再手游里面，断线是很是容易发生的。因此须要考虑断线重连的状况。是否当即存库其实也跟断线重连的设计相关。若是保留玩家的数据再内存一段时间，如1分钟，30分钟，offline的操做在手游里面就会极大的变少。能够根据下线成本自行考虑把。可是操做是必不可少的，只是执行的数量的问题。

4. 结尾

以上是我的经验总结出来的业务逻辑开发场景。只是单纯将业务逻辑的常见，此处不讨论游戏服务器的框架设计，如网络，日志，协议，持久化等。这些其实才是游戏服务器设计者的大头。

好记性不如烂笔头。