Graphics Reference
In-Depth Information
Let's take a look at what this script actually does: In this case, if we were to call the
Engine() function on OctoCar, it would do the same as the BaseCar class; that is, it would
write “Vroom” to the console. It would do this because we have inherited the function but
have not overridden it, which means we keep that default behavior. In OctoCar, however,
we have overridden the Wheels() function. The BaseCar behavior of Wheels would print
“Four wheels” to the console, but if we call Wheels() on OctoCar, the overridden behavior
will write “Eight wheels” instead.
Inheritance plays a huge part in how our core game framework is structured. The idea
is that we have basic object types and specific elaborated versions of these objects inherit-
ing the base methods, properties, and functions. By building our games in this manner,
the communication between the different game components (such as game control scripts,
weapon scripts, projectile controllers, etc.) becomes universal without having to write out
the same function declarations over and over again for different variations of the script.
For the core framework, our main goal is to make it as flexible and extensible as possible,
and this would be much more difficult if we were unable to use inheritance.
The subject doesn't stop here, but that is as far as we will be going here. Each method
will be useful in different areas of game development. For example, in cases where a com-
ponent requires a reference to another object such as a material or a texture, it makes
sense to set this via the Unity editor. In cases where we are developing classes that are
not applied to gameObjects, we may use a static variable to make it accessible to all other
scripts. For the sake of sanity, it is probably likely that we will never use a static object
reference without using it as a singleton.
1.1.5 Where to Now?
Think about how your objects work together in the game world and how their scripts need
to communicate with each other. I find that it helps to make flow diagrams or to use mind-
mapping software to work things out beforehand. A little planning early on can reduce a
whole lot of code revisions later on, so try to plan ahead. That said, it is perfectly okay for
your structure to grow and evolve as you develop it further. The framework shown in this
topic ended up going through many revisions along the way before reaching its inal form.
Try to break up your scripts into smaller components to help with debugging and
for flexibility. Also, try to design for reusability; hard-coding references to other scripts
reduces the portability of the script and increases the amount of work you will need to do
in the future when you want to carry it over into another project.
