Розробка інструментів та редакторів для контент-менеджерів ігор
Геймдизайнер хоче додати новий рівень. Без кастомного інструменту це виглядає так: відкриває Unity Editor, створює ScriptableObject, заповнює поля вручну, не видить превю, випадково залишає null в обов'язковому полі — баг обнаруживається в QA через тиждень. З правильним Level Editor всередину Unity: візуальний список рівнів, drag-and-drop порядок, вбудована валідація, превю іконки рівня прямо в інструменті.
Різниця — це не зручність. Це швидкість ітерації та кількість помилок у контенті.
Що будуємо та для яких задач
Custom Editor Windows для роботи з ігровими даними. Типові cases: редактор квестів (дерево залежностей, умови, награди), редактор діалогів (граф з ветками), редактор економіки (таблиця з цінами, курсами валют, балансом), редактор лута (ймовірності, ваги, умови дропа). Все це можна зберігати в 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 — це кілька годин роботи, які економлять години непорозуміння у геймдизайнера.
Редактор діалогів — розбір одного case
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] для полiморфного зберігання різних типів вузлів — це дозволяє серіалізувати нащадків без обгорток та без втрати типів при десеріалізації. Якщо діалоги потрібно редагувати поза 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 тижнів |
Вартість розраховується після опису функціональних вимог та аналізу структури ігрових даних.