When you initially started with this book, all the little details about programming looked like a treacherous mountain to climb. Every step up the mountain was perceived as the one that would just be too difficult to take. Learning to write C# code looked nearly impossible to learn. Not because each step is difficult, but because it looked like a mountain of information to overcome. Then the journey began and a funny thing happened along the way. Each step became just another step. Before long, the top was reached and the goal was accomplished. All that initial fear and worry was nothing more than overzealous imagination.
Now that the top is reached, we'll turn around and look at the new skills you just learned, and mention some things that weren't learned during your hike up this mountain.
In this chapter we will cover the following topics:
- Review the goal of this book
- Look at the C# you learned, and didn't learn
- Look at the State Machine as a design choice
- Talk about furthering your education
Let's see where to go from here.
Unity projects are usually about the game being created, and not the code used to control the game. The State Machine was the project for this book; not the actual game. The simple game was just a collection of examples to demonstrate coding to access some of Unity's features.
The point of this book is to teach the basics of programming using C#. The State Machine allowed me to teach you about C# classes that were not Unity scripts. As you learned, not all classes have to be a script attached to a GameObject. If a class doesn't use any of Unity's magic methods, such as Update() and Start(), and none of the variables need to appear in the Inspector panel, then you could just create a regular C# class instead of a Component script.
None of the State classes are Components so they don't have to inherit from MonoBehaviour, yet they allow fine control of the game while organizing the code. Instead of having many large scripts with many if-else statements to determine game flow, a few compact States were used when needed.
We saw that in Unity, everything is an object that contains data in variables, and methods to work with the data. For instance, the Player object knew its color, how fast it could move, and that it could shoot projectiles. The projectile object knew how long it would exist, how fast it travelled, and what to do when it encountered another object. The objects know what to do because their behaviors were defined in a class file.
This interaction between objects is possible because they could talk to each other by using dot syntax communication. The class defines what an object should or shouldn't do when encountering with another object. The Player object knew it should try to hover over other GameObjects. However, if it instead collided with certain GameObjects, Player and the other GameObjects communicated with each other to cause specific actions to take place, such as changing the score.
Even though classes are nice from a coding point of view, the basic thing to understand is that a class simply consists of the two main building blocks of programming, variables and methods.
No matter what feature C# may have that makes writing code easier, everything revolves around variables to store data, and methods to act on the data. That's why the first goal of this book was to help you understand these building blocks.