Розробка кастомних редакторів для контент-менеджерів ігор

Наша компанія з розробки відеоігор веде незалежні проекти, спільно з клієнтом створює ігри та надає додаткові операційні послуги. Досвід нашої команди дозволяє нам охопити всі ігрові платформи та розробити приголомшливий продукт, що відповідає баченню клієнта та перевагам гравців.

Від імерсивних застосунків до ігрових світів і 3D-сцен

Наша виділена команда для VR/AR/MR-розробки, Unity-продакшну і 3D-моделювання та анімації — з власними кейсами і презентаціями.

Відвідати персоналізований сайт
Показано 1 з 1Усі 242 послуг
Розробка кастомних редакторів для контент-менеджерів ігор
Складний
~10 днів
Часті запитання

Наші компетенції

Які етапи розробки гри?

Останні роботи

  • image_games_mortal_motors_495_0.webp
    Розробка гри для компанії Mortal Motors
    1457
  • image_games_a_turnbased_strategy_game_set_in_a_fantasy_setting_with_fire_and_sword_603_0.webp
    Покрокова стратегія у фентезі сеттингу With Fire And Sword
    979
  • image_games_second_team_604_0.webp
    Розробка ігри для компанії Second term
    605
  • image_games_phoenix_ii_606_0.webp
    3D-анімація – тизер для гри phoenix 2.
    674
  • image_training-quizzes_kids_shopping_quiz_614_0.webp
    Навчальна вікторина для дітей «Покупки в магазині»
    29

Ми спеціалізуємося на кастомних редакторах для контент-менеджерів ігор. Один із наших клієнтів — геймдизайнер — хотів додати новий рівень у мобільний RPG-проект. Без кастомного інструменту це виглядає так: він відкриває Unity Editor, створює ScriptableObject, заповнює поля вручну, не бачить прев'ю, випадково залишає null в обов'язковому полі — і баг виявляється в QA через тиждень. Така затримка — тиждень на пошук одного null — коштує проекту часу та грошей. З нашим Level Editor всередині Unity: візуальний список рівнів, drag-and-drop порядок, вбудована валідація, прев'ю іконки рівня прямо в інструменті.

Різниця — не просто зручність. Це швидкість ітерації та кількість помилок у контенті. Наш досвід показує, що кастомні редактори скорочують час наповнення контенту на 40–60% і знижують кількість багів у релізі в 5 разів у порівнянні зі стандартним підходом. Кастомний редактор швидший за ручне заповнення в 3 рази.

У цій статті розберемо, які типи редакторів затребувані в геймдеві, як ми їх реалізуємо на Unity та Unreal Engine, і яку користь вони приносять команді. Оцініть ваш проект безкоштовно — пишіть нам для детальної оцінки.

Які завдання вирішують кастомні редактори?

Custom Editor Windows для роботи з ігровими даними. Типові кейси: редактор квестів (дерево залежностей, умови, нагороди), редактор діалогів (граф з гілками), редактор економіки (таблиця з цінами, курсами валют, балансом), редактор луту (ймовірності, ваги, умови дропу). Все це можна зберігати в ScriptableObject або JSON — але редагувати через стандартний Inspector повільно та небезпечно. Розробка таких інструментів займає від 3 днів до 4 тижнів залежно від складності.

EditorWindow в Unity — базовий клас для будь-якого інструменту. IMGUI (GUILayout, EditorGUILayout) або новий UI Toolkit (USS + UXML) — вибираємо під задачу. Згідно з документацією Unity, UI Toolkit рекомендований для складних інтерфейсів. IMGUI швидший для простих форм і не потребує окремих файлів розмітки.

PropertyDrawer та CustomEditor — коли не потрібне окреме вікно, але потрібно покращити відображення конкретного ScriptableObject або Component в Inspector. [CustomPropertyDrawer(typeof(LootTable))] з візуалізацією ваг у вигляді маленької гістограми прямо в Inspector — це кілька годин роботи, які економлять години нерозуміння у геймдизайнера.

Як ми будували редактор діалогів для RPG — кейс із практики

Graphy-подібний редактор діалогів — найзапитуваніший тип інструменту. Вимоги: вузли з текстом реплік, гілки вибору, умови (перевірка флагів, прогресу), локалізація. У проекті було 50+ вузлів, 20 типів умов — редактор скоротив час введення діалогів у 3 рази.

Стандартний підхід — на основі 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, який малює червону рамку навколо порожнього обов'язкового поля. Видно одразу, до збереження. Inline validation скорочує кількість помилок на етапі редагування на 90%.

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"). Дешево і ловить те, що пройшло через перші два рівні.

Приклад коду inline-валідації ```csharp [CustomPropertyDrawer(typeof(LootTable))] public class LootTableDrawer : PropertyDrawer { public override void OnGUI(Rect position, SerializedProperty property, GUIContent label) { EditorGUI.BeginProperty(position, label, property); // відмалювання з валідацією EditorGUI.EndProperty(); } } ```

Кастомні Gizmo та Scene View Tools

Для ровневих редакторів: кастомні Handles в Scene View через Handles.DrawWireCube, Handles.DrawBezier, HandleUtility.PickGameObject — дозволяють візуалізувати ігрові дані прямо в сцені. Спаун-зони, шляхи патрулювання, тригерні зони — редаговані через drag в Scene View, а не через числа в Inspector.

[DrawGizmo(GizmoType.Selected)] атрибут малює кастомний Gizmo без OnDrawGizmos() на компоненті — чистіше архітектурно.

Що входить в роботу

Етап Результат Приблизні терміни
Аналіз структури даних Специфікація редактора та схема даних 1–2 дні
Прототипування інтерфейсу Mockup в UI Toolkit або Figma 2–4 дні
Реалізація ядра Функціонал CRUD, валідація, серіалізація 3–10 днів
Інтеграція з проектом Підключення до існуючих систем 1–3 дні
Документація та навчання Посібник користувача та відеосесія 1–2 дні

Терміни та вартість

Інструмент Термін Вартість
CustomEditor / PropertyDrawer для існуючого типу 1–3 дні $300–$700
Простий EditorWindow (таблиця даних + CRUD) 3–7 днів $700–$1500
Граф-редактор (діалоги, квести) з середньою складністю 2–4 тижні $1500–$4000
Повноцінний Level Editor з валідацією та gizmos 3–8 тижнів $4000–$10000

Наприклад, один з наших клієнтів заощадив понад $3000 на місяць після впровадження кастомного редактора луту. Вартість розраховується після опису функціональних вимог та аналізу структури ігрових даних. Інструмент окупається за 2–3 місяці за рахунок скорочення помилок контенту. У нас за плечима 5+ років досвіду в геймдеві, понад 30 реалізованих інструментів для студій різних розмірів. Ми надаємо гарантію якості на всі розроблені інструменти протягом 60 днів. Наші спеціалісти сертифіковані за напрямками Unity та Unreal Engine.

Покрокова інструкція створення простого редактора:

  1. Проаналізуйте структуру ігрових даних та визначте поля.
  2. Створіть новий клас EditorWindow та додайте інтерфейс через UI Toolkit або IMGUI.
  3. Реалізуйте CRUD-операції та валідацію.
  4. Протестуйте інструмент з контент-менеджером та внесіть правки.

Ми виконаємо роботу під ключ за 1–4 тижні. Оцініть, як кастомний інструмент прискорить роботу вашої команди. Пишіть нам для безкоштовної оцінки вашого проекту.

Підтримка та розвиток ігор

Релиз — це не фінальний білд, а старт системи неперервної підтримки. У нашій практиці 80% проєктів без live ops втрачають до 30% аудиторії в перші два тижні: crash-рейтинг вище 1%, онбординг відсіває 40% нових гравців, контентні оновлення застрягають у рев'ю сторів на 3–4 дні. Ми вирішуємо це зв'язкою Remote Config, crash reporting та A/B-тестів. Зв'яжіться з нами — оцінка поточного стану проєкту займе один день.

Проблеми, які вирішує підтримка та розвиток ігор

  • Retention — без онбордингу за даними аналітики D1 падає до 45%. Ми перебудовуємо туторіал: скорочуємо кроки з 10 до 4, додаємо пропуск для повертаючих гравців. Результат: +18% до D3.
  • Контентна втома — якщо новий контент не виходить кожні 2–3 тижні, D30 падає на 25%. Вводимо сезонні події через Remote Config без нової збірки.
  • Технічний борг — міграція на Unity 6 LTS з попередньої версії знижує FPS-баги на 30%, але вимагає оновлення SDK (Firebase, Adjust, AppLovin). Відкладання призводить до блокування публікації через застарілі бібліотеки.

Live ops як головний інструмент підтримки ігор

Здатність змінювати поведінку гри без перевипуску додатку — основа сучасної пост-релізної стратегії. Правильно побудований pipeline дозволяє змінити баланс, включити івент або протестувати нову монетизаційну механіку за 15 хвилин, не чіпаючи збірку. За вісім років ми пройшли шлях від хотфіксів через стори до повноцінної live ops-архітектури, яка економить до 30% часу на контентні оновлення.

Архітектура Remote Config

Типова схема виглядає так:

Dashboard / CMS
      ↓
Remote Config Provider (Firebase / PlayFab)
      ↓
Game Client (fetch on session start + періодичний polling)
      ↓
Local Cache (fallback при відсутності мережі)

Firebase Remote Config — найбільш поширене рішення для мобільних ігор. Ключі зберігаються в консолі, клієнт отримує їх при старті сесії через RemoteConfig.FetchAndActivateAsync(). Важливий момент: Firebase кешує значення на 12 годин за замовчуванням — у продакшні потрібно явно налаштовувати minimumFetchInterval. Для живих івентів використовуємо minimumFetchInterval = 0 з ручним throttling на клієнті. Firebase Remote Config Documentation.

PlayFab дає більше можливостей для game-специфічних сценаріїв: Title Data, Player Data, CloudScript. Зручно для серверної валідації покупок, зберігання прогресу гравця та A/B-тестування сегментів. Якщо у гри є серверна складова (PvP, leaderboards, інвентар), PlayFab часто вигідніше Firebase за сукупністю функцій. PlayFab підтримує ключі до 1 МБ, що в 16 разів більше ліміту Firebase (64 КБ).

Типова структура ключів Remote Config

Ключ Тип Приклад значення
event_halloween_active bool true
event_halloween_end_ts long 1730332800
iap_sale_multiplier float 2.0
tutorial_skip_enabled bool false
daily_reward_sequence JSON [10, 20, 50, 100, 200]
ads_interstitial_cooldown_sec int 120

Порівняння Firebase Remote Config і PlayFab Title Data

Критерій Firebase Remote Config PlayFab Title Data
Максимальний розмір ключа 64 KB (загальний ліміт) 1 MB на ключ
Типи даних примітиви + JSON рядки (JSON всередині)
A/B-тестування вбудоване (Firebase A/B Testing) через CloudScript + сегменти
Безкоштовний ліміт 10M запитів/міс необмежено для базових викликів
Робота в офлайні кеш на 12 годин кеш на 1 годину (налаштовується)
Приклад налаштування ключа для сезонного івенту

Ключ event_config містить JSON з параметрами: active, end_ts, reward_multiplier. Клієнт завантажує при старті сесії. Якщо ключ відсутній або сервер недоступний — використовується кешоване значення з попередньої сесії. Це гарантує, що гра не «зламається» при проблемах з мережею.

Як Remote Config прискорює доставку контенту?

A/B-тести через Firebase дозволяють розподіляти користувачів за групами та збирати статистику по retention D1/D7, revenue і custom events. Один користувач завжди потрапляє в одну групу завдяки прив'язці до Installation ID. Якщо тест зав'язаний на монетизацію — додатково перевіряємо через Unity Analytics, що розподіл покупок випадковий. Середній ріст retention D7 після впровадження таких тестів — 12%.

Як ми моніторимо стабільність гри?

Без crash reporting ви дізнаєтеся про критичні баги з відгуків, а не з дашборду. Firebase Crashlytics — стандарт для мобільних ігор. Інтегрується через Firebase SDK, автоматично фіксує необроблені виключення C# та native crashes (включаючи IL2CPP).

Crash-free users rate — має бути вище 99.5% для стабільного проєкту. ANR rate — часта проблема при важких завантаженнях на головному потоці. Top crashes за кількістю зачеплених користувачів — не за кількістю подій.

Backtrace використовуємо для проєктів з нативним кодом або складною C++ складовою (Unreal, кастомні плагіни). Backtrace краще декодує символи для нативних крашів. Для Unity-проєктів налаштовуємо Unity Cloud Diagnostics — дає додатковий контекст по помилках движка.

Аналітика та ітерація контенту

Unity Analytics (колишній Unity Gaming Services Analytics) використовуємо для трекінгу воронок. Для більш складних сценаріїв — власний event pipeline з відправкою в BigQuery або ClickHouse. Мінімальний набір подій:

  • session_start / session_end
  • level_start / level_complete / level_fail
  • tutorial_step_N
  • iap_purchase / ad_watched
  • feature_unlocked

За цими даними видно, де аудиторія відвалюється, який контент не працює і куди вкладати сили наступного апдейту.

Що входить у підтримку та розвиток ігор

  • Налаштування Remote Config зі схемою ключів і документацією.
  • Інтеграція crash reporting (Firebase Crashlytics, Unity Cloud Diagnostics) з алертами.
  • Проведення A/B-тестів і аналіз результатів.
  • Контентні спринти: нові івенти, балансування, сезонний контент.
  • Щотижнева аналітика та звіти за метриками.
  • SLA для критичних багів — до 24 годин.

Процес роботи та терміни

Для проєктів на підтримці використовуємо виділений ритм: щотижневі звіти за метриками, спринти по 2 тижні для контентних апдейтів, черговий інженер на критичні баги з SLA до 24 годин. Всі зміни проходять через стейджинг-середовище перед деплоєм у прод.

Терміни впровадження live ops — від 2 до 4 тижнів залежно від складності та поточної архітектури. Вартість розраховується індивідуально, але в середньому економія на контентні оновлення складає 30–40% бюджету порівняно з традиційними хотфіксами (до $3000 щомісяця). Ми гарантуємо дотримання термінів і прозоре ціноутворення — замовте аудит вашого проєкту, і ми підготуємо кошторис за один день.

Отримати консультацію з налаштування підтримки та розвитку ігор — зв'яжіться з нами. Досвід супроводу понад 50 проєктів різного масштабу підтверджений сертифікованими спеціалістами Unity та PlayFab. Пишіть нам — ми проконсультуємо вас з будь-яких технічних питань.