没事没事，支持luban谢谢喵，希望这个讨论不要让你产生对luban的厌恶，这真的是一个好用到夸张的工具。 
看完文档后,我觉得可以用一句话来总结这个工具
每个使用平台或者使用者都可以从这个工具中方便定制属于自己的个性需求.
因为抽象,所以方便个性化定制.
真是个好东西… 我的需求可以方便地满足.
1赞
刚去看了下luban，功能挺多，不过某些情况还是不合适，比如 Hero表有个技能数据，“1,1408101;41,1408102;81,1408103;121,1408104”，这个结构是{英雄星级：技能ID}，其中技能ID可以配置多个，需要根据策划提供的方案进行技能合并，而且技能合并还比较复杂（需要按技能权重排序确定首技能，然后将后续技能的属性和Buff按一定规则合并到首技能），此时需要把这个字段映射为更复杂的自定义复合对象 {星级： {技能类型： 合并后的技能}}，而且读取数据时需要快速定位数据，后端java可以引入Guava TreeRangeMap，TS却只能循环遍历，这种情况luban是好像无法处理，请问，你能给个建议吗？
我不会配置这么复杂的表，按照我之前说的，这属于post-pipeline的内容，在c#里可以使用分部类，在ts里可以做一个helper函数。
如果你偏要
1.你可以考虑看一下luban的定制开发方案，直接配置这么复杂的结构是不可能的。
2.让策划写一套公式，策划远比我们想象的会用excel。
luban 确实是更好的方案。你的需求，在luban 的解决方案里，可以通过定制 DPP 管线实现。
如果要用地编，一般首选 Tiled Map。除了文档和功能齐全之外，最重要的是，它是标准化了的软件。luban 就是配置表的标准化工具。为什么有那么多标准化组织，标准化的好处就在于降低成本，减少内耗。
策划一旦掌握。以后他做别的什么 Unity Godot 或者 App 项目，都可以用这套配置工具，相互之间都有公共的知识背景。
你让大家学习 luban，肯定好过学习你的配置体系。
文档不用你写，技能不用你教，你省了时间。他们获得了更通用的技能。双赢。
有我这种需求案例推荐吗？看文档，DPP就是一笔带过。
+1
你这种应该业内很多在用，我们 java 后端就是打成.bin，然后预处理这块真的很有必要。我前端目前是 json 有空也改造 csv
引用这个学到了
我没做硬性要求数据是否存在，因为之前我在工作中使用时几乎每个空数据都要进行判空处理很不方便
所以数据不存在我会在导出时根据数据类型给一个默认值，比如"", 0, false, []，只要有效值避免使用这些默认值即可
我们会把定义导出来，类似于next_task: string?等，方便ts检查，在实际使用过程中，需要判空的概率不是很大，由于我们有做约束检查，比如使用另一张表的id等，代码中直接索引不需要判断
那你一定是用了严格模式
，如果不用严格模式的项目使用到了undefined的进行运算就报错了，老项目也没法改
必须上严格模式 
，自从用了ts，记忆力直线下降。。。。
说实话我也看了一眼头大，策划要上手头也大，强大通用意味着复杂，学习成本也大，我喜欢简单的，99% 项目可以满足，策划维护简单，大家都爽。
再加上还要装.net 环境马上劝退
（没有说 luban 不好哦）
不要再打了.gif
我对导表这块感兴趣所以大概爬楼看下来了，首先工具没有谁好谁坏，楼主插件很好，luban 也很强大， @568049460 借楼说自己的方案也没看出有贬低拉踩意思，有些对我来说还是有借鉴意义的。不知道为啥就互相有怼的味道了，论坛不是应该鼓励分享吗，至少我从大家的分享中学到东西了。
顺便说下，其实很多工具的出现都是从自己项目实践中提炼和迭代出来的，会有自己的需求色彩，会有各自的优势和需要解决的痛点，适合自己的才是最好的。
嗯，其实luban有些情况也不合适（比如我上面提到的那个英雄技能配置，策划配置简单，就是用于业务逻辑所映射的对象很复杂，不管数值怎么变化，都应该服务于程序，而不是让程序去为数值伤脑筋），哪怕luban能满足99%的功能，只要1%的功能不满足就得劝退一拨人，至于说那些luban DPP管线和定制功能，我花那个时间研究，我手鲁代码写完早就喝茶去了，当然，我不否定luban有它的优势，说实话，luban开源也就两年左右，而手鲁代码是数十年游戏业内通用做法，只要我们愿意花时间、花精力，很多人都能重复照轮子，只是没必要而已。
哈哈哈，其实也没啥，我只是提出作者几个可以改进的地方，并提出手鲁代码也有其优势，作者改进后或许就是另一个luban。
装.net环境倒不是必须的，不打成dll，给它打成对应平台的执行文件就好了。