I try to make my code as reusable, readable, and as simple as possible, but I cannot understand some of the trends I see in Unity tutorials with breaking up scripts into very small functions.
Player movement, cam rotation, inventory, health, all in their own individual classes, why?
Most of these things can be handled with one function, why are so many tutorials making a whole script component for each? I understand the intent fully, but it seems that doing something like this will lead to a huge and unnecessary amount of scripts.
My game is currently organized with classes such as :enemyScript, itemScript, mainScript(player), fx(static fx spawn class), sound(static sound class). guidraw (static GUI class)
I do not see any reason to further break these scripts down, and to me doing so would break the organization I am aiming for. I see tutorials breaking up the player class into health, weapon, camera, movement, animations scripts and have 5+ scripts just for the player, and like I said before most of these scripts can be handled with a function and 1 or 2 variables in the âmainâ class it stems from, why make mess by adding a whole nother script for something like 4-5 lines of code (more in some situations, but still doesnât change the fact a lot of these can be broken down into ONE function, and donât need a whole entire nother script running for it)
Thank you⌠I just tried to give some advice against a ânoobâ doing this, and 2 âprosâ came in and argued against me and told me what I basically just told you was horrible coding design, and that he should make a script for every function in the game o.o
Not their words, but I asked them why they would create a script for each function which is essentially what they were saying, and all they said was reusability, anything that uses the function can just use the script. Which I understand some components are reusable if you make them extremely simple⌠but how far do you take that I mean, I really donât want to manage between multiple scripts for one single object. The time you save in reusability by making a health/animation/ etc component script for each class, you might lose in the organization of having so many scripts for each actual âobjectâ and if the scripts need to interact with each other.
A lot of it depends on how big your project is going to get. If you only have a player class and a monster class and thereâs not much code then it might be fine to just put everything in those two classes. But if you have a huge project, and you decide to give every class its own version of health rather than breaking it out into its own class, then you can end up writing weapon code like this:
if(GetComponent<Player>()) player.DoDamage(dmg);
else if (GetComponent<Monster>()) monster.Damage(dmg);
else if (GetComponent<Barrel>()) barrel.DamageTheBarrel(dmg);
else if (GetComponent<OtherPlayer>()) otherPlayer.Damage(dmg);
else if .....
and so on. In this case youâll see that separating it out into a Health class that all of them share will result in a lot less code and fewer chances for errors.
I do that now except player and enemy classes have an âaddDamageâ function, which in my opinion is simpler than creating a whole nother script to manage (even if its just health related), in the example you gave all i would have to do is check script type and call its addDamage function, in the same way you checked component.
Your explanation gave me some insight, I think the big thing confusing me was the fact that I saw tutorials breaking up EVERY possible component into a script, movement, camera, inventory, etc. and to me that is taking OOP too far and not what it was intended for.
I see your point for reusability, but I feel like the reusability would only be in some small cases, like the player and enemy which might have very similar characteristics, animation functions, health functions, etc so they share a component script for each, I can see that working, but to me those are the only small cases that it is a good idea to break up scripts when you have 2 very similar classes (in certain respects such as health/anim) such as player and enemy
Well, like I said, if you just have two classes like player and enemy, then it might be fine. If you get to a point where you have twenty classes though, youâll start to see that breaking it out into code they can share is better than rewriting the addDamage function twenty times.
But logically I can never see this happening with âgoodâ code. I would never create 20 different types of things that can take damage (except maybe in a very unique game), at most I would have enemies, player, item, and some sort of âdestructableSceneObjectâ class for nearly everything else,.
I see your point entirely, Iâm just trying to find which cases I should break up the script and which ones would just be extra work and extra scripts if I broke it up.
Right now my game is at about 10 scripts, most of them share nothing in common script-wise, so there is little reason for me to break them up into even more script components.
Yeah, a simple ball game that was created to teach beginners comes to mind⌠the first thing the tutorial does script-wise is have the person create 4 scripts that does stuff for the player⌠one movement, one camera, one shooting, and 1 other⌠so itâs like theyâre teaching this stuff from the beginning. And Iâve watched a LOT of Unity tutorials, this habit is EVERYWHERE. I am not new to programming or game programming, just relatively new to Unity, and this habit of breaking up scripts as much as possible just astounded me.
Sorry but your argument is invalid. C# is a OOP programming language (as UnityScript) and so you have access to abstract classes.
Basically, if you create a script with only one function that means you want to add it easily to several game objects. Nothing more. Itâs NOT a bad idea. Itâs up to you.
If you want to ignore an UI element from events, you could create a script called âUIIgnoreRaycastâ and add it whenever you want to any UI element you want.
Maybe you know the Shuriken Magic Effect Pack, which is a good effect pack in my opinion. If you look at it, you could see some scripts which have only one function: randomize scale, position or rotation. You also have some script that Lerp the position / rotation over the time, etc. This is a good way to do that rather than create a script for each effect in order to randomize their scale or / and their position or / and their rotation.
Anyway, in my opinion, creating a Health script is not really efficient but why not. Also, it is also a good way to break down some script to avoid scripts of 5 billions lines
Yeah but I like to organize my scripts with formatted comments/coding standards, variable/function organization, not with tons of scripts
Plus for someone using a good IDE the code size doesnât really matter as much, I think Iâll stick to my original notion, that each âobjectâ in the game should usually only have one script, except maybe in very rare cases. In my opinion, the farther you stray from that idea, the harder the code will be to understand or organize in the future.
I honestly donât see any reason to break up huge class files as long as you are organizing your variables and functions in some way. Of course if any code is messy its gonna be hell to read the longer it gets - I donât see that as a good reason to break up a group of code that all belongs together anyways - except the very specific cases I mentioned where classes share properties⌠but i feel that is the exception far more than the norm.
Wow, there is some really bad advice here. You should almost always break your code into multiple classes. Its incredibly rare for me to have a significant GameObject without four or five scripts attached.
The principle of single responsibility is kind of fundamental to OOP, and has major advantages in simplicity, reusability and modularity. Let me talk through some of these.
Simplicity
When I am writing about health I only want to be writing about health. The script contains a couple of floats, a method for damage, a method for healing, and a method for dying. Everything is directly related to the job the script has, which is keeping track of health. The same is true for my script on movement, everything in that file is directly related to movement. There is no need to scroll past irrelevant code to find the bits I am looking for.
Reusability
Shorter, more focused scripts are easier to reuse. I can have a health script on every single object I want to take damage. I can have a rotate script on something I want to rotate. There is no need for a rotate-health script. This becomes even more obvious when you start working with multiple scripts. You need 32 âlong single scriptsâ to produce all of the combinations that can be made from just four short scripts
Modulatory
By using multiple scripts you can switch out part of the functionality completely without affecting the rest of the set up. A common set up uses three scripts for movement. The first script is responsible for path finding, basically identifying where to go. The second script is responsible for steering, figuring out how to get there. The third script is responsible for the engine, this script actually moves the GameObject. By changing the engine you can quite simply switch from a boat to a car, with no effect on the steering or path finding. You can change a cars behaviour from passive to aggressive by switching out the steering. No need to modify the engine. You get the picture.
Multiple small classes is not just a Unity trend. This is an industry standard across OOP languages. Youâll get plenty of good answers on this from a Google search.
It is possible to go too far with this, but most beginners donât go near far enough.
I agree with all your points, but I still disagree that most GameObjects would need more than 1 script, I feel 90% of possible GameObjects should have 1 or 2 scripts and no more. I disagree that this is how people encorporate encapsulation in the real world - the classes and their functions are enough, no need to break down every single type of variable or function group into a module- the encapsulation youâre talking about can be broken down using functions, it doesnât need a whole nother script just for each of those âmodularâ properties. Iâve seen lots of professional code and Iâve never seen classes broken up to such a ridiculous extent as some of the ways people do it in Unity. OOP is taking it too far when you break up whole objects into tons of little modules, it may be reusable but itâs a huge mess and is more reusable than applicable to your individual game. In my opinion this is doing the opposite of making the code more simple.
Iâd rather have a playerScript that is clean, easy to read, in 1 or 2 scripts, than a huge messy set of âmodulesâ that I probably will only use for 1 or 2 other classes at the most.
Obviously, OOP and encapsulation are very useful, and make things easier to read, but to an extent. It is not necessary in most situations to have individual modules of every âgroupâ of properties for the player, there should be as much classes as there need to be to define the objects that exist, but no more.
