常见游戏服务器业务逻辑和模板

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

为什么需要将上线的操作拆分onLoginsendOnLogin两个函数。两者的区别是,前者用于进行数据预处理。补回类似刚刚说的,每日邮件啊,每日奖励那些处理。后者是再数据预处理执行完了之后,进行该业务逻辑的协议同步。将数据预处理和协议同步分开是非常有必要和方便的。另外如果某个系统依赖于别的系统,该系统的onLogin操作需要放在别的系统的onLogin之后。

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

玩家下线往往存在非常规操作,所以下线一般没有协议同步,只有数据处理。下线一般放在与客户端socket断开的地方处理。下线也可以决定是否进行存档。需要特别注意的是,再手游里面,断线是非常容易发生的。所以需要考虑断线重连的情况。是否立即存库其实也跟断线重连的设计相关。如果保留玩家的数据再内存一段时间,如1分钟,30分钟,offline的操作在手游里面就会极大的变少。可以根据下线成本自行考虑把。但是操作是必不可少的,只是执行的数量的问题。

4. 结尾

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

好记性不如烂笔头。

原文地址:https://www.cnblogs.com/rond/p/9226799.html

时间: 2024-11-06 07:28:52

常见游戏服务器业务逻辑和模板的相关文章

棋牌游戏服务器架构设计

转载自:简书一位同行的文章 一,棋牌类服务器的特点 1,棋牌类不分区不分服 一般来说,棋牌游戏都是不分区不分服的.所以棋牌类服务器要满足随着用户量的增加而扩展的需要. 2,房间模式 即在同一局游戏中就是在同一个房间中,同一个房间中的人可以接收到其他人的消息. 3,每个房间的操作必须是顺序性 这个特性类似与一般游戏的回合制,每个玩家的操作都是有顺序性的. 二,需要解决的技术点 1,数据共享 因为棋牌类游戏不分区不分服,我们在设计服务器的时候,是按世界服的思想去设计,即服务器是一个n多台物理机的集群

简论游戏服务器架构设计

一.QIPAI类服务器的特点 1,QIPAI类不分区不分服 一般来说,QIPAI游戏都是不分区不分服的.所以QIPAI类服务器要满足随着用户量的增加而扩展的需要. 2,房间模式 即在同一局游戏中就是在同一个房间中,同一个房间中的人可以接收到其他人的消息. 3,每个房间的操作必须是顺序性 这个特性类似与一般游戏的回合制,每个玩家的操作都是有顺序性的. 二,需要解决的技术点 1,数据共享 因为QIPAI类游戏不分区不分服,我们在设计服务器的时候,是按世界服的思想去设计,即服务器是一个n多台物理机的集

游戏服务器框架概括分析

这篇blog题目涉及的范围真大!以至于在这里需要先写一篇前言把范围缩小.选择写这样一个系列的文章,主要是想给工作了两年的自己一个交代,或者说是一个阶段性的总结.两年时间里,房价依然再涨,工资依然跑不赢CPI,某人依然在仰望星空.期间很多梦碎了,很多还在坚持着,生活过得波澜不惊.而我也从刚毕业是的青涩逐步蜕变为"老油条".不知道是一种悲哀.还是一种悲哀.还是一种悲哀....... 庆幸的是梦还在继续,一颗倔强的心还在坚持.希望明天的明天被束缚的心能回到梦开始的地方! ==========

关于网站服务器与游戏服务器的一些常用端口介绍

关于网站服务器与游戏服务器的一些常用端口介绍 如何正确使用服务器里的网站与游戏端口?规避防火墙策略的影响及保护网站与游戏的正常运行.以及服务器安全的一些简单方法,介绍一下我在工作中遇到的这些情况,及相关的想法. 工具/原料服务器.游戏.安全方法/步骤 一.先介绍一下网站与游戏使用的常用端口 网站常用的端口是80和8080,游戏常用是6000-10000这个范围内,一般程序或管理人员都是这样设置的,我在工作中也经常见到很多的客户使用这些游戏端口. 二.介绍一下IDC防火墙中默认的防护端口 无论哪一

教你从头写游戏服务器框架

本文由云+社区发表 作者:韩伟 前言 大概已经有差不多一年没写技术文章了,原因是今年投入了一些具体游戏项目的开发.这些新的游戏项目,比较接近独立游戏的开发方式.我觉得公司的"祖传"服务器框架技术不太适合,所以从头写了一个游戏服务器端的框架,以便获得更好的开发效率和灵活性.现在项目将近上线,有时间就想总结一下,这样一个游戏服务器框架的设计和实现过程. 这个框架的基本运行环境是 Linux ,采用 C++ 编写.为了能在各种环境上运行和使用,所以采用了 gcc 4.8 这个"古老

腾讯高级工程师:如何从头开始写游戏服务器框架_转

转自: 腾讯高级工程师:如何从头开始写游戏服务器框架 本文作者:韩伟,腾讯互娱高级工程师,目前在 Next 产品中心研发创新类型游戏. 前言:从去年开始作者投入了一些具体游戏项目的开发,这些新的游戏项目,比较接近独立游戏的开发方式.在这个过程中,作者从头写了一个游戏服务器端的框架,以便获得更好的开发效率和灵活性.因此这篇文章便是该项目服务器框架的设计和实现过程的总结. PS:框架的基本运行环境是 Linux ,采用 C++ 编写.为了能在各种环境上运行和使用,采用了 gcc4.8 这个“古老”的

使用GoWorld游戏服务器引擎轻松实现分布式聊天服务器

GoWorld游戏服务器引擎简介 GoWorld是一款开源的分布式可扩展的游戏服务器引擎,使用Go语言(Golang)编写.它采用类似BigWorld的结构,使用了简化的场景-对象框架.以一个典型的MMORPG为例,每个服务器上会有多个场景,每个场景里可以包含多个对象,这些对象包括玩家.NPC.怪物等.GoWorld服务器可以将场景分配到在不同的进程甚至不同的机器上,从而使得游戏服务器的负载是可扩展的. 开源分布式游戏服务器引擎:https://github.com/xiaonanln/gowo

Netty游戏服务器之一

所谓磨刀不误砍柴工,所以在搭建netty游戏服务器之前,我们先要把要准备的东西做好. 首先进入netty的官网下载最新版本的netty的jar包,http://netty.io/downloads.html,这里我下载的是netty-5.0.0.Alpha2.tar.bz2 版本的. 打开压缩包,找到all-in-one下面的netty-5.0.0.Alpha2.jar包. 打开我们的eclipse我们神圣的编辑器,然后新建一个File,取名叫lib,专门存放第三方的jar. 然后把之前的net

游戏服务器生成全局唯一ID的几种方法

在服务器系统开发时,为了适应数据大并发的请求,我们往往需要对数据进行异步存储,特别是在做分布式系统时,这个时候就不能等待插入数据库返回了取自动id了,而是需要在插入数据库之前生成一个全局的唯一id,使用全局的唯一id,在游戏服务器中,全局唯一的id可以用于将来合服方便,不会出现键冲突.也可以将来在业务增长的情况下,实现分库分表,比如某一个用户的物品要放在同一个分片内,而这个分片段可能是根据用户id的范围值来确定的,比如用户id大于1000小于100000的用户在一个分片内.目前常用的有以下几种: