（转）Unity 游戏配置表格代码自动生成术

风吹吹蛋蛋疼风w

说起游戏配置表，不论是游戏程序还是游戏策划，都是每天都在打交道的、最普通不过的东西。
相信不少游戏程序员，撸过大量这样的代码：

1. class SkillSetting
2. {
3.     public int Id;
4.     public string Name;
5.     public string Desc;
6.     public int Arg1;
7.     public int Arg2;
8.     public int Arg3;
9.     // .....
10.     // .....
11. }
13. class SkillSettingManager
14. {
15.     // .....
16.     public void Init ()
17.     {
18.         var table = TableReader.Read("jineng.txt")
19.         for (var line = 0; line <= table.RowsCount; line++)
20.         {
21.             Id = table.GetRow(line, "id");
22.             Name = table.GetRow(line, "name");
23.             Desc = table.GetRow(line, "desc");
24.             Arg1 = table.GetRow(line, "arg1");
25.             Arg2 = table.GetRow(line, "arg2");
26.             Arg3 = table.GetRow(line, "arg3");
27.             // ......
28.         }
29.     }
30. }
31. // ....
32. // .....
33. // ......
34. class BuffSettingManager { .... }
35. class TaskSettingManager { .... }
36. class MissionSettingManager { .... }
38. // .... 接近上百个XXX SettingManager

复制代码

相信不少游戏策划，都遇到过这样的配置表：


好吧。大家都或多或少遇过这些问题：

大量的配置表代码需要手工撸，枯燥繁杂大量的手工配置表代码跟随着大量的BUG策划配置表跟程序代码经常命名不一策划新人看不懂配置表的这一列究竟是干嘛的策划同学想要更方便的工具提升工作体验配置表加载严重影响游戏启动速度运营需求对游戏配置表修改热重载，手工代码没有支持配置表相关联的功能和BUG消磨大量的研发、运营时间

嗯，多么痛的领悟。
接下来抛砖引玉，让我们一起探讨一种游戏配置表的优化方案。
需求

编辑游戏配置表的用户首要就是我们的策划同学了，而策划同学最喜欢最顺手的工具非Excel（或WPS表格）莫属了。 当然了，也见过自己开发编辑器工具的，但我们毕竟不是全职做工具开发，没必要额外的增大工作量。
因此我们可以在Excel表格设计上，动动手脚。策划同学有这样的需求：

配置表的列头带上注释策划同学可以在任意他们喜欢的地方做注释策划同学可以在他们的配置表中的添加文档性东西如图表、文字框有时候同样的表，可以拆分成多张，方便编辑

拿到这样的一份配置表后，程序同学有这样的需求：

希望配置表的代码是可以自动生成的部分复杂逻辑的可以自定义扩展的为配置表的列定义类型

方案

编辑

针对这些需求，我们就有了这样的这个结果：

第一行是列名第二行是程序用途的类型声明，如int, Dictionary<int, string>第三行是该列的注释列名以#开头，则这一列为注释列（忽略该列单元格内容忽略）行的第一个单元格内容以#开头，则这一行为注释行（所有行单元格内容忽略）可以加入图表、第二张工作表作为辅助内容

将这样的一张表，保存为SettingSrc/Test.xls文件。
下面我们使用一个名为TableML的执行程序，可以从Releases · mr-kelly/TableML · GitHub下载测试，并包含源码和单元测试。

1. TableML.exe --Src SettingSrc --To Setting --CodeFile Code.cs

复制代码

在SettingSrc目录下执行这个配置表编译命令，会把所有的Excel文件，编译成Tab分隔的表格纯文本（TSV），并生成一个代码文件Code.cs。
编译后的TSV文件Test.tml纯文本内容，实质就是剥离了注释的Excel表格。
Excel表编译结果：




同时命令生成代码：

1. /// <summary>
2. /// Auto Generate for Tab File: "Test.bytes"
3. /// Singleton class for less memory use
4. /// </summary>
5. public partial class TestSetting : TableRowFieldParser
6. {
7.         /// <summary>
8.         /// ID Column/编号/主键
9.         /// </summary>
10.         public string Id { get; private set;}
12.         /// <summary>
13.         /// Name/名字
14.         /// </summary>
15.         public I18N Value { get; private set;}
17.         // .............
18. }
19. public class TestSettings
20. {
21.      IEnumerator GetAll()
22.      {
23.           // ...
24.      }
25. }

复制代码

至此，程序同学，把策划同学的游戏配置表编译优化成纯文本格式，生成的Code.cs文件也导入Unity工程，使用TestSettings.GetAll来获取所有的配置表内容了。
多语言



标注列的类型为I18N
既然表的第二行支持类型说明，那自然而然，我们可以标记某一列是可以需要进行翻译的。比如，把这一列标记成I18N，我们通过脚本，把所有带有I18N列中的字符串进行收集，自动生成一个翻译表；而生成的代码中对应I18N这个类，则对翻译表进行处理，来实现字符串的多语言翻译。 细节不多叙述。
而在游戏做多语言版本的过程中，光字符串翻译是不够的，我们有些时候，不同的版本还有不同的游戏数值。鉴于我们的表编译机制，我们可以加入一些类似预编译指令的机制来处理：




拆表

在很多时候，策划同学喜欢将一个表的东西，分成多个文件来写。比如有游戏的道具比较多，一般会分成SettingSrc/Item/Weapon.xls，SettingSrc/Item/Equipd.xls, SettingSrc/Item/Common.xls等多张表格，尽管他们是不同的文件，但是它们的列头都是一样的，这样让编辑起来更加的容易，而且多人编辑时，不容易做成冲突。
在程序代码中，它们也会被一个统一的ItemSettingsManager类读取成统一的配置类型。
我们可以应用之前的“#”符号，来对他们的文件名修改一下：SettingSrc/Item/#Weapon.xls，SettingSrc/Item/#Equipd.xls, SettingSrc/Item/#Common.xls，这样，来骗过编译程序，再执行刚才的编译命令：

1. TableML --Src SettingSrc --To Setting --CodeFile Code.cs

复制代码

这样就会让代码生成器，忽略#号后面的字符串，把它们统一合并成ItemSettings类。

1. public class ItemSettings
2. {
3.     // 把三个表一起进行加载
4.     public static readonly string[] TabFilePaths = {
5.        "Item/#Weapon.xls", "Item/#Equipd.xls", "Item/#Common.xls"
6.    };
7.    // ...
8. }

复制代码

至于还有一些细节功能的，如自定义类型、自定义解析、自定义代码模板（让C++、Lua都支持）等扩展代码能力的功能，这里不多作解释。
具体的细节可以参考命令的源码中的单元测试：
GitHub: TableML，
这是一个提供给Unity游戏开发的开源配置表代码生成工具，
一些逻辑细节和教程也可以参考这里的文章。



常见问题

在TableML尝试应用的过程中，曾经遇到过不少疑问：
考虑其它格式让策划同学编辑？如Lua、JSON？

考虑到策划同学和其他同学的使用体验和习惯，Excel表格是他们最顺手、功能强大的工具。
既然编译，为什么不直接编译成序列化的字节？

选择编译成纯文本格式，更多出于工程考虑的，一考虑文本格式能对版本管理（如SVN）更友好，二考虑开发调试也更容易。性能方面，在我经历的项目上，对这种Tab分隔的表格文本解析，比序列化还要快。
我更喜欢自己撸，没必要代码自动生成？

从程序习惯的角度来说，这种想法无可厚非，毕竟多年的开发习惯如此，而且自由度更高，写起这些代码来自然是舒畅的 。 但是从工业角度来想，人工写出的代码维护Bug成本，比自动生成代码维护成本要高。并且，为自动生成的代码添加功能（比如，运行时动态重载），只需要在生成代码的代码中稍微修改，就全局生效。
Excel文件怎么进行版本比较？

在我看来这是一个非常关键的问题。这也是为什么Excel表被编译成TSV纯文本的一个重要原因。另外除了Excel表，TableML命令中还支持TSV翻译到TSV，就是直接把Excel文件另存为TSV格式的配置表文件，再进行编译。
另外，Beyond Compare 4支持Excel文件的直接比较；TortoiseSVN中双击Excel文件，也会打开Excel文件显示差异的地方（但较蹩脚）。
我项目的配置表都是自动生成的，程序策划没意见、也挺智能的？

恭喜你们项目的质量棒棒的，也希望一同分享您的方案！独乐乐不如众乐乐！
所以呢

说这么多，技术角度来说，自动化的配置表编辑和加载，没有什么技术含量，更多的是一种思想，但是我相信这对项目管理、规范化是起到积极的作用的，减少重复劳动的时间，增加生产力。做游戏项目，消耗时间的，往往不是高深难解的问题，而是一些简单问题的重复轮回。
原作者：陈小霖 Kelly
九城学院游戏编程干货分享专区：IT开发学院 - 泛IT开发驱动基地