I learned C# in Unity so I really never used subclassing.
Usually I just drag and drop references to public variables between scripts attached to gameobjects, but I found myself with a gameobject structure that I would want to subclass in the same way as the hierachy of the gameobjects so I don’t have to link each and every script to each other.
However, subclassing resulted in that all public variables of the top object, became visible and undefined - in all child objects, together with the local variables. Not at all what I expected. Perhaps logical within programming but very messy inspectorwise.
Is there a solution to what I want to achieve? Inspector values on a script that hides inherited public methods and variables in the inspector on local gameobjects, but are displayed in the top class inspector?
Just to be clear on the intention of what you’d like to create, could you describe it in your own words what you’re looking for? An example large enough to explain, but not longer/confusing
If I knew your goals, maybe I could help; I mean about what you want from the class, not the hiding inherited members, etc…
Hiding inherited members in inspector seems to be the correct way to google. No answer thought.
There seems to be all sorts of problems associated trying to hide inherited members in inspector not to mention subclassing and the behaviours of start and awake functions. Probably not worth to mess with it at all.
Okay, maybe I worded my question poorly… For what purpose do you want this setup?
I don’t get why you’d hide the variables. You can hide them on the parent class, if you want, that’s easy… but then I just don’t get what your end goal is here, that’s all.
Variables you’ll never set or just set in code in the parent class?
If I could subclass the parent gameobjects class, I wouldn’t need to add a public class reference in the child and drag drop the parent instance to the child class.
Its a common question among unity oriented programmers it seems. It looks really bad with empty references that aren’t actually empty in the inspector. In my example you see the int, but with gameobjects and animation, they’re all empty in the child.
Edit: Also I would like to warn anyone from trying this out in a project that you care about, since regretting and removing the subclass could trash all your public variables in that particular gameObject hierachy, not just the subclassed one…
Sorry, still doesn’t make sense to me. If you have a reference to a gameobject in a parent class, and attach a child class to any gameobject, you will see the reference in the inspector (won’t be blank, unless you didn’t fill it in).
Then, if that’s not what you meant about it looking bad, and you don’t care about those variables in the child class, then that means you don’t really need a child class at all probably?
Think about this example. In my game I have a Car and a Boat, both of which are Vehicles.
public abstract class Vehicle {
public float maxSpeed;
public float mass;
}
public class Car : Vehicle {
public int numberOfDoors;
}
public class Boat : Vehicle {
public int numberOfDecks;
}
Both Cars and Boats have a maximum speed and a mass, so that’s something that should be represented on Vehicle. Cars don’t have decks, however, and so defining a number of decks doesn’t make sense for a Car. Therefore that information goes on the Boat class instead of Vehicle. Same story in reverse with the number of doors on a car. With this structure a Car script will have the fields maxSpeed, mass and numberOfDoors and a Boat script will have maxSpeed, mass and numberOfDecks. A Vehicle script on its own would make no sense, hence the abstract class.
‘Child class’ is bad terminology. It’s not a parent/child structure like the GameObject hierarchy. Subclasses are their parent class, just with more detail. A Car is a Vehicle, but a Vehicle is not necessarily a car.
It’s a confusing subject to get started in, especially with the apparent (but unfounded) similarities to the GameObject hierarchy.
I’d recommend reading this for some explanation as to why Unity uses the hierarchy it does, and maybe find some tutorials on inheritance in object oriented programming. Hope I helped a little
ah, what I want is to subclass from an instance? That is perhaps impossible? The subclass doesn’t know anything about the parent instance. Thats why the inspector fields are empty.
Yes, but getComponent is not like telling a subclass that it is an instance of a certain base class.
It doesn’t seem to be possible.
Besides, if you drag and drop public variables in the inspector, you can re-order the gameobject relation in the editor regardless of parent/child relation. You can’t do that with getcomponentparent/child.
I honestly think you have some major misunderstandings about how Unity works, and OOP in general. Not really sure I can help much if you keep going down such a broken path with your architecture.
It’s not so much about not sharing knowledge, but the topics @Kiwasi said were general enough, and definitely large enough, to require research on your own. “Sharing Knowledge” in that sense would be copying whatever article was referenced here whole sale, which is not what the forums are for even if it were possible. Since @Kiwasi already said some keywords, I suggest you google them. It will help for you to know how to source for information on your own anyway.
My intent isn’t to hide knowledge. I apologize if I came off that way. I’m trying to direct you to a better structure.
Currently your approach has some fundamental flaws. We could probably hash out a solution that works for you. Something with reflection and custom inspectors could achieve exactly what you want. But the fact that you are trying to hide public variables from a base class on a derived class indicates you are doing something wrong. If a derived class doesn’t need the implementation and interface of the base class, then it shouldn’t inherit from it.
So take a step back and review your structure. Following this path will only lead to pain and suffering.
Yeah…that’ll get folks hopping up and down to help you
A few things:
This is spot on 100%. The whole point of inheritance is that the inheriting thing drags along all the stuff from higher up the type tree. That’s how it works. That’s how it’s designed to work. If you have an issue with how that works given your current situation then you’re not using inheritance correctly or inheritance is not the correct solution to the problem you’re trying to solve. Full stop. End of story.
To leverage some of the language you’ve used in this thread
So if you’ve got Thing A that has some GameObject and Animation properties and then you have Thing B that inherits from Thing A but never does anything with GameObjects or Animations then…why does B inherit from A in the first place? Simply postulating - whatever they have in common should probably be abstracted out to another class that both A and B inherit from.
It doesn’t seem possible because it isn’t possible. Frankly this statement doesn’t make much sense and raises the red flags that others have put forth. You never say “Hey B now you’re a ‘subclass’ of A”. Inheritance is declarative in that if B inherits from A then B is always A but(!) A does not have to be B. @monodokimes tried to illustrate this example earlier.
You’ve admitted that you don’t have much experience with polymorphism and type inheritance but yet you’ve taken offense to people suggesting that you rethink your naive approach to what you’re trying to accomplish. So let’s take a step back and just declare what, in a real world scenario, you’re trying to achieve and let’s see if we can’t figure out a solid approach to solving that particular problem. Hopefully, in the process, we can make some of these other concepts clearer.
