Have you ever noticed that as your Unity project progresses, your scrips get larger and larger? Perhaps your Player and UI script files are massive. Of course, your game is centered around the player and thus it should do a lot of things. The same goes for the UI as it needs to know a lot about the game in order to display the correct information. Yet, you are struggling to find particular sections of the code and it becomes harder to add new features… If you recognize this, it’s time to refactor your scripts. Let’s try to improve your code in Unity by using small scripts.
How Did My Scripts Become So Large?
Well the answer to this question seems quite obvious doesn’t it? Over time, you added more and more things to the game, so naturally the script files got larger. Yet, this is only half the story. There is something deeper going on that beginners often miss out on.
Imagine you’re developing a shooter and you start working on the player first. Initially, the player can only move, next it can also shoot… Also, if the player can shoot, it should keep track of its weapon ammo… and perhaps the player has multiple weapons that fire at different rates… etc. Clearly, you can see the number of things the player can do keeps increasing. So adding it to the Player script seems like a reasonable thing to do right? Yet, just because the Player can shoot and move in the game, does not mean that the Player Script should do it all.
In an ideal world, a class (Like Player) should only have one responsibility. In Object Oriented Programming, this is referred to as the Single Object Responsibility Principle. When developing with Unity, we are always working with classes inside script files. To improve our code, we need to make sure that our classes only have one responsibility, or at least try to limit their responsibilities as much as possible. To improve our code in Unity, we can try using smaller scripts.
Why Are Large Scripts Bad?
In the world of Software Development, large classes are known as an Anti Pattern and are comically classified under the name The Blob or The God Class. So why are they bad? Well, of course it has to do something with the readability of your code. Digging through a large script file isn’t exactly fun and can be really confusing and time consuming.
However, what makes large classes really evil is the fact that they undermine the ability to hide implementation details. Referring back to the example given earlier, does the Player Script really need to know how movement and shooting is implemented? This is known as Abstraction and is considered a cornerstone of Object Oriented Programming. So how does abstraction help us in creating smaller classes?
How Does Abstraction Help Us Make Smaller Classes?
Remember how earlier on we mentioned that just because a Player can do things, it does not mean the Player Script is responsible for it all? When we examine the example given earlier, we can determine what responsibilities the Player Script currently has:
- Moving the Player
- Selecting different weapons
- Shoot weapons with different firing rates
Clearly, we can see that there are responsibilities here that shouldn’t really fall under the Player. The most obvious one is the fact that the Player does not need to know how the weapons works. The Player only cares about whether or not it can shoot. Yet, it makes sense for the player to know what the currently selected weapon is.
Now that we know that the the actual shooting of the weapons is not really part of the Player Script, we should create a Script specifically for the Weapon. Because of abstraction, we are able to hide implementation details which result into smaller classes. In our case, because of abstraction, we are able to hide the details of how the weapon works away from the Player Script. This results into a much smaller Player Script that is much easier to work with.
As an analogy, you can think of hiding implementation details as creating a black box. You only need to think about how to work with the box, rather than learning how the box works.
How Do I Know My Class is Small Enough?
Since you now understand that it’s important to keep an eye on the size of your classes, you might wonder when to know if your class is small enough. Unfortunately, there is no real valid answer to this but there are a couple of guidelines you can stick to:
- Try to ensure that your class only has one responsibility, or try to limit it to as few as possible.
- Try to keep your classes under 500 lines of code. Any longer and you should consider splitting it up.
- Try to keep your functions under 100 lines of code. Any longer and you should consider splitting it up.
- Try to make sure your class has at max 5 dependencies on other classes. Any more and you should consider splitting up your class.
Summary
What we hope you have learned from this article:
- Just because the Player can shoot and move in the game, does not mean that the Player Script should do it all.
- In an ideal world, a class/script should only have one responsibility.
- What makes large classes really evil is the fact that they undermine the ability to hide implementation details,
- Because of abstraction, we are able to hide implementation details which result into smaller classes.
- Try to keep your classes under 500 lines of code.
- Try to keep your functions under 100 lines of code.
Conclusion
To conclude, we hope you now understand how you can improve you code in Unity by using small scripts. We learned that in order to do this, you have to take into account what the responsibilities of the script are. Also, we discovered how abstraction can be used to take away responsibilities from classes and cut their size down as a result.
Further Reading
If you found this interesting, you might also like the following articles:
