🛠️ Lesson 7.1: Custom Inspectors & Property Drawers

Why Customize the Inspector

The default Inspector is reflection over your fields: Unity walks every serialized member and draws a matching control. That is a fine default and, for most components, all you need. You reach past it when the default draws the data correctly but presents the work badly. Four recurring motivations cover almost every real case:

None of these change what your component is — the serialized data is identical. They change how a human interacts with it. That distinction matters, because a custom Inspector that quietly corrupts undo history or breaks multi-object editing is worse than no custom Inspector at all. The trick, as we'll see, is to redraw the interface while letting Unity keep owning the data.

💬 A note on the two UI systems. Custom Editors can be built with the classic IMGUI API (OnInspectorGUI, EditorGUILayout) or the newer UI Toolkit (CreateInspectorGUI, returning a VisualElement). This lesson teaches IMGUI because it is the most direct, most documented path and reads top-to-bottom like the code it is. You'll meet UI Toolkit properly in the next lesson when we build a full EditorWindow with it.

Your First Custom Editor

Suppose we have a simple spawner component. Nothing exotic — a prefab, a count, a radius:

using UnityEngine;

// This is a normal runtime MonoBehaviour. It lives in a runtime assembly.
public class EnemySpawner : MonoBehaviour
{
    public GameObject enemyPrefab;
    public int count = 10;
    public float radius = 5f;
}

To take over its Inspector, we write a separate Editor class, tag it with [CustomEditor(typeof(EnemySpawner))], and override OnInspectorGUI. Unity calls that method every time it needs to draw the Inspector for a selected EnemySpawner:

using UnityEngine;
using UnityEditor;   // the whole Editor API lives here

[CustomEditor(typeof(EnemySpawner))]
public class EnemySpawnerEditor : Editor
{
    public override void OnInspectorGUI()
    {
        // 'target' is the EnemySpawner being inspected (typed as Object).
        var spawner = (EnemySpawner)target;

        // Draw a heading, then the default fields for now.
        EditorGUILayout.LabelField("Enemy Spawner", EditorStyles.boldLabel);
        DrawDefaultInspector();   // Unity's reflection-based drawing

        if (spawner.count > 100)
            EditorGUILayout.HelpBox("That's a lot of enemies — check your pool size.",
                                    MessageType.Warning);

        if (GUILayout.Button("Preview Spawn Points"))
            Debug.Log($"Would spawn {spawner.count} enemies within {spawner.radius}m.");
    }
}

That is a complete, working custom Inspector. DrawDefaultInspector() keeps the normal fields, and we bolt on a warning and a button. Notice the shape of the class: it derives from Editor (not MonoBehaviour), it has a target reference to the object being inspected, and the [CustomEditor] attribute wires the two together. This is enough for buttons and read-only feedback — but the moment you want to write to fields, reading target directly is the wrong move. Here's why.

SerializedObject & SerializedProperty

If you set spawner.count = 5 directly inside OnInspectorGUI, three things silently break: the change won't register with Undo, it won't mark the scene or prefab dirty (so it may not save), and it won't behave correctly when multiple objects are selected or when the value is a prefab override. Unity's Inspector never edits objects directly — it edits them through a SerializedObject wrapper, and you should too.

The pattern is always the same three-step ritual, and the SVG below shows what it protects you from. Read the property at the start of the frame, draw fields bound to properties, then write the buffer back at the end:

using UnityEngine;
using UnityEditor;

[CustomEditor(typeof(EnemySpawner))]
[CanEditMultipleObjects]                       // enable multi-select editing
public class EnemySpawnerEditor : Editor
{
    SerializedProperty prefabProp;
    SerializedProperty countProp;
    SerializedProperty radiusProp;

    void OnEnable()
    {
        // Cache the property handles once, by field name.
        prefabProp = serializedObject.FindProperty("enemyPrefab");
        countProp  = serializedObject.FindProperty("count");
        radiusProp = serializedObject.FindProperty("radius");
    }

    public override void OnInspectorGUI()
    {
        serializedObject.Update();             // 1. pull current values into the buffer

        EditorGUILayout.PropertyField(prefabProp);
        EditorGUILayout.PropertyField(countProp);
        EditorGUILayout.PropertyField(radiusProp);

        if (countProp.intValue > 100)
            EditorGUILayout.HelpBox("That's a lot of enemies.", MessageType.Warning);

        serializedObject.ApplyModifiedProperties(); // 3. write buffer back (records Undo)
    }
}

serializedObject is a property Unity gives every Editor. PropertyField draws the right control for whatever type the property is — an object field for the prefab, an int field for the count — and because it is bound to a SerializedProperty, all the machinery just works. ApplyModifiedProperties() is what records the Undo step and marks things dirty; forget it and your edits appear to work but never persist.

Drawing with EditorGUILayout

EditorGUILayout is the toolbox of Inspector controls, laid out automatically top to bottom so you never compute rectangles by hand. You saw PropertyField, LabelField, and HelpBox already; a handful more cover the vast majority of custom Inspectors. Here is a richer OnInspectorGUI that groups fields, reacts to a mode, and detects changes:

public override void OnInspectorGUI()
{
    serializedObject.Update();

    // A bold section header.
    EditorGUILayout.LabelField("Spawn Settings", EditorStyles.boldLabel);

    // Indent a group of related fields.
    EditorGUI.indentLevel++;
    EditorGUILayout.PropertyField(prefabProp, new GUIContent("Enemy Prefab"));
    EditorGUILayout.PropertyField(countProp,  new GUIContent("Spawn Count"));
    EditorGUILayout.PropertyField(radiusProp, new GUIContent("Radius (m)"));
    EditorGUI.indentLevel--;

    // Put two controls on one horizontal line.
    EditorGUILayout.BeginHorizontal();
    if (GUILayout.Button("Reset")) countProp.intValue = 10;
    if (GUILayout.Button("Double")) countProp.intValue *= 2;
    EditorGUILayout.EndHorizontal();

    // Detect whether the user changed anything in a block.
    EditorGUI.BeginChangeCheck();
    EditorGUILayout.PropertyField(radiusProp);
    if (EditorGUI.EndChangeCheck())
        Debug.Log("Radius edited — you could revalidate here.");

    serializedObject.ApplyModifiedProperties();
}

Every one of these is composable: BeginHorizontal/EndHorizontal and indentLevel nest, BeginChangeCheck/EndChangeCheck brackets any block you care about, and EditorStyles gives you the editor's own fonts and colors so your additions look native. Because the method runs every repaint, you can branch on the current data — hide a field when a bool is off, swap a slider for a plain field — and the Inspector reshapes itself live.

Property Drawers & Custom Attributes

A custom Editor customizes one component type. A Property Drawer customizes one field type or one attribute — everywhere it appears, in every Inspector, automatically. This is how Unity's own [Range], [Header], and [Tooltip] work, and you can add your own. It's the more reusable of the two tools: write it once, decorate any field, done.

The pattern has two halves. First, a small PropertyAttribute — a marker with no logic — that you can stick on fields:

using UnityEngine;

// A marker attribute. Note: this is RUNTIME code (it decorates runtime fields),
// so it lives in a normal assembly, not the Editor one.
public class RequiredAttribute : PropertyAttribute { }

Then a [CustomPropertyDrawer] that knows how to draw any field wearing that attribute. Property drawers use the rect-based API (EditorGUI, not EditorGUILayout) because Unity hands them a fixed position rectangle to paint into:

using UnityEngine;
using UnityEditor;

[CustomPropertyDrawer(typeof(RequiredAttribute))]
public class RequiredDrawer : PropertyDrawer
{
    public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
    {
        // Draw the normal field first.
        EditorGUI.PropertyField(position, property, label);

        // If it's an empty object reference, tint it and warn.
        bool missing = property.propertyType == SerializedPropertyType.ObjectReference
                       && property.objectReferenceValue == null;
        if (missing)
        {
            var warnRect = new Rect(position.x, position.yMax, position.width, 16f);
            EditorGUI.LabelField(warnRect, " ⚠ This reference is required.");
        }
    }

    // Reserve extra vertical space when we draw the warning line.
    public override float GetPropertyHeight(SerializedProperty property, GUIContent label)
    {
        bool missing = property.propertyType == SerializedPropertyType.ObjectReference
                       && property.objectReferenceValue == null;
        return EditorGUIUtility.singleLineHeight + (missing ? 18f : 0f);
    }
}

Now any field in any component can opt in: [Required] public GameObject enemyPrefab; and it grows a warning line whenever it's empty — no per-component Editor needed. The SVG below shows the reconstructed result: a custom Inspector combining bold headers, labelled fields, a [Required] warning, a help box, and an action button.

💡 Editor vs. Property Drawer, in one sentence. Use a custom Editor when you want to restructure a whole component's Inspector (headers, buttons, conditional layout); use a Property Drawer when you want one field or one attribute to look and behave the same wherever it shows up.

Where Editor Code Must Live

Everything in the UnityEditor namespace exists only in the Editor — it is stripped from player builds. If a using UnityEditor; ends up compiled into a runtime assembly, your game won't build. Back in Lesson 1.1 you learned to carve a project into assemblies with .asmdef files; Editor code is the textbook case for that discipline.

There are two ways to keep Editor code out of your build, and Unity honors both:

• A folder named Editor. Any script under a folder literally called Editor is compiled into the special Editor-only assembly. Simple, and enough for small projects.
• An Editor .asmdef. In a properly modularized project, you make a dedicated assembly definition with its Platforms set to Editor only, and have it reference your runtime assembly. Your custom Editor and PropertyDrawer classes go there.

This is exactly the layering from Lesson 1.1 paying off: a clean runtime assembly that ships, and a separate Editor assembly full of tools that never leaves your machine. As your tooling grows in the next three lessons — an EditorWindow, an Addressables-aware level tool — it all lands on this same Editor side of the line.

Hands-on Challenge

[CustomEditor(typeof(WaveConfig))]
public class WaveConfigEditor : Editor
{
    SerializedProperty waveCount, spawnInterval, prefabs;

    void OnEnable()
    {
        waveCount     = serializedObject.FindProperty("waveCount");
        spawnInterval = serializedObject.FindProperty("spawnInterval");
        prefabs       = serializedObject.FindProperty("enemyPrefabs");
    }

    public override void OnInspectorGUI()
    {
        serializedObject.Update();

        EditorGUILayout.PropertyField(waveCount);
        EditorGUILayout.PropertyField(spawnInterval);
        EditorGUILayout.PropertyField(prefabs, true); // true = draw children

        if (spawnInterval.floatValue <= 0f)
            EditorGUILayout.HelpBox("Spawn interval must be positive.", MessageType.Error);
        if (prefabs.arraySize == 0)
            EditorGUILayout.HelpBox("Add at least one enemy prefab.", MessageType.Error);

        if (GUILayout.Button("Sort Prefabs by Name"))
        {
            // Simple insertion sort over the serialized array elements' names.
            for (int i = 1; i < prefabs.arraySize; i++)
                for (int j = i; j > 0; j--)
                {
                    var a = prefabs.GetArrayElementAtIndex(j - 1).objectReferenceValue;
                    var b = prefabs.GetArrayElementAtIndex(j).objectReferenceValue;
                    if (a != null && b != null &&
                        string.CompareOrdinal(a.name, b.name) > 0)
                        prefabs.MoveArrayElement(j, j - 1);
                }
        }

        serializedObject.ApplyModifiedProperties(); // records the sort as one Undo step
    }
}

Summary

🚀 What's Next?

You've reshaped the Inspector that Unity gives you. Next you'll build a window of your own from nothing. In Lesson 7.2: EditorWindows with UI Toolkit, you'll add a menu item, open a dockable EditorWindow, and construct its interface with modern UI Toolkit VisualElements — labels, buttons, and a ListView — the foundation for the level-layout tool at the end of this module.