We have covered most of the theory part now. You can read and write code. In this chapter, we will discuss organizing your code and object oriented programming.
In this chapter, we will cover the following topics:
- Working with objects
- Constructing the class and its syntax
- Using C# constructors with data
I'm throwing the word object around like you were born with the knowledge of what an object is. Actually, you do know what it means. The coffee cup you may have in your hand is an object, a real one. That UFO flying around at night is an object, even if you can't identify it. In Unity, you may have a flying saucer in your Scene, but it's obviously not a real flying saucer—it's a virtual one.
However, in the virtual world of gaming, most people would consider things they can see on the screen as objects.
If you can expand your mind just a little bit more, perhaps you can accept that not all objects in Unity have to be something you can see in a game Scene. In fact, the vast majority of objects in Unity are not visually in the Scene.
In a computer, an object is just a small section of your computer's memory that acts like a container. The container can have some data stored in variables and some methods to work with the data.
The best example I can show you is the object you've been using since we started this book:
In MonoDevelop, we've been working with the Script called LearningScript. In Unity, we use the general term Script, but it's actually a class, which means it's a definition of a type of container. Look at line 4 of the file:
public class LearningScript : MonoBehaviour
See that second word? It means that LearningScript is a class. In this class, we defined its member variables and methods. Any variable not declared in a method is a member variable of the class.
In Chapter 2, Introducing the Building Blocks for Unity Scripts, I told you about the magic that happens when we attach the script class to a GameObject. The Script becomes a Component.
Besides the visual mesh in the Scene, can you visualize in your mind that a GameObject is just a bunch of different types of Component objects assembled together to construct that GameObject? Each of those individual Components shown in the Inspector window will become an object in our computer's memory when we click on the Play button.
Select any GameObject in the Scene window and look at Inspector. For example, select the Main Camera GameObject. There are several Components on the Main Camera GameObject. Look at each of these defined Components. Every one of these Components started off as a class file in Unity, defining a type of container of variables and methods.
We don't see or modify those Unity class files, but they're in Unity somewhere.
- The name of the class is also known as the object type of the object that will be created in memory from that class, when the Play button is clicked.
- Just like
intor a string is a type of data, the name of a class is also a type of data. - When we declare a variable and specify the type of data it will store, it can easily just store a reference to an object of the
LearningScripttype, as shown in the following line of code:LearningScript myVariable;
- Storing a reference to an object in a variable does not mean we are storing the actual object. It means we are storing the location in memory of that object. It's just a reference that points to the object in memory so that the computer knows where to access the object's data and methods. This means we can have several variables storing a reference to the same object, but there's still only one actual object in memory.
Note
A Script is just a file on your hard drive, and there's only ever one file. The class file simply defines a type of container of variables and methods that will become a Component object in the memory when you click on Play. You can attach the Script to many GameObjects, but there's still only one file on your hard drive.
Attaching a Script to a GameObject is like placing a sticky-note on the GameObject. When we click on the Play button, Unity looks at our GameObject, sees the sticky-note which says, "This GameObject is supposed to have a Component of type LearningScript. Make some room in the computer's memory to hold this object of variables and methods, as described in the LearningScript class file."
If we were to attach LearningScript to 1,000 GameObjects and click on Play, there will be 1,000 separate sections created in your computer's memory, with each storing an object of type LearningScript. Each one has its own set of variables and methods, as described by the script file. Each one of those 1,000 sections of computer memory is a separate Component object of its respective GameObject.
Your brain is probably just about to start boiling. To make this easier to understand, let's write a quick example.
Take a look at the code. We wrote a class named Person. Notice that I removed : MonoBehaviour after the name of the class. The main reason is that we treat the class Person as a simple container of the data, a C# object of type Person, not a Unity Component. We don't need this class to be a full-spec Unity Component.
As you can see, you can easily store any type of data inside your class. We make variables public as we will need to access this data from other classes.