前言
这里的编辑器开发指的是针对游戏运行时功能开发的编辑器，更多是针对策划使用的，而不是一键生成脚本的这种。 像是程序自己使用方便自己、一键生成配置文件对应脚本之类的完全可以只做成一个按钮，因为程序使用的编辑器基本上只涉及到一些路径之类的参数，参数修改过一次后在项目开发中也不会去动，如果有改动也只需要在代码里修改就好了。
其实可能是我自己比较钻牛角尖，导致很多时候开发不必要的编辑器，到最后发现还不如直接改代码或者怎么样，切记…游戏开发是面向游戏的，开发工具也是面向工具的，而不是面向技术的…
为什么要使用编辑器
在游戏开发的过程中，有时候我们需要开发编辑器来使得工作更加便捷，有的模块只需要进行配置表格就可以，而有的模块由于外部的工具并不合适需要自行开发编辑器，比如用 Excel 编辑帧动画，虽然也可以做到但是会变得很难实时预览导致效率低下（拿Unity自带的编辑器举个栗子），但是例如一些语言表功能之类的，可能用配置表更合适，因为本身 Excel 或其他 文本编辑器 就包含了大部分文本操作的功能。
其实分析下来，无论是编辑器还是配置表甚至是 Unity，都需要有一个数据的保存以及其序列化的方式，把具体的部分进行数据结构的定义，然后选择保存的数据格式以及序列化的方法，在运行时载入到对应的 C#类中，可以以文本方式打开 Unity 的 prefab文件，就可以发现在 Unity 属性面板上填入的数据都已经在这个文本中了，具体可以参照此链接Unity文件、文件引用、meta详解。
如上图一样，当编辑只需要进行文本的一些操作，那就使用配置表的方案，而需要实时查看一些效果或者需要对照图片、音乐等资源进行操作时就可以选择编辑器的方案。
采用何种编辑器方案
在进行编辑器制作的过程中，也要明确一些东西，编辑器不仅仅只有做 Unity Editor 的方案，还可以选择做运行时编辑器，做运行时编辑器的好处是通过接入同样逻辑的脚本可以在编辑的过程中看到和游戏运行时的一样的效果，方便测试，坏处也比较明显，可能要维护两份代码，复用性差一些，针对性强一些，实际上已经使用了编辑器就说明这个需求是针对某一类型甚至特定的游戏了。
另外在序列化的方面，有些插件习惯把数据保存到 Prefab 上，我感觉这种不太好，很容易造成数据的丢失，对 Prefab 的修改比较频繁是一方面，数据耦合在一起其实也容易出现一些问题，也不太合适做扩展。可以选择使用 Unity 的 ScriptableObject，在运行时动态载入，或者其他一些用的比较顺手的文件保存方法，毕竟数据的修改、展示都可以在编辑器中进行了，不用太在意数据保存方案本身的展示、编辑问题。