Graphics Reference
In-Depth Information
important to me to design scripts as standalone so that they may be used in more than one
situation. For example, our weapon slot manager will not care what kind of weapon is in
any of the slots. The weapon slot manager is merely an interface between the player and the
weapon, taking a call to “fire” and responding to it by telling the weapon in the currently
selected weapon slot to fire. What happens on the player end will not affect the slot man-
ager just as anything that happens with the weapon itself will not affect the slot manager.
It just doesn't care as long as your code talks to it in the proper way and as long as your
weapons receive commands in the proper way. It doesn't even matter what type of object
the slot manager is attached to. If you decide to attach the weapon slot manager to a car, a
boat, a telegraph pole, etc., it doesn't really matter just as long as when you want them to
fire, you use the correct function in the slot manager to get it to tell a weapon to fire.
Since our core game logic is controlled by manager and controller scripts, we need to
be a little smart about how we piece everything together. Some manager scripts may ben-
efit from being static and available globally (for all other scripts to access), whereas others
may be better attached to other scripts. We deal with these on a case-by-case basis. To get
things started, we will be looking at some of the ways that these manager scripts can com-
municate with each other.
As a final note for the topic in this section, you may be wondering what the differ-
ence is between managers and controllers. There really isn't all that much, and I have only
chosen to differentiate for my own sanity. I see controllers as scripts that are larger global
systems, such as game state control, and managers as smaller scripts applied to gameOb-
jects, such as weapon slot management or physics control. The terms are applied loosely, so
don't worry if there appear to be inconsistencies in the application of the term in one case
versus another. I'll try my best to keep things logical, but that doesn't mean it'll always
make sense to everyone else!
1.1.2 Script Communication
An important part of our manager- and component-based structures is how our scripts
are going to communicate with each other. It is inevitable that we will need to access our
scripts from a multitude of other areas of the game, which means we should try to provide
interfaces that make the most sense. There are several different ways of communicating
between scripts and objects in Unity:
1. Direct referencing manager scripts via variables set in the editor by the Inspector
window.
The easiest way to have your scripts talk to each other is to have direct references
to them in the form of public variables within a class. They are populated in the
Unity editor with a direct link to another script.
Here is an example of direct referencing:
public void aScript otherScript;
In the editor window, the Inspector shows the otherScript field. We drag and drop
an object containing the script component that we want to talk to. Within the
class, function calls are made directly on the variable, such as
otherScript.DoSomething();
