Development of Custom Editors for Content Managers in Games
One of our clients — a game designer — wanted to add a new level to a mobile RPG project. Without a custom tool, the process looks like this: he opens Unity Editor, creates a ScriptableObject, fills fields manually, sees no preview, accidentally leaves a null in a mandatory field — and the bug is discovered in QA a week later. That delay — a week to find one null — costs the project time and money. With our Level Editor inside Unity: visual level list, drag-and-drop order, built-in validation, level icon preview right in the tool.
The difference is not just convenience. It's iteration speed and the number of content bugs. Our experience shows that custom editors reduce content creation time by 40–60% and cut release bugs by 5x.
In this article we’ll examine which editor types are in demand in gamedev, how we implement them in Unity and Unreal Engine, and what benefits they bring to the team. If you need a custom tool — contact us for an initial analysis.
What problems do custom editors solve?
Custom Editor Windows for working with game data. Typical cases: quest editor (dependency tree, conditions, rewards), dialogue editor (branching graph), economy editor (price tables, exchange rates, balance), loot editor (probabilities, weights, drop conditions). All of this can be stored in ScriptableObject or JSON — but editing via the standard Inspector is slow and error-prone. Development of such tools takes from 3 days to 4 weeks depending on complexity.
EditorWindow in Unity is the base class for any tool. IMGUI (GUILayout, EditorGUILayout) or the new UI Toolkit (USS + UXML) — we choose based on the task. UI Toolkit is preferable for complex interfaces with trees, lists, drag-and-drop. IMGUI is faster for simple forms and doesn't require separate markup files.
PropertyDrawer and CustomEditor — when you don't need a separate window but want to improve the display of a specific ScriptableObject or Component in the Inspector. [CustomPropertyDrawer(typeof(LootTable))] with weight visualization as a small histogram right in the Inspector — that's a few hours of work that saves hours of confusion for the game designer.
How we built a dialogue editor for an RPG — a case from practice
A graph-like dialogue editor is the most requested type of tool. Requirements: nodes with speech text, choice branches, conditions (flag checks, progress), localization. The project had 50+ nodes, 20 types of conditions — the editor cut dialogue input time by 3x.
The standard approach is based on the GraphView API (namespace UnityEditor.Experimental.GraphView). GraphView provides pan, zoom, select, copy-paste out of the box. Custom Node classes inherit from UnityEditor.Experimental.GraphView.Node, ports (Port) define inputs and outputs.
The problem with GraphView: it has been marked as Experimental since Unity 2019 and has officially never become stable. This means potential breaking changes when upgrading the engine. Alternatives for new projects are xNode (open source) or a custom implementation on UI Toolkit with custom drag logic.
Dialogue data is stored in ScriptableObject with [SerializeReference] for polymorphic storage of different node types — this allows serialization of inherited types without wrappers and avoids type loss during deserialization. If dialogues need to be edited outside Unity (by a narrative designer without the Editor) — we use JSON with custom serialization or yarn/ink formats with a parser on the Unity side.
How does validation prevent errors?
A tool without validation shifts responsibility for data correctness to the person — that always leads to errors. Three levels of protection:
Inline validation in the editor. [Required] attribute via a custom PropertyDrawer that draws a red border around empty mandatory fields. Visible immediately, before saving. Inline validation reduces editing-time errors by 90%.
Pre-build validation. IPreprocessBuildWithReport.OnPreprocessBuild() — a method called before each build. We iterate all ScriptableObject assets of the required type via AssetDatabase.FindAssets, check mandatory fields, null references, duplicate IDs. If an error is found — we throw BuildFailedException with a description of what and where is broken. The build does not 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 through the first two levels.
Inline validation code example
```csharp
[CustomPropertyDrawer(typeof(LootTable))]
public class LootTableDrawer : PropertyDrawer
{
public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
{
EditorGUI.BeginProperty(position, label, property);
// drawing with validation
EditorGUI.EndProperty();
}
}
```
Custom Gizmo and Scene View Tools
For level editors: custom Handles in Scene View via Handles.DrawWireCube, Handles.DrawBezier, HandleUtility.PickGameObject — allow visualizing game data directly in the scene. Spawn zones, patrol paths, trigger zones — editable via drag in Scene View, not via numbers in Inspector.
[DrawGizmo(GizmoType.Selected)] attribute draws a custom Gizmo without OnDrawGizmos() on the component — cleaner architecture.
What is included in the work
| Stage |
Result |
Approximate time |
| Data structure analysis |
Editor specification and data schema |
1–2 days |
| Interface prototyping |
Mockup in UI Toolkit or Figma |
2–4 days |
| Core implementation |
CRUD functionality, validation, serialization |
3–10 days |
| Project integration |
Connection to existing systems |
1–3 days |
| Documentation and training |
User manual and video session |
1–2 days |
Timelines
| Tool |
Time |
| CustomEditor / PropertyDrawer for existing type |
1–3 days |
| Simple EditorWindow (data table + CRUD) |
3–7 days |
| Graph editor (dialogues, quests) with medium complexity |
2–4 weeks |
| Full Level Editor with validation and gizmos |
3–8 weeks |
The cost is calculated after describing functional requirements and analyzing the game data structure. The tool pays for itself within 2–3 months by reducing content errors. We have over 5 years of gamedev experience and more than 30 implemented tools for studios of various sizes. Assess how a custom tool can speed up your team's workflow. Ready to discuss your editor? Contact us for a detailed evaluation.
Game Support and Development Services
Release is not the final build — it's the start of a continuous support system. In our practice, 80% of projects without live ops lose up to 30% of their audience in the first two weeks: crash rates above 1%, onboarding drops 40% of new players, and content updates get stuck in store review for 3–4 days. We solve this with Remote Config, crash reporting, and A/B testing. With over 8 years of experience in mobile game live operations, we've supported 40+ titles and helped reduce post-launch churn by an average of 25%. Assessing your project's current state takes one day — contact us to schedule an audit.
What game support problems do we solve?
Problems we tackle include retention drop, content fatigue, and technical debt. Without analytics-driven onboarding, D1 retention falls to 45%. We rebuild tutorials: reduce steps from 10 to 4, add a skip option for returning players — result: +18% D3 retention. If new content isn't released every 2–3 weeks, D30 retention drops by 25%. We introduce seasonal events via Remote Config without a new build. Migrating to Unity 6 LTS from an older version lowers FPS bugs by 30%, but requires SDK updates (Firebase, Adjust, AppLovin). Delaying leads to publishing blocks from outdated libraries — we've seen it happen on projects using SDKs older than two years.
Why live ops matters for post-launch support
The ability to change game behavior without re-releasing the app is the foundation of modern post-launch strategy. A well-structured pipeline allows you to adjust balance, enable events, or test new monetization mechanics in 15 minutes without touching the build. Over the years, we've moved from store-based hotfixes to a full live ops architecture that saves up to 30% of time on content updates. According to Firebase official documentation, proper Remote Config setup can reduce update cycles from weeks to hours. (As noted on Wikipedia, Remote Config is used by thousands of mobile games globally for dynamic control.)
Remote Config Architecture
A typical setup:
Dashboard / CMS
↓
Remote Config Provider (Firebase / PlayFab)
↓
Game Client (fetch on session start + periodic polling)
↓
Local Cache (fallback when no network)
Firebase Remote Config is the most common solution for mobile games. Keys are stored in the console; the client fetches them on session start via RemoteConfig.FetchAndActivateAsync(). Important: Firebase caches values for 12 hours by default — in production you must explicitly set minimumFetchInterval. For live events we use minimumFetchInterval = 0 with manual client throttling. See Firebase Remote Config documentation on Wikipedia for details.
PlayFab offers Title Data, Player Data, and CloudScript — great for server-side purchase validation, player progress storage, and A/B testing segments. If your game has a server component (PvP, leaderboards, inventory), PlayFab often provides more value overall.
Typical Remote Config Key Structure
| Key |
Type |
Example Value |
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 |
Store only what actually changes. Gameplay constants untouched for a year are not candidates.
Comparison: Firebase Remote Config vs. PlayFab Title Data
| Criteria |
Firebase Remote Config |
PlayFab Title Data |
| Max key size |
64 KB (total limit) |
1 MB per key |
| Data types |
primitives + JSON |
strings (JSON inside) |
| A/B testing |
built-in (Firebase A/B Testing) |
via CloudScript + segments |
| Free limit |
10M requests/month |
unlimited for basic calls |
| Offline support |
12-hour cache |
1-hour cache (configurable) |
How does Remote Config speed up content delivery?
A/B tests via Firebase allow you to segment users and collect statistics on D1/D7 retention, revenue, and custom events. Each user is consistently assigned to a group based on Installation ID. If the test affects monetization, we verify via Unity Analytics that purchase distribution is random. Average D7 retention increase after implementing such tests is 12%. Compared to manual app-store rollouts, Remote Config is 4x faster for publishing new events — hours instead of days. That translates to roughly $2,500–$4,000 monthly savings on content update cycles.
How do we monitor game stability?
Without crash reporting, you learn about critical bugs from reviews, not from a dashboard. Firebase Crashlytics is the standard for mobile games. It integrates via Firebase SDK and automatically captures unhandled C# exceptions and native crashes (including IL2CPP).
Key metrics we monitor daily:
- Crash-free users rate: should be above 99.5% for a stable project.
- ANR rate: a common issue with heavy loads on the main thread.
- Top crashes by affected users — not by total events.
For projects with native code or complex C++ components (Unreal, custom plugins), we also use Backtrace — it decodes symbols better for native crashes. For Unity projects, we enable Unity Cloud Diagnostics for additional engine error context.
Analytics and Content Iteration
We use Unity Analytics (formerly Unity Gaming Services Analytics) for funnel tracking. For more complex scenarios, we build a custom event pipeline sending to BigQuery or ClickHouse. Minimum event set:
-
session_start / session_end
-
level_start / level_complete / level_fail
-
tutorial_step_N
-
iap_purchase / ad_watched
-
feature_unlocked
This data shows where the audience drops off, which content underperforms, and where to invest next update efforts.
How to implement live ops: step-by-step plan
-
Audit current state: Analyze crash-free rate, retention, build performance. Identify the tightest bottlenecks.
-
Set up Remote Config: Integrate Firebase or PlayFab, create key schema, configure polling.
-
Implement crash reporting: Integrate Crashlytics, set alerts for crash-free rate below 99%.
-
Launch A/B tests: Start with simple experiments (reward balance, ad frequency), monitor metrics.
-
Regular content sprints: Every two weeks: adjustments based on analytics, new events, optimizations.
Work process and timeline
For projects on support, we use a dedicated rhythm: weekly metric reports, 2-week sprints for content updates, an on-call engineer for critical bugs with SLA up to 24 hours. All changes pass through a staging environment before deploying to production — both Remote Config and code changes.
Live ops implementation takes 2 to 4 weeks depending on complexity and current architecture. Cost is calculated individually, but average monthly savings on content updates range between $2,500 and $4,000 compared to traditional hotfix cycles. Typical live ops setup investment is between $3,000 and $8,000. We guarantee deadlines and transparent pricing — order an audit of your project and we'll provide an estimate within one day. Contact us to get started.
What you get: deliverables
After the engagement you receive:
- Documented Remote Config key schema with version history
- Crash analytics dashboard (Firebase or Backtrace) with alert rules
- Tutorial rewrite report and updated onboarding funnel
- A/B test design with success metrics and monitoring plan
- Access to staging environment and deployment scripts
- 2-week handover session with your team, including runbook for common issues
Common pitfalls we avoid: storing too many keys in Remote Config (keep only dynamic values), forgetting to set minimum fetch interval (leads to wasted quota and stale data), not testing Remote Config changes against offline scenarios (crash on first session), combining A/B test segments with unrelated features (pollutes results), delaying crashlytics integration until after launch (we install it during pre‑production).
Need game support that actually retains players? Request a free audit by email or through the website form — we'll advise on any technical questions.
