Разработка инструментов и редакторов для контент-менеджеров игр
Геймдизайнер хочет добавить новый уровень. Без кастомного инструмента это выглядит так: открывает Unity Editor, создаёт ScriptableObject, заполняет поля вручную, не видит превью, случайно оставляет null в обязательном поле — и баг обнаруживается в QA через неделю. С правильным Level Editor внутри Unity: визуальный список уровней, drag-and-drop порядок, встроенная валидация, превью иконки уровня прямо в инструменте.
Разница — это не удобство. Это скорость итерации и количество ошибок в контенте.
Что строим и для каких задач
Custom Editor Windows для работы с игровыми данными. Типичные кейсы: редактор квестов (дерево зависимостей, условия, награды), редактор диалогов (граф с ветками), редактор экономики (таблица с ценами, курсами валют, балансом), редактор лута (вероятности, веса, условия дропа). Всё это можно хранить в ScriptableObject или JSON — но редактировать через стандартный Inspector медленно и небезопасно.
EditorWindow в Unity — базовый класс для любого инструмента. IMGUI (GUILayout, EditorGUILayout) или новый UI Toolkit (USS + UXML) — выбираем под задачу. UI Toolkit предпочтительнее для сложных интерфейсов с деревьями, списками, drag-and-drop. IMGUI быстрее для простых форм и не требует отдельных файлов разметки.
PropertyDrawer и CustomEditor — когда не нужно отдельное окно, но нужно улучшить отображение конкретного ScriptableObject или Component в Inspector. [CustomPropertyDrawer(typeof(LootTable))] с визуализацией весов в виде маленькой гистограммы прямо в Inspector — это несколько часов работы, которые экономят часы непонимания у геймдизайнера.
Редактор диалогов — разбор одного кейса
Graphy-подобный редактор диалогов — самый запрашиваемый тип инструмента. Требования: узлы с текстом реплик, ветки выбора, условия (проверка флагов, прогресса), локализация.
Стандартный подход — на основе GraphView API (пространство имён UnityEditor.Experimental.GraphView). GraphView предоставляет pan, zoom, select, copy-paste из коробки. Кастомные Node классы наследуются от UnityEditor.Experimental.GraphView.Node, порты (Port) определяют входы и выходы.
Проблема GraphView: он помечен как Experimental с Unity 2019 и официально так и не получил стабильного статуса. Это означает возможные breaking changes при обновлении движка. Альтернатива для новых проектов — xNode (опенсорс) или собственная реализация на UI Toolkit с кастомной drag-логикой.
Данные диалогов храним в ScriptableObject с [SerializeReference] для полиморфного хранения разных типов узлов — это позволяет сериализовать наследников без обёрток и потери типов при десериализации. Если диалоги нужно редактировать вне Unity (нарративщиком без Editor) — используем JSON с кастомной сериализацией или yarn/ink форматы с парсером на стороне Unity.
Валидация и защита от ошибок
Инструмент без валидации переносит ответственность за корректность данных на человека — это всегда ошибки. Три уровня защиты:
Inline validation в редакторе. [Required] аттрибут через кастомный PropertyDrawer который рисует красную рамку вокруг пустого обязательного поля. Видно сразу, до сохранения.
Pre-build validation. IPreprocessBuildWithReport.OnPreprocessBuild() — метод, который вызывается перед каждой сборкой. Обходим все ScriptableObject ассеты нужного типа через AssetDatabase.FindAssets, проверяем обязательные поля, null-ссылки, дубликаты ID. При нахождении ошибки — throw BuildFailedException с описанием что и где сломано. Билд не запускается с битыми данными.
Runtime assertions. В Debug-сборках: Debug.Assert(quest.reward != null, $"Quest {quest.id} has null reward"). Дёшево и ловит то, что прошло через первые два уровня.
Кастомные Gizmo и Scene View Tools
Для уровневых редакторов: кастомные Handles в Scene View через Handles.DrawWireCube, Handles.DrawBezier, HandleUtility.PickGameObject — позволяют визуализировать игровые данные прямо в сцене. Спаун-зоны, пути патрулирования, триггерные зоны — редактируемые через drag в Scene View, а не через числа в Inspector.
[DrawGizmo(GizmoType.Selected)] аттрибут рисует кастомный Gizmo без OnDrawGizmos() на компоненте — чище архитектурно.
Сроки
| Инструмент | Срок |
|---|---|
| CustomEditor / PropertyDrawer для существующего типа | 1–3 дня |
| Простой EditorWindow (таблица данных + CRUD) | 3–7 дней |
| Граф-редактор (диалоги, квесты) со средней сложностью | 2–4 недели |
| Полноценный Level Editor с валидацией и gizmos | 3–8 недель |
Стоимость рассчитывается после описания функциональных требований и анализа структуры игровых данных.





