demo的配置文件d_entities问题

问： demo的d_entities 是很多类型的数据都往里放（怪物的数据和传送门等等），不会造成策划维护表比较麻烦吗？ 能否有什么改进的方案？ 因为我做掉落，我做了一个掉落表，然后要在d_entities增加字段 掉落ID，我就觉得别扭，大神有什么做掉落的方案？

答： 这个配置是excel导出的。

这个配置的架构方式已经在多款大型端游中使用过。 因此我不觉得有什么问题。 在excel中加字段就好了。

我的方案是你跟策划沟通这个excel的表头， 策划填数据就行了。 而掉落表是另一个excel表。 大概也是你说的方案。

问： ...但是 有些类型不需要这个字段 例如传送门等 第一个问题： 不会非常的冗余吗 第二个问题：做在Cell上的掉落物品entity需要继承GameObject吗？ 第三个问题：大神你们用kbe做掉落，服务端大概怎么做的，不需要详细。

答： 大多策划的想法与程序不一样， 很多策划并不觉得冗余，会适当的分表但不会那么严谨的在乎冗余字段。 一张表策划便于拉公式， 有些项目甚至每一种可能的功能都在一张表上平铺， 连外链表都没有。

KBE自带的导表工具支持多表合一导出为一个配置，在程序中一个配置便于管理，一些冗余字段是无所谓的，并不会占用多少空间。 因为实体的策划ID是一个体系， 分开多表反而你需要在不同的实体之间找不同的配置读取。

第二个问题， 你应该设计自己的逻辑框架， 我的做法是需要继承GameObject， 当然demo是随便写的， 并不很严谨。

你要不这么干你最好自己写工具， 那样能比较好组织结构， 不过策划拉量效率大大降低。 大型项目随便一拉几千个技能， 上万的怪， 那种简洁缩化结构就比较折腾数值拉表了。

批量拉数值， 出错概率相当低， 除非你们是一个一个手填。

不过一些小型项目确实没有批量需求， 总之你们自己考虑怎么用吧。