[CustomEditor(typeof(Type))]
这是所有写过编辑器的人非常熟悉的一行代码,因为它是编辑器的入口。
但是:
[CustomPropertyDrawer(typeof(Type))]
恐怕就没几个人知道了。
它和CustomEditor功能类似,都是自定义特定类型的编辑器界面,但它的对象不是MonoBehaviour,ScriptableObject, 而是一个字段上的数据。
[CustomPropertyDrawer(typeof(UserStruct))]
public class UserStrutDraw : PropertyDrawer
{
public override float GetPropertyHeight(SerializedProperty property, GUIContent label)
{
return 0f;
}
public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
{
EditorGUI.BeginProperty(position, label, property);
EditorGUILayout.BeginHorizontal();
EditorGUILayout.PropertyField(property.FindPropertyRelative("name"),new GUIContent("姓名:"));
EditorGUILayout.PropertyField(property.FindPropertyRelative("sex"),new GUIContent("性别:"));
EditorGUILayout.EndHorizontal();
EditorGUI.EndProperty();
}
}
创建这样一个类后,用到UserStruct这个数据的编辑器界面都会发生变化(或者是公开属性直接在属性面板显示,又或者是用EditorGUILayout.PropertyField呈现)
但这样并不方便,因为同一段编辑器代码会用在多个类型上,所以通常的做法是:[CustomPropertyDrawer(typeof(Type))]中的Type不指定具体类型,而是指定一个PropertyAttribute元标签对象。
public class UserDisplayAttribute : PropertyAttribute
{
}
然后在需要应用应用这个编辑器的地方打上UserDisplayAttribute这个元标签。
[System.Serializable]
public class Profile
{
[UserDisplayAttribute]
public UserStruct user;
}
便能够有和之前相同的效果。
此外,编辑器类的基类PropertyDrawer是用来定义某个属性的,它具有独占性。但你也可以继承自DecoratorDrawer,它是“装饰”的意思,是可以叠加的,可以用它来做一些界面绘制工作。
[System.Serializable]
public class Profile
{
[DrawLine]
[UserDisplayAttribute]
public UserStruct user;
}
另外,Attribute对象也是可以有内部属性的
public class UserDisplayAttribute : PropertyAttribute
{
public Color color;
}
直接写在括号内就可以为这些属性赋值,然后就可以在相应的PropertyDrawer类里读取到这个值,并处理。
[System.Serializable]
public class Profile
{
[DrawLine]
[UserDisplayAttribute(color = Color.red)]
public UserStruct user;
}
这就为我们开通了另一条,不通过CustomEditor做界面的方法。而这种方法代码量更少,也更容易重用。我们可以在写数据类的时候顺便加上这些元标签,然后用EditorGUILayout.PropertyField呈现整个数据类的根结点,然后用Unity自己的对象层级功能一层层展开,不需要为每条属性书写编辑器代码。对Unity自带呈现不满的地方,用PropertyDrawer类重新定义就可以。
数组也是可以重定义的。
而且用这种方法,以前一些比较麻烦的组件功能也变得容易实现了,诸如Tab
[CustomPropertyDrawer(typeof(TabAttribute))]
public class TabDraw : PropertyDrawer
{
public override float GetPropertyHeight(SerializedProperty property, GUIContent label)
{
return 0f;
}
public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
{
GUIStyle buttonActive = new GUIStyle(GUI.skin.button) { normal = GUI.skin.button.active };
string[] tabNames = (attribute as TabAttribute).tabNames;
EditorGUILayout.BeginHorizontal();
int count = tabNames.Length;
for (int i = 0; i < count; i++)
{
if (GUILayout.Button(tabNames[i], i == property.intValue ? buttonActive : GUI.skin.button))
{
property.intValue = i;
}
}
EditorGUILayout.EndHorizontal();
}
}
public class TabAttribute: PropertyAttribute
{
public string[] tabNames;
}
//使用示例
[Tab(tabNames = new string[] { "tab1","tab2"})]
public int tabIndex;
还有比较重要的属性中文化
[CustomPropertyDrawer(typeof(LabelAttribute),false)]
public class LabelDrawer : PropertyDrawer
{
public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
{
label.text = (attribute as LabelAttribute).label;
EditorGUI.PropertyField(position, property, label);
}
}
public class LabelAttribute : PropertyAttribute
{
public string label;
public LabelAttribute(string label)
{
this.label = label;
}
}
[Label("中文属性名")]
public int testInt;
所以我们只需要写好数据类,然后适当加几个样式元标签,根据游戏内容自己实现一些特殊的元标签以便和游戏预览部分通信,以及针对布局需求用DecoratorDrawer绘制界面。然后外面再包一个EditorWindows,将游戏的数据用ScriptableObject整体序列化以及储存。
这样我们在游戏开发过程中,编辑器就可以自动完成了,数据部分也是高效的二进制序列化格式,读取即使用,也不需要重写一遍Parse。
要说缺点的话,也就是限死了必须用Unity的序列化格式。当然,如果你愿意的话,也可以写个反射脚本把它转换成JSON,XML等其他格式,但在“技能编辑器”这类应用环境内,由于只有客户端在使用,并不需要“通用性”(虽说这个格式C#也能内建读取就是了)
至于你说,策划和程序用的是不同的Unity工程,所以不能用一样的数据格式……
首先策划和美术起码得用一样的工程,否则同步资源太浪费时间了,不同步资源?是让策划瞎着眼睛配置数据吗?程序部分如果不想暴露代码,可以编译成DLL放到他们的工程目录内,这样用上去和使用同一工程是一样的。
你非要两边代码不共用,就意味着编辑器那边不仅要实现数据编辑,还要把部分游戏逻辑修改复制一份到另一边,很容易不一致,并导致委曲求全,编辑器使用非常困难。
关键是耗费巨大,又没有实际的好处。
只要编辑器和运行时使用同一套CS代码,就可以通过这套东西节约大量开发时间,以及需求变动时修改导致的等待时间。
然而,虽然有这套东西,但是Unity自己的原始属性面板确实比较难用,虽说都可以实现,但像Tab,数组之类的功能,一个个实现也很费时间。
这里正好有一个实现好的三方库
Odin Inspector and Serializersirenix.net
进入网站往下拉可以看到全部功能介绍的动图。
除了大量定义好的元标签之外,还提供了一个任意类型序列化的功能,便于容纳字典等其他复杂类型。
从源码看,它还重写了Unity的那套Attribute的底层,不再限制元标签必须在字段上,可以放到方法上实现诸如Button之类的功能。
[Button("label")]
public void TestMethod()
{
Debug.Log("test");
}
在它的基础上开始扩展,应该是更好的做法。
29号更新:
Odin的某个示例程序
貌似是只能猜了吧?
编辑于 2018-01-29