I’ve been wondering for a while now why Unity doesn’t offer a out-of-the-box way to create instances of a derived base type from within the Inspector?
Let’s say I have;
public MyBaseType myInstance;
And in my code base, I got 4-5 classes that derive from MyBaseType. Of course, Unity got a hard time with polymorphism to begin with, but there’s some way to bypass the problem. I should have the ability to create an instance that derive from MyBaseType from within the Inspector. For some reason, the expected behaviour is to always fill field manually. It’s really annoying and counter-productive.
Also, I wondered why the Inspector never let you inspect object that are within a field? It never let you dig down a hierarchy of reference.
Or why you can’t define how a specific type’s field is drawn. Custom Editor are always for a whole class, not for a type’s field.
Frankly, it had been quite a challenge to implement a robust and bullet proof system to offer that, but I really don’t understand why the stock Inspector is so limited.
Am I alone to think the stock Inspector could use a lot more love and work?
From a pure serialization perspective how would you propose that Unity handle derived types? It’s impossible to know every derivation which is why most (all?) serialization frameworks make you be explicit with what types you’re allowing.
Also - AFAIK drag-drop functionality will work with inheritance just fine (I’m assuming this is just a quick “is a” check), so it’s not totally clear what you’re really asking.
Lastly - I personally wouldn’t be a fan of fields being drawn inconsistently between different types, but that’s just me.
From a pure serialization point of view, Unity handle polymorphism pretty well… as long as you use ScriptableObject or MonoBehaviour as you base class.
Also, it’s totally possible to know every derivation of a class. Reflection exist for that specific purpose.
Let’s give an example;
This is a camera class that is built in a modular approach.
Let’s say I want to manage the “position” of the camera, and the system uses a “CameraPositionner” for that. “CameraPositionner” is an abstract class that only gives a specific method signature. Currently, I got 4 different classes that derive from this base class, and each offer a different “position” behaviour for the camera. I click the “+” sign and;
A popup shows up to give me the list of appropriated sub-type for that specific field. I select “Input Positionner” and;
There you go. I got an instance of that specific type.
By the way, this is not a mockup made in photoshop. This is a functional framework I’m using right now.
No limit in depth of object within object… Even polymorphic lists;
Reflection will work as long as all your derived types are in the same Assembly, which isn’t guaranteed. It might work for your use case but I was speaking more generally.
foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
{
foreach (Type type in assembly.GetTypes())
{
Obviously, dependency between assembly is tricky, but not impossible. But you’re nitpicking here; if your class is able to derive from another, you can retrieve all that by Reflection.
I’m not nitpicking - just providing a different point of view based on my experiences with different serialization frameworks.
Your main question was - “Why doesn’t Unity do this” and my response was that, generally, serialization solutions don’t do that - they force you to be explicit. That’s all.
Frankly, Unity is the first video game editor I’ve used that doesn’t give me, right out of the box, an anonymous polymorphic solution. Of course, I’m used with working with internal video game engine.
The lack of polymorphism on class deriving from System.Object is mind-blowing.
