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:
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.
int
or a string is a type of data, the name of a class is also a type of data.LearningScript
type, as shown in the following line of code:LearningScript myVariable;
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.