游戏开发-数据配置

本文是对游戏中逻辑数据的配置的一个总结。游戏逻辑数据的配置,是mmo游戏首要考虑的问题,从字面意思看就是简单的生成游戏逻辑配置,让前后端加载即可;实际上往中后期的测试和调试来讲,却又不是一个简简单单的游戏逻辑配置问题,而是一个各个组员如何相互配合,如何保持配置即能健壮,又能在出错的时候能够及时反馈到来源方,既要保证配置的敏捷性,又要使开发人员,测试人员以及运维人员都能及时发现错误并正确的运行服务器,这个时候定制的一套规范就很有必要,而通过工具检查配置符合规范又显得很有必要。

1. 从DataEditor说起

使用c#写的DataEditor，目的是让策划人员从源头上避免数据出错,比如配置怪物的等级信息,NPC信息,而配置关卡信息时需要引用这个怪物和NPC的ID,配置怪物的一些数值信息,这里有表之间的引用关系,也有表内的字段之间的关系,数据编辑器就做的复杂无比,就算实现了,你会发现你还需要教会策划人员去学习使用它,这个成本是相当高的。索性后续退而求其次,策划还是使用excel来配置自己的数据。

2. csv2cpp的功能

csv2cpp是我用golang写的一个插件,给DataEditor调用使用，不过也可以单独使用。这个插件提供两个功能,一个功能是根据xml描述文件生成cpp文件用来读取csv文件,第二功能直接读取csv文件导出为lua文件,前者给服务器读取,后者给前端读取。

2.1 生成cpp文件

这里需要说明的是Description.xml,可以手动编写,也可以直接从csv文件中到处,csv文件有两项强制规范,首行是列表名字,名字C前缀为前端专有,D前缀表示不生成(用来缩小lua文件大小),默认是都会生成；第二行为列的字段类型,这里只有INT和STRING两种,至于策划用的逗号和分号之类的都用STRING表示了。Description.xml的格式说明，DataElement节点表示一张csv表格,Dir表示输出的目录名字,当前结构的版本号

<DataElement Name="mainMap" Dir="mainMap" Version="0.1.0" MD5="a567ec4898c9543128990729b8d2b408">
  <Field Name="id" Type="int" Key="true" IsNULL="true" Desc="地图id" Flag="3" />
  <Field Name="name" Type="string" IsNULL="true" Desc="地图名称" Flag="3" />
  <Field Name="startslot" Type="int" IsNULL="true" Desc="初始节点ID" Flag="3" />
  <Field Name="nextmap" Type="int" IsNULL="true" Desc="后继地图ID" Flag="3" />
</DataElement>

格式中还定义了前后端可以通用的枚举和常量,这里要指出的是也可以通过协议定义来导出,不过这里导出的是逻辑配置中用到的一些枚举和常量。
如下所示：

<enum name="eSkillTag">
  <enumerator name="eSkillTag_Unknow" value="0" />
  <enumerator name="eSkillTag_Begin" value="1" />
  <enumerator name="eSkillTag_Common" value="2" comment="普通攻击"/>
  <enumerator name="eSkillTag_AutoAttack" value="3" comment="自动攻击"/>
  <enumerator name="eSkillTag_End" value="3" />
</enum>
<constant>
  <define name="equip_bag_maxnum" type="int" value="200" comment="装备背包最大值" />
  <define name="pet_bag_maxnum" type="int" value="200" comment="宠物背包最大值" />
</constant>

2.2 tpl目录说明

dataloadermanager.tpl 是数据加载的管理器
dataloader 是csv的数据加载类
idataloader 是dataloader的接口类

3. 结语

有几个需要注意的地方：

策划的excel文件需要自行通过svn来管理版本,由主策同意生成csv的文件，同步更新Description.xml。
Description.xml文件是策划和程序的数据结构接口，却不是数据内容接口;结构正确的情形下,策划仍然有可能填错内容，导致测试的工作在不准确的配置上;
Description.xml可以及时更改以配合自身的开发,功能开发完毕后通知策划人员做出更改。这个时候测试有可能使用的还是旧的配置而无法快速测试新功能。
Description.xml的字段类型还可以再扩展和细化,达到生成的代码在加载时就可以检测加载错误。但是交叉引用的逻辑错误还是无法通过读取配置代码来检查,这个需要在配置读取完毕以后做一次检查。
关于服务器的配置热更新的问题，mmo服务器不建议热更配置！不过通过我长期实践k8s里的分布式配置中心的原理来说,也是可以做到的，这里需要考虑的问题是服务器热更是单独一台服务器热更还是保持所有的线上服务器配置数据的一致性问题，因此保守起见不建议热更。

最后给上源码链接