Tried Creating a Context Editor with Odin

Hello! I'm PanKUN.

Using Odin Inspector in an indie project, I created a project-specific "Context Editor" that planners can touch even if they don't have much knowledge of Unity.

The "Context Editor" referred to here is an image of:

"A tool that allows you to edit data related to XX in the game all at once on a single screen"

• Character and stage parameters
• Display text and descriptions
• Reward tables and flag settings

The story is that I made it possible to edit information that I want to handle as a group from a single location.

Overview

Originally, the project managed data structures with ScriptableObject and CSV, but there were issues such as:

• It is difficult to understand "which data is where"
• It is necessary to open many assets to change parameters
• It takes time for planners to search through the Unity Project window

So, I made a dedicated editing screen (Context Editor) with Odin where:

"When touching the specifications of XX, just open this window for now"

Roughly summarizing what I did:

• Created a dedicated window using Odin's OdinEditorWindow
• Bound ScriptableObjects collectively that planners are expected to touch
• Implemented filtering, searching, button operations, etc. quickly with Odin attributes
• Guarded "items that should not be touched" with ReadOnly / Foldout / Box, etc.

This is the configuration.

What I wanted to do

In this context editor, I mainly aimed for the following experiences.

1. Understanding "where to touch" at a glance

• Even if planners are not familiar with Unity,
  • Categories on the left
  • Contents to edit on the right
• I made it so that parameters can be touched with a feeling of "opening Excel" in this form.

Specifically:

• Separating each section with Foldout and Title attributes
• Preparing a frame summarizing only "wording displayed in the game"
• Management IDs and internal flags are ReadOnly and display only

I make full use of Odin's decoration attributes like this.

2. Being able to edit related data across the board

For example, if it is a context of "XX Event",

• Basic settings for the entire event
• Difficulty table for each stage
• Reward table
• Text for guidance

I made it possible to arrange and edit information divided into separate ScriptableObjects in one window.

By using Odin's InlineEditor and TableList,

• Edit the referenced ScriptableObject by expanding it on the spot
• Edit arrays/lists in table format

I was able to paste such UI onto the custom EditorWindow side.

3. Making it so that only safe ranges can be touched

• Fields that I want planners to see but not touch
• Flags that are dangerous to change during development

For these things, I included ingenuities such as:

• Locking with ReadOnly attribute
• Not showing at all with HideIf / ShowIf
• Showing notes with InfoBox

I was conscious of making it a "UI that leaves freedom but is hard to break".

Implementation Configuration

The technical configuration is roughly like this.

1. Base Window Class

• Prepare ContextEditorWindow inheriting OdinEditorWindow
• Make it openable from the menu with MenuItem attribute

using Sirenix.OdinInspector;
using Sirenix.OdinInspector.Editor;
using UnityEditor;
using UnityEngine;

public class ContextEditorWindow : OdinEditorWindow
{
    [MenuItem("Tools/Context Editor")]
    private static void Open()
    {
        GetWindow<ContextEditorWindow>("Context Editor");
    }

    // List targets for planners to touch here
    [Title("Event Basic Settings")]
    [InlineEditor(Expanded = true)]
    public EventConfig eventConfig;

    [Title("Stage Settings")]
    [TableList]
    public StageConfig[] stages;

    [Title("Reward Settings")]
    [TableList]
    public RewardConfig[] rewards;

    // If necessary, place search/filter fields here as well
}

Just by opening the window,

• The contents of the specified ScriptableObject are expanded on the same screen
• Values are edited on the spot, and saving is reflected

You can create such a state.

2. Design on ScriptableObject side

If you make the original data structure into a ScriptableObject beforehand,

• Use as a ScriptableObject as usual in the entire project
• Access from the context editor window only when editing

You can use it in double ways like this.

For example:

[CreateAssetMenu(menuName = "Game/Event")]
public class EventConfig : ScriptableObject
{
    [LabelText("Event Name")]
    public string eventName;
    
    [LabelText("Period")]
    public string durationText;
    
    [LabelText("Description")]
    public string description;
    
    [LabelText("Enabled Flag")]
    public bool isEnabled;
}

If you reference this as a field of the ContextEditorWindow mentioned earlier, when doing InlineEditor on the window side, it will be displayed including Odin decorations.

3. Little UX improvements

Example:

• Button to "Launch test scene only for the selected stage"
• Button to "Initialize reward table with default values"
• Button to "Search and focus data with specific ID"

If you use Odin's Button attribute, you can output methods as buttons directly in the EditorWindow, so you can easily add a little tool feeling.

Actually trying to operate

The merits felt by having planners actually use it were like this.

• The entrance was fixed as "When you want to touch this spec, just open this window"
• Time spent wandering around Unity's Project window and Inspector decreased
• It became easier to log parameter updates and communication (easier to say "I changed here on this screen")
• Since parts that would be troublesome if operated by mistake can be locked from the beginning, accidents decreased

On the other hand, as challenges:

• Maintenance cost of the context editor itself occurs
• When tinkering with the data structure, it is necessary not to forget to reflect on the Editor side as well
• If you build the UI too much, it becomes too much of a "dedicated tool" and flexibility drops

There were also points like that.

Finally

The context editor using Odin felt quite compatible when:

• You want to create a "Unity tool that planners can touch directly"
• You want to quickly prepare a "project-specific editing screen"

In cases where Inspector extensions alone are not enough, but creating an EditorWindow from scratch is hard, just combining Odin attributes and EditorWindow makes it easy to create a tool of "just the right line".

In the future, I would like to challenge:

• A version with a little more organized UI/UX
• Abstraction that can be reused in other projects

If you are interested, I will dig deeper into concrete code and how to use attributes in another article, so I would be happy if you could read it again.