游戏后端设计与思考——业务开发、配置读取

最近也是经历了裁员换工作，在熟悉了新项目游戏后端的架构后，感觉到游戏业务上的一些设计有些不同，当然设计的不同也受到游戏类型的影响，这里记录下自己的总结。

上一家公司的项目是一个MMORPG类型的游戏，业务比较核心的开发内容是副本相关的玩法，比如爬塔副本、PVP擂台赛、各种组队副本等等。
玩法副本类继承于副本基类，基类中定义了各种常用的虚函数接口，比如玩家进入/离开副本、击杀、死亡等等。所有的副本内部逻辑都写在这个新玩法副本类中。除了副本类，还需要一个handle类来接收新玩法相关的协议；一个manager类来处理玩家在新玩法中的数据以及与玩家相关的逻辑，比如玩家的积分、玩法获胜后奖励的发放等等(并不是每一个玩法都需要这个类，如果有需要处理的数据或逻辑才会有)。
玩家会持有各种玩法的manager类指针，当handle类收到协议需要处理逻辑或者副本类中需要处理玩家数据时，直接通过玩家身上的manager类指针调用函数即可。思路比较简单，逻辑好理解。

新公司的项目是一个即时对战动作游戏，业务开发主要是各种节日活动，比如双十一活动、元旦活动、春节活动等等。
实现上，将各种基础活动(比如抽奖、签到、任务、兑换商城等等)实现为一个个component组件，节日活动module类根据需要注册对应的component组件即可。
逻辑的触发使用了事件机制，组件类根据需要注册相应事件的回调函数，当有事件触发，由事件分发器类转发到注册了该事件的活动组件类，触发回调函数。回调函数使用了map存放，key值使用typeid().hash_code()来获得事件类型的唯一值。
思路稍复杂些，而且代码看起来比较累，各种回调函数，逻辑不是特别清晰。好处是理解之后，开发是比较便捷的。

业务的设计和开发与游戏类型有一定的关系，而玩法活动配置的读取就与游戏类型无关了。两个项目的实现方式也不尽相同。

上一个项目的协议是自己实现的，因此活动配置的数据结构也使用了协议去约束。活动配置的excel表需要根据协议的定义来生成表结构(由脚本实现)，再由策划配置内容。内容配置完成后，由脚本生成为协议所定义的数据结构类型对应的二进制文件(供服务端读取)和json文件(供客户端读取)。
因此，配置的读取只需要在config配置类中注册文件名，服务器启动时，config类会根据注册的文件名依次读取二进制配置文件内容，转为协议定义的数据结构放到内存中。
config类设计为单例，并且提供模板函数find<配置文件名>()用于获取活动配置，在需要的地方，使用config类即可获得。

目前项目是将excel配置表导出为xml文件，封装了TinyXml库作为基类。添加新的配置表时，需要添加新的config单例类继承于基类并注册各个页签数据读取的回调函数。服务器启动时，基类会调用各个config类的初始化函数，读取xml文件到内存中(此内存在结束回调后会释放)，再通过回调读取到各个config类中。因此config类中需要定义对应的数据结构类型来接收存放，再提供get()函数来获取配置数据。

以上是对于游戏业务开发、配置读取两个方面在两个项目中的设计实现方式。