开发重型Inspector Unity插件电视电影小迷妹 TVco.cn

iLLOGIKA提供由我们的才华横溢的艺术家，设计师和程序员团队撰写的文章。 iLLOGIKA的程序员Gabriel Huot编写了 开发重型Inspector Unity插件 。

几年前，我的一些同事正在使用非常简单的状态机与Unity进行游戏。每个状态和状态转换都使用一个状态脚本，可以将其他行为脚本添加到每个状态以达到目的。真的很简单。当他们最终在同一个GameObject上使用多个状态脚本时，噩梦开始了。问题是Unity会以以下格式显示对脚本的引用： ScriptName（脚本所在的GameObject） 。这意味着检查员将从一个状态到另一个状态的每个转换显示为： State（字符） 。更糟糕的是，当您单击该参考时，它会在场景中ping对象，但不会提供任何有关在对象上选择了哪个组件的线索。

无法知道哪个字段引用了哪个状态。

最近，我们听说Unity 4中有一项新功能，称为属性抽屉，因此我着手进行调查。想法是在脚本中添加名称和颜色，然后使用属性抽屉在检查器中的对象引用旁边显示该颜色名称。我们当时还不知道这会导致我们前进，但这是重型检查员的诞生。在接下来的一年中，我不断添加团队成员所要求的新功能。可重排序列表，一种新的选择对象上的组件而无需不停地滚动检查器几页长的新方法，甚至是一种选择另一对象上的组件而无需打开和锁定第二个检查器的新方法。

现在很清楚了，您甚至不需要打开第二个检查器来选择另一个对象上的组件。

经常出现的另一件事是在检查器中使用字符串是多么不安全，因为人们经常会打错它们。这导致了AssetPath抽屉，它允许您通过将文件拖动到检查器中的对象字段来保存文件路径，而Tag抽屉则允许您从Unity的标签下拉菜单中选择字符串。这最终也导致了在更新1.2中添加的“关键字”系统。

那时我们使用的是关键字系统的原始版本，但从未向公众发布。它使用xml文件存储可能的字符串列表，并将选定的字符串存储在脚本中的具有ListFromFile属性的简单字符串中。它工作了一段时间，但最终我们遇到了重大缺陷，迫使我们重新设计它。第一次发生在为网络播放器开发游戏时。即使仅在编辑器中使用了此字符串列表，当Unity的构建目标设置为“ Web Player”时，System.IO也不存在，即使在编辑器内部也不存在，从而阻止了xml文件的加载。当设计师要求从同一脚本中的两个不同列表中选择字符串时，第二个出现。到目前为止，我们使用的是两阶段系统，您将首先选择xml文件的路径，然后该脚本中的所有其他ListFromFile抽屉都将使用此文件作为其字符串列表。另外，随着将要在我们的游戏中浏览的字符串列表变得长达数页之久，要求将这些字符串分类为类别的方法时不时地出现。所有这些挑战最终导致创建了关键字系统，该系统现已成为重型检查器的一部分。

一切开始大约一年后，我们决定尝试在资产商店中出售不断增长的物业抽屉系列。经过审议，我们提出了“重型检查员”的名称。我花了几天的时间提出了一个没人要求的新物业抽屉，但是我觉得这对某人可能有用，做了一些例子，整理成一个自述文件，并在Unity论坛上发表了这篇文章，作为我们唯一的宣传，发布了它在资产商店上。

到现在已经两年多了，销售超过260件，我要感谢所有购买重型检查器的人，尤其是那些报告了错误或要求新功能的人。在评论和编程文章中也提到了我们。经常会要求使用字典，尽管尽管Unity有一定的局限性，但我不得不等到Unity 4.5才能接受一半的接受方式。用户也请求了DynamicRange抽屉和EditableProperty抽屉。我们一直在提出一些建议，以使“重型检查器”更好，但我们也正在考虑发布其他在开发Subaeria游戏时创建的与“检查器”无关的编辑器工具。