koobas.hobune.stream
References to script objects outside of the gameobject in a class that does not inherit from monobehaviour
I have a number of gameobjects that get created dynamically (via Instantiate) that have a main controlling script on them. After they are created I need to access the transform and the main controlling script frequently from another script on the parent object. In order to avoid using GetComponent all the time I have created a wrapping class for the Instantiated gameObjects. The wrapping class does not inherit from Monobehaviour. It takes in an instance of the GameObject created via Instantiate and saves Public references to the transform and main controlling scripts. This way I can instantiate each object, wrap it in the wrapper class and then pop it into a Javascript Array. I can then iterate through the array and access the transform and script via WrapperClass.trans and WrapperClass.script. The reason for the wrapper class was to allow direct references to the transform and controlling script of the object without using GetComponent.
Now I thought that that would be a fast solution. However I am now having my doubts as it seems that there is some overhead I am not aware of in doing what I am doing. Can anyone shed some light on this?
I guess the simple answer I am looking for is whether what I am doing is a bad idea or not. Should my wrapping class inherit from MonoBehaviour? Am I meddling with non-managed code if I don't inherit from monobehaviour? Or is it slow because the type is being determined at runtime when I access it from the array? Hmmmm should I use C# with generics?
C# with generics would definetly be a faster solution. In general anything that is typed will run faster. (Also true for javascript) Normally I keep references to all the transforms and Components that I need frequently in the script that uses them. Just make a Transform[] or List and initialize it in Start() using GetComponent<>().
thanks these comments are helpful. For all objects that I know will be around I keep references to things I want to access. In this case these objects are spawned dynamically at runtime in possibly unknown numbers. I don't want arrays with null references in them to account for the max number of possible objects that will be created.
Even if you do have to get the variables out of the array, as long as you're just doing a simple cast it should still be a heck of a lot faster than accessing the components on the gameobject, so yes, your encapsulation idea is a good one
You don't want to make this class a monobehaviour - it doesn't really make much sense, as you won't be able to create instances of it without using AddComponent on a gameobject
You're not going to see a huge improvement with generics (basically it'll just save you the cast when accessing it), as long as you're grabbing things properly from the array (which won't type it at runtime):
var whatever : YourClass = yourArray[0];
Will be a lot faster than the same thing without the type (which will type it at runtime):
var whatever = yourArray[0];
That's not to say you shouldn't go that route though - generics make the code a lot easier to read, and give you type safety (So you can't push a Halibut instance into a Hippo list for example)
