If you’re a traditional developer, Unity is more than a bit odd. The constructs, for the most part, make sense, but they require that you contort your thinking a bit. In this post, I’m going to walk through object hierarchy, scripting, and reuse.
Everything in Unity is built up from the concept of a game object. A game object is a connection for components. Every game object will have either a Transform or a Rect Transform component associated with it. 3D objects have a Transform – which is a 3D transformation containing the location, rotation, and scale, along X, Y, and Z dimensions. 2D objects have Rect Transform components, which are designed to work with 2D objects even if they exist in a 3D space. Game objects with a Transform don’t fundamentally have a size. Their size is driven by the other components that are attached to the game object.
Game objects can be organized in a hierarchy. This is useful when you want the objects to operate as a unit, as we’ll see as we build out the rotator script and demonstrate its use to create a cluster of directional lights. However, for performance reasons, deep nesting of game objects is discouraged. Largely, this is because some operations are recursive, and a large number of recursive operations can drop the frame rate of the solution unacceptably low. (Below about 60 frames per second.)
Frame of Reference
In the post Creating A Spinning Cube with Unity and MRTK, I created a single object – called Nexus – which had child objects of lights. To Nexus, we attached a rotation script and rotated Nexus. This caused all the lights associated with Nexus to rotate and move. We were able to set the context of the lights local to Nexus, and whatever Nexus did, the light objects would do as well.
This illustrates why we need to be careful with object hierarchy inside of Unity. When we do one operation, we’re impacting seven objects inside the hierarchy. The greater the depth of the hierarchy and the more objects, the more things need to be manipulated – or at least checked – for a single operation.
Scripts and Game Objects
In Unity, scripts are C# code that is associated with a game object. Placing a script in the project does nothing until it’s connected to an instance of a game object. Game objects themselves can be almost anything – including nothing but a container with a Transform component, like the Nexus game object. When we added the script as a component of the game object, we connected the script and told Unity to instantiate the class and connect it to the game object that we added it to.
Including public properties in the script allowed us to set those properties in the editor and ultimately have one script act on multiple objects in different ways. Unity automatically tooled our Camel case names and added spaces before the capital letters to make it more readable. It also provided an editor for the complex Vector3 object. This makes it easy to create scripts that are reusable across objects and for different purposes.