从技能配置可视化+纯业务的角度，将原来的技能系统换个角度刨析一遍。

大体分类

按照可配置的文件来分类，可分为以下五大类：

碰撞关系配置
buff配置
skill配置
单位配置
bullet配置

下面对这几类的核心配置数据进行列举。

碰撞关系配置

目标队伍
目标选择规则
目标单位
目标查找范围

buff配置

buff类型
buff附着目标
buff位置确定方式
碰撞关系配置

skill配置

图片、音效资源路径
技能动画名
技能目标确定方式、范围等
技能指示器类型

单位配置

UnitInfoCfg，比较特殊，为了方便导表，逻辑碰撞体这块只提供一个Enum，在实际加载时使用它的派生类，根据Enum读取出不同的真实逻辑碰撞数据。

单位基础属性（基础血量、防御等）
单位资源位置
单位逻辑碰撞体类型（受击点高度 + 碰撞体大小、形状）

实现协作

即想要结点编辑器、又想要表格式的批量填写。将他们协作起来需要多写一些代码，且他们的数据都必须来自同一套数据源——我采用Json数据源。

Luban

由Luban提供2套类型：Editor专用的类型，用于和Json数据源交互；运行时使用的类型，也就是真实类型，用于和bytes数据源交互。

由Luban提供多种格式数据转换：2种Editor可视化面板中填写数据 => Editor专用Json类 => Json数据源；Json数据源 => bytes数据源；bytes数据源 => 填充运行时对象。

Odin

实现在Unity中，表格式的批量填写配置数据。数据依赖于Json数据源，可视化面板需要单独写一套。

xNode

实现在Unity中，结点式的树形填写配置数据。数据依赖于Json数据源，可视化面板需要单独写一套。

要点小记：

1.比如List<int>类型外键，实现结点连接。
2.多个不同类型的buff实现结点。
3.如何全遍历图，输出json。

完全基于数据驱动的xNode连点图

不依赖于SerializableObj的数据持久化内的数据，每次打开图，全部清空，只根据json数据来重新绘制整张图。这样就能保证多种编辑方式（普通编辑器、连点编辑器、excel）修改同一主体后，保持数据一致。

依赖

需要人为保障准确的，只有Graph的命名，因为这代表着要读取数据的文件路径。按照统一风格标准来命名即可。

启动流程

根据命名去取对应路径下的json数据源文件，读取；
获取依赖的其他json文件（比如skill下的buffList），读取；
将所有取得的文件可视化成对应的Node；
根据1中获取的信息，对图中Node进行连线。

未来计划

一点是，xNode在这里的用途非常小，数据层已完全分离、存于硬盘，graph是打开绘制的也不依赖于SerializableObj；另一点是，xNode效率真的太低了，实时刷新造成结点一多就卡顿。

所以其实应该基于odin（甚至直接脱离unity用wpf）自己写一套简单的数据可视化连点器，再去掉它的高频刷新。会比xNode实现轻便的多，画面板也更轻松。最后加上Timeline，行为树和状态机的模板，就可以复用了。

另外，关于luban的使用方式上有一点改进。比如SKillCfg.BuffList并不需要以int[]的形式去写数据了，而是直接以BuffCfg[]的形式，因为luban是支持多态记录json的。不过由于luban和editor都是UnityMobaDemo搭建完技能系统后才引入的，本次作罢。

考虑以后采用的技术方案选择：

时间线编辑器：timline flux slate

可视化连点器：NodeGraphProcessor