适用于游戏项目的Excel配置表导出工具
- 数据结构定义在proto文件中
- 解析proto文件,获取proto中的message的结构信息
- 解析Excel配置表,列名就是proto中定义的message的字段名
- 导出为proto对应的json格式(也可以扩展为导出proto序列化后的二进制数据,以便于更高效的加载)
- 支持批量导出,在一个excel里配置所有需要导出的配置表,可以批量导出并生成加载代码,把加载代码放到项目中, 可以一个接口就完成加载所有数据,并支持并发,热更新,增量加载
- 支持配置表关联检查
- 支持不同的配置表合并导出到同一个文件里
- 测试用例在tool/export_test.go
- 加载导出的json数据(或二进制数据),直接反序列化成proto的message对象
- 测试用例在example/import_test.go
excelexporter -config=.\exporter.yamlconfig: 配置文件
#Excel导入目录(excel所在目录)
DataImportPath: "./data/excel"
#数据导出目录
DataExportPath: "./data/json"
#proto所在目录
ProtoPath: "./proto"
#需要解析的proto文件
ProtoFiles:
- "export.proto"
- "cfg.proto"
#可选项:导出md5文件完整路径
Md5ExportPath: "./data/json/md5.json"
#代码模板目录
CodeTemplatePath: "./template/"
#代码模板
CodeTemplateFiles:
- "data_mgr.go.template"
#代码导出目录 NOTE:和CodeTemplateFiles的数量要一致
CodeExportFiles:
- "./cfg/data_mgr.go"
#导出分组标记 c s cs
ExportGroup: "s"
#默认的分组标记
DefaultGroup: "cs"
#导出总表的文件名
ExportAllExcelFile: "all.xlsx"
#导出总表的sheet名
ExportAllSheet: "ExportCfg"- 由于proto文件中已经定义了数据结构,所以excel里只需要列名和proto定义的字段名一致,就可以知道字段的类型信息, 所以excel里不需要再指定字段类型,假设物品的proto定义如下
message Item {
int32 Id = 1;
int32 Type = 2;
string Name = 3;
}
那么物品配置表的excel格式就可以这样:
-------------------------
| Id | Type | Name |
-------------------------
| 1 | 1 | 物品1 |
-------------------------
| 2 | 1 | 物品2 |
-------------------------
| 3 | 2 | 物品3 |
-------------------------
message Test {
int32 Id = 1;
Item Item1 = 2;
Item Item2 = 3;
repeated Item Items = 4;
}
配置表的excel格式就可以这样:
-------------------------------------------------------------
| Id | Item1 | Item2 | Items |
| | #Field=no | #Field=full | #Field=Id_Type |
-------------------------------------------------------------
| 1 | 1_1_物品1 | Id_1#Type_1#Name_物品1 | 1_1;2_1 |
-------------------------------------------------------------
| 2 | 2_1_物品2 | Id_2#Type_1#Name_物品2 | 2_1;3_2 |
-------------------------------------------------------------
| 3 | 3_2_物品3 | Id_3#Type_2#Name_物品3 | 3_2;1_1 |
-------------------------------------------------------------
一个单元格要配置一个message的数据,就需要在一个单元格里填写多个字段的数据
- #Field=no 表示Item1不需要填写字段名,以_作为分隔符,按照字段顺序进行赋值,适用于字段少的结构简单的message, 缺点是兼容性差,当message的字段做了更新,可能导致解析异常
- #Field=full 表示Item2需要填写字段名,以Field1_v1#Field2_v2的格式,按照字段名进行赋值,填写麻烦但是兼容性强, 当message增删了字段或者调整了字段的顺序,也不影响字段的解析
- #Field=Field1_Field2_FieldN 是前2种格式的结合,既简洁又保留了兼容性,解析时会按照表头指定的字段名进行赋值, 且单元格不需要再每行填写字段名
-----------------------------------------------------------------------
| Id | Item1 | Item2 | Items |
| | #Field=no | #Format=json | #Field=Id_Type |
-----------------------------------------------------------------------
| 1 | 1_1_物品1 | {"Id":1,"Type":1,"Name":"物品1"} | 1_1;2_1 |
-----------------------------------------------------------------------
| 2 | 2_1_物品2 | {"Id":2,"Type":1,"Name":"物品2"} | 2_1;3_2 |
-----------------------------------------------------------------------
| 3 | 3_2_物品3 | {"Id":3,"Type":2,"Name":"物品3"} | 3_2;1_1 |
-----------------------------------------------------------------------
格式: #Ref=要关联检查的配置表名,假如有一个配置表Item,下面的Item2配置了#Ref=Item,在导表时,将会自动关联检查Item2中配置的Id是否在Item中存在,如果不存在,将会输出错误信息
-------------------------------------------------------------
| Id | Item1 | Item2 | Items |
| | #Field=no | #Field=full#Ref=Item | #Field=Id_Type |
-------------------------------------------------------------
| 1 | 1_1_物品1 | Id_1#Type_1#Name_物品1 | 1_1;2_1 |
-------------------------------------------------------------
| 2 | 2_1_物品2 | Id_2#Type_1#Name_物品2 | 2_1;3_2 |
-------------------------------------------------------------
| 3 | 3_2_物品3 | Id_3#Type_2#Name_物品3 | 3_2;1_1 |
-------------------------------------------------------------
- 导出protobuf二进制数据