Unity Editor extension to group scripts attached to an object

Let us suppose we have a game object which has hundreds of scripts attached. Now out of those hundreds we can pick out groups responsible for a specific functionality. E.g. there are 15 scripts responsible for moving on the ladder, there 20 scripts which control shooting, 10 scripts which control jumping, etc.

Now it becomes hard to navigate all the scripts when you want to see only a specific feature related scripts.

So, what I want to do is to add some kind of grouping separators in my Inspector view, which would separate groups of scripts from each other.

Of course I know about the following improvements:

• making the codebase structure reasonable by utilizing folders
• placing the scripts close to each other by reordering them in the Inspector view

But still I feel that having the separators would make my life easier.

E.g. as the red lines on screenshot separate script groups, I would like to have something similar in the editor:

I found some documentation related to my question: https://docs.unity3d.com/Manual/editor-PropertyDrawers.html. But it seems that I can only customize the look of a specific script or property, but not the Inspector view. Is it so?

• Breaking functionality into separate reusable components is good, but having hundreds of components on one GameObject is probably taking it too far. In addition to making your life hell as a developer, it's going to bloat your scene/prefab files and possibly impact performance. "15 scripts responsible for moving on the ladder" is crazy. Try condensing a bit. – Kevin Mar 12 at 18:52

I strongly recommend consolidating your scripts so that you don't have hundreds of components on one GameObject. There are many reasons not to get this carried away with components, some of which I mentioned in my comment. Breaking functionality into reusable components is good. Having 15 components for climbing a ladder and 10 components for jumping is getting carried away.

Property drawers are not the correct solution. What you want are custom Editor Windows.


class ShootWindow : EditorWindow {
public static void  ShowWindow (GameObject target) {
Assert.IsNotNull(target);
ShootWindow window = EditorWindow.GetWindow<ShootWindow>();
window.target = target;
}

private GameObject target;

void OnGUI () {
CShoot shoot = target.GetComponent<CShoot>();
CShootMovement movement = target.GetComponent<CShootMovement>();
//etc etc etc

//Draw GUI for editing all of these components here
}
}


You can display the window like this:

[CustomEditor(typeof(CShoot))]
private class CShootEditor : Editor {
override void OnInspectorGUI() {
base.OnInspectorGUI();
if (GUILayout.Button("Show Editor Window")) {
CShoot shoot = (CShoot)target;
ShootWindow.ShowWindow(target.gameObject);
}
}
}


You can use a custom Editor Window for editing multiple components at once with a custom interface. However, if you have hundreds of components on each GameObject, expect to spend many many hours writing all of the relevant Editor Windows. Personally I think your time would be better invested consolidating some of your component scripts.

• Is it bad having a rule: "If I have a script which is > 100 lines long I split it into two or more smaller scripts"? – some1 here Mar 13 at 8:54
• @some1here A rule meant to be followed blindly is a bad rule. I would recommend “if I have a script which has more than one logical purpose, I may choose to split it into two or more scripts each with a single purpose, as long as it increases maintainability, rather than decreases it”. Note also that just because you have two classes, that doesn’t necessarily mean that you have two components. If you really feel like you need multiple scripts to handle ladders, you could still have a single ladder handling component which delegates specific behavior to other, non-component classes. – Ed Marty Mar 15 at 8:09
• @some1here Ed Marty's response is pretty thorough. Another thing to think about is coupling, which refers to situations where one class/component depends heavily on the specific functionality of another class/component. Let's say you have two components for jumping, which call each other's functions frequently and can't be used independently. This can be a good sign that the components might as well be merged. – Kevin Mar 15 at 18:44