游戏开发业务篇-师徒系统（1）

这个专题主要记录从事游戏开发做过的业务系统，以及分享一些好的业务模块。毕竟游戏开发业务才是核心，底层的服务端技术在日常工作中基本是不怎么需要关心的，对于刚进入游戏行业的小伙伴们来说尽快提升业务能力显得尤为重要，因为可以帮助你有效率的开展工作，关于游戏服务端开发的一些感受后面会单独写一篇博文，对游戏行业感兴趣的同学到时可以关注一下。

师徒系统.png

1 业务介绍

本文需要介绍的是为游戏实现一个师徒系统，策划的目的是增强玩家间的社交联系，并强化高端玩家的荣耀感。这个业务目的非常容易理解，大家玩的游戏如果足够多的话，就会发现大部分游戏都有类似的东西，如果碰巧你也玩过“王者荣耀”的话，那么就更容易明白了，因为这次介绍的师徒系统基本和王者荣耀是一样的，相对来说功能要简单一些，因为在下目前在研发的游戏是休闲竞技类，而王者荣耀是moba类，要大型复杂很多，社交做的可能功能丰富点。

2 业务需求

简单介绍一下需要实现的需求：

（1）拜师收徒
（2）徒弟任务，完成有师傅徒弟都有奖励
（3）师徒同场游戏收益加成
（4）名师等级，通过升级名师等级，加成收益会上升

本系列会逐个介绍师徒系统的功能实现，本篇主要讲一下整体设计，为接下来的文章铺垫下。我们会尽量的简化一些业务细节，重点放在业务的流程和一些比较有意思的地方，比如我们先来分析分析拜师收徒功能，我们通过下面的一张图来看看：

拜师收徒流程.png

从图可以发现，这里的重点是需要维护玩家的申请列表和师徒关系，因为申请是双向的，玩家A向玩家B发起的申请，需要同时更新玩家A的“我的申请列表”和玩家B的“拜师申请”列表；玩家B同意了玩家A的拜师申请，需要同时更新玩家A、B的申请列表的状态信息（将状态改为“已同意”），并且将玩家A添加进玩家B的徒弟列表，同时玩家B信息作为玩家A的师傅信息。这里在下会考虑用spring的事务去做，整个师徒系统会有很多这样的一些业务细节的问题，当然实现并不是说很难，但这能作为我们开发的经验积累。

3 玩家数据结构简介

大部分游戏玩家的信息存储都会单独的持久化出一张player表出来，这里同样也是如此，数据库使用的是mysql，玩家的基本信息以字段形式呈现，每个业务模块则使用的是mysql longtext类型，通过JSON格式存储，持久化时需要序列化，取出时再反序列化，并转化成相应的Java对象即可。 也有的游戏是每个业务模块的数据都单独一张表，通过玩家唯一Id建立连接，在需要此业务模块数据时再去查询，当然两种方法皆有利有弊，这里不讨论这个。

4 模块设计

拿到这个需求的时候，因为师徒系统是独立的模块，因此当然需要在player表加一个字段为：mentorPoolJson，数据类型为longtext，然后根据业务对象划分类，下图是我的模块设计类图，（类命名可以不用吐槽哈）：

模块设计图.png

简单解释一下：
（1）整个师徒系统都是通过MentorStatus来维护，MentorStatus主要及时记录了玩家的师徒状态，状态会决定着玩家的身份，到底是师父还是徒弟，还是已经出师了，或者是什么都不是，当玩家在玩师徒系统时，要保证玩家的师徒状态是最新的，即要第一时间更新师徒状态，并且保证更新成功。

（2）ApplyListPool是玩家身上保存的申请列表，有“我的申请”，“拜师申请”，“收徒邀请”三种类型的申请列表，申请列表的只保存玩家Id即可，当需要显示时再从数据库load出来。

（3）DisciplePool是玩家身上的徒弟管理类，玩家如果成为了师父所有关于徒弟的信息操作都在这个类里进行，Disciple是徒弟类，之所以抽象出一个徒弟类而不是直接保存玩家Id，是为了方便扩展，以后如果需求需要对徒弟进行一些升级改动啥的都可以在Disciple类里面去处理。DisciplePool需要持久化的仅仅是一个discipleList数组和一些基本成员变量。

（4）MasterPool同（3）是一样的，不一样的是徒弟有多个，但师父只能有一个，因此MasterPool没有数组，这里MasterPool模块保存的是玩家拜师之后的师父信息，同样也会抽象出一个Master类，当然Master类里也只有一个成员变量，那就是玩家Id。

（5）TopMasterPool模块保存的是玩家的名师等级信息，当玩家具备成为师父的条件时会开启名师等级功能，名师等级有新的等级和经验，升级名师等级可以增加收徒弟的数量，并且可以获得相应奖励。

本篇作为师徒系统的开篇，介绍了师徒系统基本背景和整体设计，下面的文章会一个个功能的去阐述，有兴趣的同学可以继续关注。业务模块设计尚有不足之处，希望可以通过和大家的交流继续提升。

Regards，
codjust