The tutorials learned me a lot of stuff about classes and how they work. But they didn’t tell much about how classes should be used in practice.
Before watching the tutorials I used to split parts of code into several smaller script that could later be reused on another object. As an example, I once created a very simple AI for an enemy in a shooter game. I made three different scripts for this - one script for the sensing (line of sight, hearing etc.), one script containing all the functions and then finally a script that basically told the AI what to do using some the functions from the two other scripts.
But was this the right way of doing it? Should I have used classes instead? When is it necessary to use classes instead of components?
I am using Javascript, and I know that this might be a very subjective question; I’m just trying to figure out how important classes actually are in Unity.
As you pointed out, a lot of it comes down to preference and scripting style. If it works, then by definition it is not wrong.
As such, I can only give you my personal approach, and what I’ve managed to learn from a year’s worth of practice and refactoring.
My current approach is to use custom classes for specific data types that don’t exist in Unity, and to use Components for actual functionality. You shouldn’t be afraid of throwing a crap-load of smaller components at a game object. Unity is built around the component architecture. It can handle an abundance of different scripts on an object. At the same time, you shouldn’t be afraid of cooking up new classes.
If I need a new type of object to store specific data, I create a custom class. If I need something to actually act in the scene, I create a component. My classes store the data, my components act on the data. Most of my functions are in the components, while my classes usually contain variables and property definitions. (and occasionally logic to alter and access them)
The way Unity is set up, classes aren’t very important. Your classes can only be a script component of the game object. In other engines you can actually extend the game object, but Unity doesn’t allow that because it’s component based. Classes are somewhat valuable in that you can extend them. So say you have a class for your AI, but you need something a little different for the AI in another enemy. You can extend the class, rather than rewriting it from scratch, or adding a workaround script.
Specifically, components are classes that extend the Monobehavior class. That’s why I specified “custom” classes, implying a class that was written without extending Monobehavior.
And it is entirely possible to use such custom classes alongside Monobehavior classes. I just try not to base my game around them. It’s usually a better idea to work with Unity’s built-in systems, rather than against them.
So is the game object, but not an extensible class. We can extend our own script components, which is what I was saying. If you used other engines that allow game object or entity extension, you would know the complete difference. Classes are useful, but a lot more subordinate in Unity. Behaviors are a good word for the scripting component. That’s what we can extend, and it’s still pretty useful.
My point was that everything is a class - the statements you were making muddied that a bit by implying there was some distinction between what Unity’s classes do and what your own classes do, which is generally not the case. Inheriting from MonoBehaviour gives you hooks into the engine and editor but the differences generally stop there. To a case OP brought up - there is generally no reason to implement AI agent behavior as a subset of MonoBehaviour. It would probably be better to implement some AgentBehaviour class that owns a state machine that controls the agent (the state machine and it’s corresponding states not inheriting from MonoBehaviour.)
Also - pre 2.0 you could extend GameObject. UT explicitly sealed it after that to reinforce their component design pattern.
So if I understand correctly, classes are basically the same as scripts. A class is therefore most useful if I have to create 50 instances of an object; else I can just use scripts?
If I for example were to create 20 different items, I would first create an item class with the necessary functions. Then I would instantiate 20 different objects of that class instead of creating 20 different scripts. Have I gotten the idea right?
Instantiating a script 20 times is the same as instantiating a class 20 times. They are in fact the same thing. (Someone correct me if I’m wrong in the case of JS/Boo, but as far as I’m aware it’s still implicitly a class.)
That was what I meant. It would not be beneficial to instantiate 20 scripts and have to modify them all in the inspector - so you do it by script instead. My post above was probably not very well written. I was in a hurry.
