- Home /
Unity 3 sealed class GameObject ?
Just testing out the new Unity 3 beta, and imported my project.
My project creates internal objects based from the UnityEngine.GameObject class, and I was warned by the new Unity that it's a Sealed class now.
So... Obviously this was done on purpose, but is there a way or another class similar to GameObject that I can derive my objects from?
Or in otherwords, do I have to re-write the UnityEngine.GameObject class myself, deriving from the base UnityEngine.Object class? That's going to suck...
Hello Cinna$$anonymous$$int. It would be helpful if you provide more details on what you're trying to accomplish.
Well, the UnityEngine.GameObject was a nice base to build my own objects from. It had transform points, texture rendering functions, and other wonderful things. I essentially took the base GameObject from Unity, and added my own variables to make it function how I wanted it to. But now since the class is now sealed, I don't have access to those protected variables from GameObject.., --- Actually, I guess I was just more or less wondering why the Unity $$anonymous$$m sealed UnityEngine.GameObject, and if they created another base similar to it so we could create our own custom scene objects.
Answer by qJake · Jul 16, 2010 at 12:51 AM
You are not supposed to derive from GameObject because it's the base class that everything "is" in the game world, and there probably isn't any support for classes that derive from GameObject when Unity compiles and reads the assembly that you create with code.
The point of scripting Components is so that you can extend the behavior of a GameObject. You have a Transform component, and a Renderer component, and then you are free to code your own components that you attach to game objects. Any scripting you do should somehow be attached to the game object through components.
Of course, you are free to call other classes, methods, and objects that you create that are not components, but rather independent classes; however pretty much all of the communication you do with Game Objects is through component scripting.
So... basically, you're going about this wrong. You need to re-think up a solution to your problem that does not involve extending the GameObject class.
Hooboy. Okay! Thanks very much. (The project I am working on was started by someone else who DID derive Everything in the entire game off of the GameObject class, and it worked for the older Unity 2.6 structure.)
So looks like I gotta rethink this one, and make a new object ins$$anonymous$$d. Thanks much!
And again, like I said, the GameObject class was never supposed to be derived from, which is probably why they sealed it. The person you inherited your code from wasn't using good Unity practices, so rewriting it will be a good thing in the long run. Good luck.
Answer by Lucas Meijer 1 · Oct 15, 2010 at 03:19 PM
We sealed the GameObject class in Unity3, because we want to be better at directing users on how we intended our api to be used. If you can give a description of what you were trying to achieve by doing this, I could give a suggestion on how achieve that in a way that would be more "unity natural"
Probably just my ignorance, but if GameObject is the base of every object, how come I don't see it in debug when I inspect the this pointer in the watch window for any given script? Is it because it's sealed? All I see is $$anonymous$$yScript -> $$anonymous$$onobehavior -> Behavior -> Component -> Object. GameObject is a member of Component according to the watch, but it's now the base class.
Answer by yoyo · Dec 16, 2010 at 10:26 PM
I had a similar issue with the Mesh class, which is newly sealed in Unity 3. I had derived my own Mesh classes for rectangles and multi-segment lines.
My solution was to switch from MyMesh is-a Mesh to MyMesh has-a Mesh. (Understanding these two relationships is good knowledge for any object-oriented programmer to have, and often has-a may be more appropriate than is-a -- a complex inheritance hierarchy may be a sign of an inappropriate design.)
So in my case, I changed this ...
class MyMesh : Mesh
{
...
}
To this ...
class MyMesh
{
private Mesh mMesh;
...
}
It turned out that very few of my uses of MyMesh depended on the base Mesh class, indicating that my use of the base class was really just an implementation detail, not something the calling code cared about. Any such dependencies were easily handled by relaying the implementation of the base member from my class to the base class, for example ...
class MyMesh { private Mesh mMesh;
public void Clear()
{
mMesh.Clear();
}
...
}
Without knowing how your client code uses your custom GameObjects, I can't tell if this technique is easily applicable to your case, so your mileage may vary. It should be simple enough to remove the ": GameObject" from your class definitions and see how and where the client code fails to compile. Good luck!
BTW, this was the only significant bit of pain I had upgrading from Unity 2.6 to 3.1, and even with this change my upgrade was complete in about an hour ... pretty painless really! :-)
P.S. I just re-read Cinna$$anonymous$$ints comment about use of protected members -- the has-a technique falls over here, because you can't access the protected members of a member field. (At least not without resorting to reflection, which I wouldn't advise!)
Your answer
Follow this Question
Related Questions
UnityEngine.Object.Instantiate 1 Answer
using Contains(gameObject) to find and destroy a gameObject from a list 2 Answers
Get first gameobject in a list and cycle through on keypress 1 Answer
Change target after destroying it. 2 Answers
How to check a sequence of gameobjects and tell if it was correct or not? 2 Answers