Just like your daily routines, you follow certain patterns that are comfortable to you. Why is that? Probably because it's easy for you and they're etched in your brain; they're habits.
Whatever it is you do; sort your laundry, build a sandwich, wash the dishes, work with Unity, you will eventually develop a routine pattern that you'll follow and like. You can equally believe that you will establish a pattern for writing scripts, too. Right now, after reading this book, you may already have some idea of how you will write and add scripts to GameObjects. Maybe you're already quite proficient at everything in Unity except for the scripting part. All you may want is to write some scripts and attach them to your GameObjects, then get back to doing the fun stuff.
How you design your scripts to control your game can be simple and neat, or if you're not careful, it could turn into a spaghetti nightmare that will make you pull out your hair. Just haphazardly writing scripts will not make you happy, especially if you need to make changes in your game flow at a later time.
As you discovered, each active State allows you to control what Unity does and what it displays.
It organized our code making it simple, neat, and easy to follow. I happen to like it. You may have decided that you don't like the idea of a State Machine after seeing the version in this book. Every programmer develops their own routine for coding. The point is, you will decide what's easiest for you and establish a pattern that's comfortable.
Besides showing you why I like State Machines, I also exposed you to writing regular C# classes. I also expanded a little into using a C# interface as well. A C# interface could be used easily with Unity Component classes as well. I just happened to need this C# feature for the State Machine classes.
Our State Machine was used to control the whole game. You could just as easily use this State Machine design pattern at the GameObject level as well.
Our game State Machine used the StateManager object. This was a Component attached to the empty GameManager in the Scenes panel. Its primary job was to know which State was active during the game.
For a visible GameObject such as an enemy, you could control its allowed actions for various conditions. You would basically name the attached Component script something like EnemyStateManager. The following graphic shows a possible enemy State Machine:
An alternate to using this type of State Machine is that you could code a GameObject State Machine using a combination of a C# enumeration and a switch statement.
That's the neat thing about programming. There are countless way to write code to get the desired result and behavior.
I personally prefer to have many very small class files that do one task rather than having one huge class file that does many things by using endless lines of if-else statements or long switch statements. You will eventually determine your preferred way of doing things.
It's one thing to study a bunch of tutorials about C# to learn the programming jargon and syntax. That's actually the easy part. The tough part for beginners is to understand how to bring it all together into a project.
I personally like using the State Machine because it doubles as an outline or mind map for a Unity project. Then it's just a matter of creating the class files corresponding to the mind map, and coding the behavior that each class will perform.
This is especially helpful for the beginner programmer. You've learned many things about C# in specific little chunks, such as variables, methods, if statements, for loops, and lists. Trying to combine all these little chunks of new knowledge to create a game can seem like a mountain has to be climbed. Separating code into many little class files makes each class easier to deal with, as opposed to having a class file that has long pages and does everything.
The only way to get good at programming is to actually write code. The usual advice to beginner programmers is to practice, practice, and practice by doing small projects. That advice is good, but let's be realistic. You probably already have a Unity project started that just needs some scripts written. Do you really feel like going off on some tangent to create some little learning projects that don't interest you? Will you really be able to concentrate on learning as you practice coding when all you can think about is your game project?
By separating your code into smaller, dedicated classes, you essentially have your little project to practice on. Plus you'll feel so much better having completed something you actually needed.