CustomEditor CustomPropertyDrawer

[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 Serializer​sirenix.net图标

进入网站往下拉可以看到全部功能介绍的动图。

除了大量定义好的元标签之外,还提供了一个任意类型序列化的功能,便于容纳字典等其他复杂类型。

从源码看,它还重写了Unity的那套Attribute的底层,不再限制元标签必须在字段上,可以放到方法上实现诸如Button之类的功能。

[Button("label")]
public void TestMethod()
{
    Debug.Log("test");
}

在它的基础上开始扩展,应该是更好的做法。

 


29号更新:

Odin的某个示例程序

貌似是只能猜了吧?

编辑于 2018-01-29

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值