Content Manager Tools and Editors Development
Game designer wants to add new level. Without custom tool looks like: open Unity Editor, create ScriptableObject, fill fields manually, see no preview, accidentally leave null in required field — bug found in QA week later. With right Level Editor inside Unity: visual level list, drag-and-drop order, built-in validation, level icon preview right in tool.
Difference — not convenience. It is iteration speed and content error count.
What we build and for which tasks
Custom Editor Windows for game data work. Typical cases: quest editor (dependency tree, conditions, rewards), dialogue editor (graph with branches), economy editor (prices, exchange rates, balance table), loot editor (probabilities, weights, drop conditions). All can be stored in ScriptableObject or JSON — but editing via standard Inspector is slow and unsafe.
EditorWindow in Unity — base class for any tool. IMGUI (GUILayout, EditorGUILayout) or new UI Toolkit (USS + UXML) — choose per task. UI Toolkit preferred for complex UI with trees, lists, drag-and-drop. IMGUI faster for simple forms and doesn't require separate markup files.
PropertyDrawer and CustomEditor — when don't need separate window but need to improve display of specific ScriptableObject or Component in Inspector. [CustomPropertyDrawer(typeof(LootTable))] with weight visualization as small histogram right in Inspector — few hours of work saving hours of confusion for designer.
Dialogue editor — one case breakdown
Graphy-like dialogue editor — most requested tool type. Requirements: nodes with replica text, choice branches, conditions (flag checks, progress), localization.
Standard approach — on GraphView API (namespace UnityEditor.Experimental.GraphView). GraphView provides pan, zoom, select, copy-paste out of box. Custom Node classes inherit from UnityEditor.Experimental.GraphView.Node, ports (Port) define inputs and outputs.
GraphView problem: marked as Experimental since Unity 2019 and never got stable status officially. Means possible breaking changes on engine update. Alternative for new projects — xNode (open-source) or own implementation on UI Toolkit with custom drag-logic.
Store dialogue data in ScriptableObject with [SerializeReference] for polymorphic storage of different node types — allows serializing children without wrappers and type loss on deserialization. If dialogues need editing outside Unity (by narrative designer without Editor) — use JSON with custom serialization or yarn/ink formats with parser on Unity side.
Validation and error protection
Tool without validation transfers correctness responsibility to human — always errors. Three protection levels:
Inline validation in editor. [Required] attribute via custom PropertyDrawer that draws red frame around empty required field. Visible immediately, before save.
Pre-build validation. IPreprocessBuildWithReport.OnPreprocessBuild() — method called before each build. Walk all ScriptableObject assets of needed type via AssetDatabase.FindAssets, check required fields, null-references, ID duplicates. On finding error — throw BuildFailedException with description of what and where broken. Build doesn't start with broken data.
Runtime assertions. In Debug-builds: Debug.Assert(quest.reward != null, $"Quest {quest.id} has null reward"). Cheap and catches what passed first two levels.
Custom Gizmos and Scene View Tools
For level editors: custom Handles in Scene View via Handles.DrawWireCube, Handles.DrawBezier, HandleUtility.PickGameObject — visualize game data right in scene. Spawn zones, patrol paths, trigger zones — editable via drag in Scene View, not via numbers in Inspector.
[DrawGizmo(GizmoType.Selected)] attribute draws custom Gizmo without OnDrawGizmos() on component — cleaner architecturally.
Timeline
| Tool | Duration |
|---|---|
| CustomEditor / PropertyDrawer for existing type | 1–3 days |
| Simple EditorWindow (data table + CRUD) | 3–7 days |
| Graph-editor (dialogues, quests) medium complexity | 2–4 weeks |
| Full Level Editor with validation and gizmos | 3–8 weeks |
Cost calculated after functional requirements description and game data structure analysis.