Unity 3 sealed class GameObject ?

Questions & Answers
1

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...

2

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.

3

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"

4

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!