您认为以下哪项比较难？
- 解决编码问题
- 解决更大的编码问题
是的，我也是。
编程是关于解决问题的。 当您尝试对代码进行过时验证时 ，您正在有效地解决不必要的难题和更大的问题。
为什么不必要地加重？ 因为很有可能您对未来的假设是错误的！
我喜欢制作游戏开发工具。 我喜欢做能创造东西的东西。 因此，有时我只是在不需要工具的情况下制作工具！
到目前为止，一切都很好。 但是在DeMagnete开发过程中，我们决定使用某种图形编辑器工具来帮助游戏设计师配置拼图逻辑。
当时我想：“那太好了，因为我之前已经创建了一个图形编辑器！ 我们就用吧！”。
事实证明，这就像快餐三明治一样差。
问题是，当我开始不实际使用它时，我做出了一些设计决定，这些决定在实际项目中使用时会给我们带来困扰。
错误的决定
- 试图使一切都可扩展
- 使用了模糊的图形绘图Unity API
不良后果
- 高度可扩展的部分正在尝试做简单的事情时出现（即使那样，它也不是那么可扩展，因为当时我不知道可配置会带来什么真正的好处）
- 没有放大/缩小
- 链接节点非常困难，因为插槽很小（没有API可以更改）
- 序列化非常困难，因为我们必须将模型与Unity API的模型进行同步
让那些从不重写解决方案实现的人投下第一石！
掌握了第一个API的难点以及我们的工具可以解决的确切需求的知识之后，我们终于可以寻求一个更强大的解决方案。
一个周末，我能够从头开始草拟一个新的图形编辑器工具，因为这次我知道了我的目标。 因此，该API变得更易于实现和使用。
好的决定
- 保持API简单明了
- 使用标准的编辑器GUI工具并滚动我们自己的图形绘制API（它比看起来简单！）
好的结果
- 新的节点脚本超级紧凑且富有表现力
- 可以实现放大/缩小！！！
- 由于我们对插槽鼠标碰撞函数进行了编码，因此连接节点更容易
- 序列化更健壮（一旦我们找出一些初始问题哈哈），因为我们不需要保持两个状态同步（图的视图和模型）
不错的附加功能
- 单击其关联节点时，在层次结构中选择GameObjects
- 当层次结构中的选择发生更改时对节点进行Ping操作
- 节点可以具有任何RGB颜色（在必须使用枚举之前–疯狂吧？）
- 更容易更改和设置边缘颜色的动画
- 我们做了一个“切割边缘”的事情，像ShaderForge一样大规模地去除了边缘（非常酷而且有用）
我们两次解决了相同的问题。 但是第二种实现要好得多，总体上更好。
唯一改变的是，当我第一次对该工具进行编码时，我并没有真正的必要 ，过去也没有。
这是我在我制作的其他工具/代码中没有实际用例的一种模式。 在没有任何种类的重写的情况下 ，我实际上没有重复使用这些工具中的任何一个！
就是这样了！ 将您的代码保存在当前状态！
**哦！ 期望这个新的图形编辑器功能不久将在BitStrap上可用！
