How much should scripts be broken up?

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)

 

You make some good points.

 

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

 

Sounds like a good idea.

 

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:

Code (csharp):

1.  
2. if(GetComponent<Player>()) player.DoDamage(dmg);
3. else if (GetComponent<Monster>()) monster.Damage(dmg);  
4. else if (GetComponent<Barrel>()) barrel.DamageTheBarrel(dmg);
5. else if (GetComponent<OtherPlayer>()) otherPlayer.Damage(dmg);
6. else if .....
7.  

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.

 

Ok

 

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

 

I'm thinking they got their ideas from all these crazy tutorials..

 

I've written entire projects with 1 script file.

[Edit] In C# it's best practice to separate classes into their own files.

 

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.

 

Ok.

 

I can also create my project with one script and minimize it as JQuery does. It works. That does mean it is a good way to code.

There are some code conventions, you should read them. Because if one day you need to work with one or more other developers, you just will be F***ed

 

Ok

 

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.

 

lol...

 

Yes lol indeed, Unity coders would divide up their code and make a script for each variable if they could.

 

I think you never work in a Software company, specialy in a video game company

 

I didn't say I did, but I have actually working with mainframe developers. Not that I would have to work in a software company to see professional code. Encapsulation is one thing but creating classes for every aspect of a class is overkill.

 

I can't comment much on the 'real world' applications, most of my serious coding experiance has been inside the Unity environment.

But inside unity I inevitably end up breaking long classes into smaller ones for ease of use. I've been burnt so many times by maintaining long scripts that I now build everything small. It occasionally happens I have to combine, but not nearly as often as I had to break longer scripts.

The one exception to this rule is sequential manager scripts. A happens, the B happens, then C and so forth. These can get very long without causing undue maintenance issues.

 

It's up to you to create a class when it is needed. But, depending on the feature, you should sometimes create another class to handle it.

You were talking about the player's inventory ; so you're gonna create a class "Player" and handle the inventory with it ? Why ? A monster can't have an inventory ? A chest can't have an inventory ? Why the player should handle the drag'n'drop of the items ? Besides, the Player will also handle the items ?

I think you don't really understand what means "OOP" ; every object / container should have his own class.

 

Ah, well your last few sentences in your first post would imply that you are talking about real world applications, which was the whole point of the reply, but okay. Thanks for your input

 

The items in my code are mainly handled by the itemScript, the only thing player and enemy has to do with inventory is their List of itemScripts. There's no further encapsulation needed.

Ah, I see the disagreement comes from what you seem to think OOP means - it does not mean every thing that could have a class/container should have a class/container. Otherwise we'd have classes and structs of literally every property in the game.

If there is no purpose or organizational benefit to encapsulating something, then it creates more mess.

 

Yeah, slightly out if line there, my apologies. My assumption was based on most if what I have read on OOP, not any actual industry experience outside of Unity.

 

I agree that encapsulation is a good thing and makes for cleaner code, but taking it too far I say would do the opposite.

 

I'm still struggling to get my head around 90% or objects only have 1 or 2 scripts. I think my last game would be a nightmare under these guidelines.

It was based on a water-air surface, so every object had a script to handle air water physics. That's one script for every object already. I suppose I could have combined all of the scripts on each player into a single class, same with the projectiles.

I then end up with a stack of variables that I have to constantly refer to with different names. I get UI code mixed through game logic. I get a spaghetti of ifs through Update as I check for various inputs. Doable, but readable or maintainable?

With multiple small classes I can avoid all of this. Unity is all about component based design.

 

Only rabbits with pancakes on their heads make arguments invalid. C# being OOP absolutely doesn't mean you shouldn't break up large classes.

Experience is the only way to really learn the benefits of modular architecture. I think you will find that if you start working on a large project with a lot of code, especially with other developers, that cramming everything into one huge class and copy-pasting large parts of that into another huge class is going to become a nightmare to deal with eventually. But, most people need to actually experience the nightmare themselves before they believe it. Then you'll probably be trying to convince some other random coder on the internet to break up their monolithic classes and they'll be telling you that they don't see the point.

 

Any time your project gets any sort of size to it, you are going to be struggling trying to cram so much into one class.

My spells have on average 5-7 scripts attached. A central manager that handles activation and deactivation and holds key properties, a type of motion class (projectile, attach to an object), a type of target detection class(Hit everyone in the area? Only affect the target? Raycast? Collision based?), one or more "effect classes" (This ability damages enemies and slows them. This ability Knocks an enemy back and lowers their defense), and optional spawner class that can create more abilities (After hitting and damaging its target, the fireball spawns an explosion that further damages all foes in an area. Or, this storm spell constantly spawns pulses that damage foes every 2 seconds.)

I have approximately 200 spells. I do NOT want to craft 200 large, cumbersome scripts that detail what each and every spell does. Create an ice bolt spell? Projectile, Detect First Target Hit, Damage Foe, Slow Foe. Boom. I'm done. Next up? Earthstomp. Attach to user, Detect All targets hit, Damage foe, KnockDown foe. Done.

Oh, and what if one day I want to decide that I want to change how projectiles work? My projectiles should now seek out targets, whereas before they only went straight. I've have 40 different spells that are considered 'projectiles'. Now i have to dive into every one and one of them (hope I remember which ones count as projectiles!) and adjust the code.

Or I could adjust my projectileMovement class and move on to something else.

I'm sorry, but I can't even imagine making my whole player run off of one class. Ew.

 

My bad, I misread your post ! Thought you were saying the exact opposite (I just saw your code )

 

Ouch. I struggle to manage scripts above 200 lines. Even that is pushing the limit. If it works for you I can't really fault it. I'm just surprised it works.

How would you handle the situation described by @Zaladur? Seems a monolith would require a maze of conditionals to achieve the same level of flexibility.

 

General advice is one script file should be no bigger than 100-200 lines max.

 

If what you are doing seems to be working, I won't try to get you to change. Breaking things apart is more flexible, but you don't always need that level of flexibility. I just want to make clear that the guy doing this :

Is far from nooby and wasteful, and I don't want new people coming in and seeing that and thinking its bad practice to split up their code into multiple classes that each focus on entirely separate aspects (such as health and movement). Because while you may not always need to do it, it is almost always a good idea.

 

Okay

 

Exactly. So telling people its "nooby and wasteful" is a bit counter-productive, right?

It sounds very much to me like you're not used to design changing while implementation is still in progress. In professional work I got a huge productivity boost by designing for flexibility rather than taking the apparently simpler approach of just directly implementing specifically what I'm asked for.

You keep saying "PlayerHealth" and such. Why does it come with a "Player..." prefix? In my last game with the concept of "health" I had one "Health" component that was used on anything that could take damage or die. I didn't split up my player and split up each of my enemies and have a PlayerHealth and an Enemy1Health and an Enemy2Health. That's the worst of both worlds - more components and no reuse. I just have one component, Health, and stick that same thing with different properties on my player and all of my enemies. Later on if I want to make something else damageable I just add that component, job done. If I decide something shouldn't be damageable any more I just remove it, nothing else cares.

Going back to the concept of designing for flexibility, this means that when a client (or designer) comes and wants something changed I don't have to modify any code (or, as may be the case, modify code in multiple places). I can just add, remove, or tweak properties on components. So when the design changes - and it always changes - it takes me a few seconds and doesn't impact other code, rather than the old way which could take between minutes and hours and often effected other code. Better yet, in the case of designers, they could change it themselves and I wouldn't need to be involved at all. That's a huge win for both of us.

I suggest doing a search on "composition vs. inheritance".

Agreed.

 

Ok

 

Unfortunately that's a big "if".

 

My understanding is that a lot of the drive to modularity comes from the need to maintain and modify code, ie to manage change. I'm guessing it's less important when the product is not going to be modified later.

 

I think you're on the right track. Split up your code, this will make your life easier.

 

Thank you all for your input - I have tried making a small sample project since I first posted this, by breaking up a monster script into component such as ai,health, and movement and I see some benefit - just that it is much easier to organize variables and functions. I have a main 'manager class' for the enemy which loads references to the other components at Start() and if needed, calls their functions.

I am not using an update in each individual script - rather the manager class has one update which calls custom 'update' functions from the component classes if needed

Creature Script Class sample

Code (CSharp):

1.     void Start ()
2.     {
3.         cmp_ai            = GetComponent<aiClass>();
4.         cmp_anim          = GetComponent<animClass>();
5.         cmp_health        = GetComponent<healthClass>();
6.         cmp_movement      = GetComponent<movementClass>();
7.         cmp_reward        = GetComponent<rewardDropClass>();
8.     }
9.  
10.     void Update ()
11.     {
12.         //Check if Creature is running death coroutine already
13.        if( !f_updateCreature )
14.               return;
15.  
16.        //Check if Creature is dead
17.        if( !(cmp_health.isAlive()) )
18.        {
19.              f_updateCreature = false; //Only run death coroutine once
20.              StartCoroutine( coDeath() );
21.              return;
22.         }
23.  
24.         //Update any components
25.         cmp_ai.ai_update(); //Call update from ai component
26.  
27.     }
28.  
29.    IEnumerator coDeath()
30.    {
31.         cmp_reward.grantReward( );  //drops items and gives exp to the last attacker
32.         cmp_anim.playAnim( "death" );
33.         yield return new WaitForSeconds ( cmp_health.decayTime );
34.         Destroy( gameObject );
35.    }
36.    

The AI class refers to the movement class and ai_update is having the enemy wander around a certain radius depending on certain ai modes/flags.

This project is small but gave me some insight on what I should/shouldn't encapsulate and this was major halting point in my main project because I couldn't decide on this idea and I didn't want to get too far into my project without deciding how I would organize scripts/classes

 

Just to give my little piece of advice here, I never worked in a professional environment. I've been going to school part time for general software engineering and I always had a hard time splitting up my code. It's been getting better with time and practice but for my current project (which has been going on for 18 months now) I can see the difference between when I first started, and code I'm making now.

The main class I have is my CitizenAI which handles literally everything. Inside that class I also keep references to Non-Mono classes such as Opinion, Attributes, Health. My Update() method is about 2500 lines, the entire class is about 3300 lines. The AI was the very first class I started to write when I still had no clue what I was doing. It's a big switch(state) with all the different tasks someone can do.

I just kept adding to that class thinking "yeah it's still manageable, I got this" but now I realize I will need to refactor the hell out of it. I'm thinking about breaking every possible state into it's own class which derives from an abstract State base class.

My advice is if you think it will grow, split up your code because it might still be very managable, but it could very well come back and bite you.

 

It's good to have one class per file.

 

As far as the tutorial videos go, that's the perfect place to cut things into smaller pieces. You don't want the newbie dev scrolling up and down a long page of code trying to find the spot you're talking about and getting lost.

When you're teaching X, you want them focused on X, not Y up above and Z down below.

 

I couldn't disagree more strongly, for reasons already given. You're right that the algorithm is important, but waving away architecture/design as having "little relevance" is a fast path to unproductive approaches. Writing code that works is the first step. Being able to make effective algorithms is the next. After that is learning to design at a bigger picture level to improve the maintainability, flexibility and robustness of your software.

 

This thread asks a specific question that doesn't exactly have a specific answer. It depends on project size, intended use and functionality, intended portability/reusability of the code, and a hundred other variables.

In the end, though, it's safer to favor modularity and flexibility than it is to favor cohesion. Modular code leads to code that is more self-documenting, easier to track bugs, more portable, and safer. Not to mention that if you decide you need modularity and flexibility later, breaking a 2000 line file into its constituent parts will involve probably rewriting much of the code.

On the flip side, I can't see a single argument in favor of having highly cohesive code. There may be a slight decrease in overhead, or there could be an increase, due to duplicated code and general failure to use an object oriented language as what it is.

I couldn't disagree more. The switch from 3 scripts to 10 could involve days of refactoring and fixing new bugs. Or a complete redesign, if foresight has been so limited that you need to do this. Or weeks, if we're talking about 3 scripts that are 2000 lines long and resemble spaghetti near the end of the project.

The longer class files I have top out under 300 lines. Each one that is applicable to other games in the future doesn't need modification to be reused, and dependencies are minimal. I've tried to anticipate for future needs for flexibility wherever possible.

These aren't personal standards, they're industry standards. This debate is silly.