Discussion Idea: Editor Component "Containers"

I've been having issues with certain gameobjects just have so many components. This particularly has been happening to my player root gameobject. This makes it hard to edit the player, due to both confusion and rendering lag. I'm planning on doing some redesigns to move some stuff out of the root, buuuut:

One solution that would be pretty interesting would be to have support for "Component Containers". This would ONLY be used in editor, and is purely a visual helper.

The idea is to allow the creation of containers that can be named and folded away.



I wonder if something like this could be done without unity's help... it could potentially be done if we could override the gameobject inspector, but I'm not sure how viable that is. It could then rely on a hidden component that stores references to each component alongside the collections and their names. Using a component to store this information would mean it automatically supports nested prefabs, which is nice.

Any thoughts? This is just a pipedream of course, just curious what others think.

 

Odin Inspector might be your pal. https://assetstore.unity.com/packages/tools/utilities/odin-inspector-and-serializer-89041

 

Oh, does Odin allow modification of gameobject drawer? if so then it'd probably be pretty easy to implement :O I love Odin

 

Sorta maybe not really. Odin deals with inspectors, as in, how a given type, be it an Unity object or component, is drawn in the inspector. It doesn't have anything built in to actually manipulate the overarching component display, however. I believe that's all very much internal and requires reflection to work with.

Doesn't mean you can't make an editor window that suits your particular work flow.

 

Can't help but wonder if you are trying to address the wrong thing.

For one you can already collapse components, so the suggestion here only really gains the ability to group some together and collapse the group in one go. Sure seems useful, could be useful, but the question I'd be asking is why do you have so many components on a gameObject to start with?

Do all those components absolutely have to be a MonoBehaviour? In many cases it wouldn't surprise me that they could be repurposed into a class and then just have a single 'manager' component on the game object ( should it even be needed ).

Maybe these components have dozens of properties to modify the behaviour of the component? In which case why not replace them with a scriptableObject that acts as a parameter/settings holder. That way should you need to interreact with those properties in the editor you can do so by inspecting the scriptableObject and not the gameobject.

Perhaps you still need all those components, in which case good luck writing your Group inspector, it would be interesting to see it working.

Though personally I'm not sure how much benefit it would really provide, since if you are having to interreact with the components frequently enough to propose this idea, wouldn't you still be interreacting with them, but now you have to expand groups instead and then expand/collapse sub-components of those groups? Does it really gain anything?

 

What would be far easier to implement: Some colorful separator. Like an additional component that just renders a name in a larger font and some visual separator.

I have too made the experience that the player object can become annoyingly large. Especially if you aim to follow the "SOLID" principle "single responsibility" classes to a degree (p.s. never go too far with that in games). They unfortunately tend to be monobehaviors because of having some serliazed configuration variables.
Technically one could put those in a scriptable object which is fetched through some singleton, but that results in all the classes being tied to that one SO.

The alternative I went with is to have some sub-objects just for scripts. Unfortunately that adds overhead due to the unnecessary Transform instances, but for a single instance in the game that's not too terrible.

 

Your comment about using the SOLID principle is an interesting one and like yourself I have dabbled with it in the past.

In theory it should be the way to go and in general with classes I would argue it still is, but in practice, as you note, it just breaks down when applied to gameObjects and their components, not only does it 'pollute' the inspector as indicated by the problem the OP is trying to solve, it can also have performance implications, especially if components have any of the Update methods.

Personally I don't mind linking a scriptableObject to a single component, though could see it being a bit problematic when you don't want to share that with multiple instances of the component. I wonder if there is a better solution to doing that?

As for the sub-objects, it was something I was going to suggest in my previous post, but it just had a bit of a code/Unity smell to it. Not that I think there are particularly any better alternatives and very much of the mind that if it works go for it. Personally I'd probably still favour focusing on using classes and then a single manager object if it was feasible, but overall there doesn't seem to be a great solution for this type of problem.

So I guess what we have here are two problems with a single cause, mainly proliferation of components on a gameObject, which happens to be the way Unity is design. The first issue is that it can end up cluttering the interface that gets in the way of efficient usability, the second is that its inefficient, though that will likely only have an impact if you really abuse it, with many components on many gameObjects.

For the second one possibility is to switch to DOTS, that's what its designed for, but it doesn't really apply to all cases. Plus I feel like Unity's 'automatic behind the scene conversion' from MonoBehaviour to DOTS has stalled as i've not heard of any progress for a long time. So while you might have a few gameObjects with excessive number of components, it should be pretty infrequent and thus not a really issue.

As for the visual aspect, if you can't architect around it, I'm not sure what better alternatives there are that haven't yet been discussed. It could be really cool to have some special inspector code, along the lines of the OP's suggestion that somehow presents many components in a more visual pleasing and efficient way.

Something that occurred to me writing this post is what if components ( maybe only non-native ones ) were part of a horizontal scroll area instead of the vertical scroll area that the whole inspector uses currently? Maybe backed up with a 'quick select' feature, like a dropdown, or buttons to quickly cycle through? For me its always a pain scrolling up/down as screens are generally not that long. I'm not sure if having a sub-section that scrolls horizontally ( per component ) is much better, but it would be interesting to see.

Anyway an interesting conversation and honestly I do feel the editor interface needs some redesigning. While it looks so much better than it use to, efficient and effective use of screen space is a constant battle for myself. Throwing more screens can help to a degree, but I can't help feeling there might be some new paradigm that could help make the layout easier to use.

 

True albeit that is nowadays a code smell to a degree as well. Whenever possible have one-off triggers (event oriented and/or via coroutines) instead of constantly running update methods that check something to react on a condition.
Player input can avoid Update() now too with the "new" Input System.

 

I implemented something like this for one of my assets back in the day. I made it work by the categories being generated automatically based on the AddComponentMenu path.



One way to achieve this with the default Inspector would be like this:

1. Hook into Editor.finishedDefaultHeaderGUI to draw additional elements right after the GameObject editor.
2. Use GetComponents to gather all components from the GameObject Editor's targets.
3. Use Editor.CreateCachedEditor to create the editors for drawing all the components.
4. Use HideFlags.HideInInspector to prevent the inspector from drawing the components.
5. Draw the category headers, component headers and component editors.
6. Somehow restore all components back to using their original HideFlags afterwards.

For the UI Toolkit, one could inject some custom UI elements into the Inspector's root visual element instead of using Editor.finishedDefaultHeaderGUI.

 

Quite cool! Think you would get some buyers/users for this as a standalone plugin on the asset store.

 

That's a pretty nice way of doing it as well - by categories.

I agree that there are many ways to skin a cat, and how to exactly use components VS class "modules".

I come from more traditional gamedev, without component based systems. Thus when I started building my game, I used larger classes alongside other classes that would act as modules. I also heavily used scriptable objects. I even built a system that makes scriptable objects support variants.

The big negative with scriptable objects and classes is a lack of editor modularity. I end up with large systems that are essentially hard coded, and with scriptable objects relatively hard coded. This has greatly reduced the flexibility of the systems, especially when I want to do something like create a monster with unique mechanics. Note that this game is an open world game with pretty open ended mechanics. It's a complex beast that is pretty high in scale. The player has hundreds of features.

Thus, I'm shifting a bit towards a more component based approach. But of course, now I'm running into the visual issue.

I will also point out that this issue is far more prevalent in ECS design. I wonder if unity will create better tooling to visually handle huge numbers of components.

 

You've encountered downside of SOLID principle and the reason why I do not put it at the same level as KISS.

SOLID principle can easily lead to situation where you have a bazillion of different tiny classes cluttering your code, because of the "single responsibility" part.

Order of comonents matter, because of [RequireComponent()]. So you can't always group. Then again, not every comonent has RequireComponent attribute.

 

How does order of components relate to RequireComponent dependencies? I'm pretty sure that you can move them up and down regardless of dependencies, so the visual order already doesn't represent them reliably (especially when prefabs are involved). In any case, there are multiple ways to represent dependencies, and while the built-in approach works I'm confident it can be improved upon.

- - -

I occasionally end up with a few GameObjects which have many components, and when editing them would sure love an improved Inspector. My in-Editor framerate depends less on what my stuff is doing and more on what GameObject is selected, because the Inspector (and its de/serialization) is such a hog.

A few improvements which I really ought to just implement some time:
- Add a filter to the Inspector, to collapse / cull components based on a partial string match. Two reasons:
1. Drastically reduce scrolling and visual clutter if I only care about one component.
2. Hopefully improve Inspector performance by not updating components I don't care about.
- Add names to components within GameObjects, separately to their types. That way if I have multiple AudioSources or Colliders, for instance, I can identify eachdistinctly. This may not be feasilble, because to be useful it would require support in more places than just the Inspector headers.
- A "Comment" component. This one is trivially easily, and I know there are existing solutions around. We document stuff elsewhere, so it's not really a problem, but it'd be super cool if it could be right there in our project instead of elsewhere.

 

Alright, fair point.

My comment stemmed from a habit of ordering components in order of "initialization". Meaning Required component comes first in the list. In this scenario you can end up in a situation. where C depends on B which depends on A, but A and C share a category and B is a separate.

Unreal engine does a lot of things you ask for, but I sincerely doubt that is the right way.

The problem is that with their approach you'd end up with a huge pile of information dumped into owning actor. You can filter it, but it is not easy to discern which piece of information belongs to which part.

In unity each comonent gets its own personal box.

 

I still want that to happen. I want the filter to just change which component boxes are open.

There may be better things than a string filter, too. My mind jumps to that as it's consistent with the Hierarchy and Project tabs.

 

I think that's more an issue with Unreal Engine's particular implementation.

If you also visualize all the parents (GameObject header, component header, declaring types) and nested members of filter results, I think it's quite easy to distinguish what you're looking at.

 

What if there was just 'one component to rule them all' that had a filter setting, and would then show the components GUI within the 'master component' based on that filter? To be specific I'm not talking about a filter that shows/hides other components, but instead the 'master' component is capable of showing the gui of any other or collection of multiple components in a streamlined fashion?

Maybe since you'd still have to have all the components on the gameObject and this is just addressing the visual aspect, we could have an improved 'Properties' inspector ( Unity added a basic properties inspector at some point ) which as stated above can show multiple component gui's within itself, getting rid of the clunky component bar and streamlining the overall appearance.

Edit:
Thinking about it, this would probably not look a whole lot different as components don't waste space or duplicate much infromation these days. However the one difference would be that instead of components being collapsed, they simply wouldn't show up in the master view.

I think this might be part of what I want, that in a gameObject with many components, even with most of them collapsed, their title bar still takes up space and breaks up the flow. I wonder if an option to Hide/show collapsed components might have some value for some situations.




Alternatively if we want to get really crazy how about ( and this might already exist ) a mobile app that is dedicated to showing the inspector ( maybe a few other tabs ), so you could use that device simultaneously with the editor. I guess most phones are a bit small to be comfortable, but tablets could work. Added bonus this would work whilst running game view in maximised view too.

No disrespect to your work, but can I just say how god damn ugly and awful the old Unity UI style was!

Isn't in odd that at the time it didn't feel to bad, but it was certainly left to age badly for too long. Heck even today I'm finding it hard to go back to 2019 now I'm more used to 2021 and the changes are far less impactful.

 

Haha, for sure! I remember when the modern/flat UI came out in 2019, it looked kind of nice to me, but I also felt like it was a pretty unnecessary change. But now the old UI looks so dated I'm very happy they revised the look

That concept reminds me a little bit about the (no longer available) Spotlight Inspector.

 

Very interesting, wonder why its no longer available?

The concept is cool and pretty close to the 'one component to rule them all' idea. The aesthetic feels a bit rough, but that should be easy to fix. Strangely when watching the video, I kind of missed the component views, though again that could be due to aesthetic. I still feel like I want the components I'm not interested in to be hidden in the list view, to reduce space and clutter, I feel like that is a major aspect of what I'd like, but it still doesn't quite fit with this concept.

I feel like at this point it might be worth looking outside Unity and its contemporaries to see what advancements have been made elsewhere in the UI layout/design.

 

I don't have a strong feeling about that, but just don't see much point.

I think that at some point you'd want to move important data outside of components and treat components as an unreliable data storage.

 

We do the former where it's relevant, but it's solving a different problem.

I'm not sure why I'd want to consider Components as "unreliable". If I couldn't rely on them to keep their properties then they would be useless, and that'd pretty much kill Unity as a dev environment. For typical usage scenarios in a decently managed project I find them to be very reliable.

 

In all of this conversation, I can't help being disappointed that Unity Tech doesn't seem to have a team or given time to a team to explore alternative layouts and paradigms for the editor, and post demo editor versions for users to test.

Just from this one conversation there are a bunch of interesting ideas that could be explored and that is just for the inspector. Years ago I posted a thread here wanting to improve the maximise function of windows, where you could maximise a sub-window ( tab ) into its parent and back again. So often I find that a tab can be one size ( width) but occasionally I ned to expand it, and such a maximise function would be perfect. Of course nothing ever happened, don't think the thread was even picked up by a UT developer.

.. and don't get me started on the Unity Hub. It feels like its got one developer working on the weekend, where important community feature requests can take 3-5 years to get implement, if ever and usually poorly.

I wasn't a huge fan of the Hub to start with, but as a central place to deal with all your Unity projects it could be really useful, but it feels like its stuck as a glorified loader ( of your last 30 projects ) and Editor installer. Yet it could be so much more, like provide data on which projects are using what editor version, which packages are in use across projects, add thumbnail/screenshot support to projects, so we can have a visual reminder of what a project creates etc.

 

Short version: If you want to change the Inspector, then change the Inspector.

Long version: What's the benefit of the "master component" over extending / replacing the Inspector? I can think of a couple of downsides. One is that you'd have to add the component to GameObjects, and the UI would be inconsistent between GameObjects with and without it. Another is that you'd have to hack around the Inspector wanting to draw the other components anyway, and just collapsing them has side effects. Another is that it's an implementation which is clearly at cross-purposes to the existing software design* and thus an easy way to turn your code into both spaghetti, and a minefield. (This is discussed elsewhere at length as the Single Responsibility Principle, already mentioned earlier in this thread.)

* The purpose of a Component is to add functionality to a GO. The purpose of the Inspector is to edit a GO.

 

I think it was a poor use of terminology on my part. It would indeed be a new inspector type and not a component added to the existing gameObject. It is simply a change in visual presentation of data ( components on gameObject ) so yeah new type of inspector fits better. Very much like the video SisusCo posted.

Though having realised this and fine tuned a few of my other thoughts here I have a plan in mind for an improved inspector. We'll see if I have the time and inclination to to implement it.

However at present I'm writing a Project manager tool to provide details on which projects are using what version of the editor and what package versions are used within projects. Idea being you can sort by different options and get a clearer indication as to what is being used by projects. For example i'd like to go through old projects and bring all the visual studio package up to the same version, or all projects using burst, then I can delete the npm and extract packages from the cache and gain back so of the 20GB of space being wasted by Unity.