Luban Excel 配表工具使用推荐及总结

[toc]

几乎每个游戏的制作过程中都少不了和配置打交道的需求，有的是用 Unity 自带的 ScriptObject 进行存储，或者更多的是使用 Excel 等表格工具，二次导出配置文件等

每种方案见仁见智，依照不同的使用场景各有优劣

一般来说数据的输入都是由策划来完成的，而大部分策划非常倾向于使用 Excel 作为日常配置使用的工具，尤其是在需要批量拉表的场景下，其他的方案在这个场景下与 Excel，几乎没有任何可比性

相关链接

Luban 仓库地址 Luban 官方示例 Luban 官方文档 Luban 简单示例 Luban 简单文档 Luban Unity GUI 工具

为什么使用 Luban

如果项目中使用 Excel 作为配表的载体，大部分都会选择使用相关的导表工具，可能是项目自己开发，也可能是使用一些现成的工具，比如 git 上 tabtoy 、excel2json 等相关工具

但是上面这些，包括大部分自己开发的导表工具，或多或少都会存在一些致命的限制，或者不够通用，亦或者不够灵活等等问题

一个具有普适性的配表工具需要兼容的场景非常多，各种语言、自定义生成模板、数据反倒、数据有效性验证 等等

而 Luban 是目前唯一一个市面上有资格成为行业配表标准的工具，未来也很难会有同类产品可以超越

核心功能介绍

数据有效性验证

这里的数据有效性不是指 bool 的格子填了一个 int

有效性验证这个问题之前让我非常头大，经常出现策划跑过来找你说，"我这里程序有 bug, 你检查一下"， 然后花了半天时间查到了因为配表中某一行的 id 或者关键数据填写不合法

一次两次还可以，次数多了难免心态不好，尤其当人员发生变动，新来的人无法完全理解每个值的意义，就很容易放飞自我，最终就是事故，而这些问题是可以从源头有效切断的

如果你项目中配表的内容存在某个地方需要相关人员记住应该怎么配，而没有相关 自动校验，那么这里假以时日 一定会出问题

工具支持的校验器如下：

当然，一个游戏的开发如果需要完整校验所有配置的合法性，上述这些校验器是无法完全满足的，或者说这些复杂场景不应该由 Luban 来解决，所以针对这些场景，在官方示例中有一个 CfgValidator 来处理这种问题

生成模板

一个合格的配表工具应当兼容自定义生成代码功能，而 Luban 这里使用的是 scriban 的方案

当你有代码定制需求时，99% 的场景不需要改代码生成工具的源码即可完成定制需求

Luban 简单文档 在我整理的这个文档里面包含了模板具体生成的介绍，可以加速你理解如何自定义模板。在 Luban 现有的设计下，几乎可以兼容任何场景（包括老项目的迁移）

复杂类型的填写

在这个仓库中 Luban 简单示例 的 多态示例 中可以很直观的看到继承相关的复杂类型应当如何在 Excel 中展开和填写

配表支持继承在很多游戏开发场景中非常非常受用，比如游戏中的道具，装备和英雄类的定义一定存在 共用数据结构 和 特化的数据结构 等，如果没有继承这里的代码会非常难看，而且配表填写的内容也会成为灾难

Luban 支持任意复杂数据结构的嵌套，只有在代码中能定义出来，Luban 就能解析，但是在实际使用中，并不推荐使用非常复杂的数据结构，这样会给策划带来额外的填表负担，以及部分场景下的代码生成的额外工作量

数据及定义过滤

一些定义只需要在客户端使用，或者只会在服务端使用，需要在生成时进行动态剔除，当然这个功能一般的配表工具也都支持，但 Luban 额外考虑到了一些场景，比如这一条数据需要临时注释或者仅在测试环境下使用

这里的 test 就非常有用，我们会单独配置一套 test 数据，用于游戏中的核心逻辑验证，及测试用例的辅助配表，而这些数据不会出现在正式环境下

数据反倒

有时候会有这种场景，项目一些配置需要在 Unity 等游戏引擎中完成，可能是一些技能的配置等，这个时候就可能需要反倒数据

如果是一些老的项目需要迁移，也是一个非常合适的场景

本地化

只要是配表工具，就一定绕不开本地化这件事，Luban 同样也提供了本地化的解决方案

这里值得一提的是，Luban 会将所有未加入翻译表的 key 单独输出到指定的文件中，方便检查

其他

Luban 支持的序列化格式、语言和场景非常多，这里并不一一介绍了，进对我目前使用中碰到的核心功能进行介绍

流程推荐

下面提到的内容在 Luban 简单示例 仓库中都可以找到相关代码

导出脚本选择

个人比较推荐实用 sh 作为项目通用导表工具，Windows 需要配置 sh 文件默认使用 git bash 作为打开方式即可

这里主要考虑的是平台兼容性问题，比如开发环境中可能有人使用的是 Mac 也可能是 Windows，但是在部署时大部分都是 Linux 服务，如果每个平台单独维护一份脚本，加上不同环境和使用场景，这里对应的文件数量就比较离谱了

test、dev、release

建议项目按照这种方式来划分配表

  • test
    • 仅在测试用例、Editor 下使用
  • dev
    • 仅在开发环境下使用
  • release
    • 仅在正式环境下使用

auto_validation

首先，我们并不希望策划推送一个已经被自动流程检测出错误的提交，此时需要对 git 进行 hook，核心就是提交时本地检查一遍，如果有错误，禁止本次 commit 将这种低级错误扼杀在源头

watch

一般可能会有这种需要对配置热重载的功能，使用 watch，配合自己项目中的热重载就可以做到这边保存 Excel，Unity 不需要重开游戏就可以直接加载到新配置