S.O.L.I.D principle and Unity3D and Game Development-Part 1: Single Responsibility Principle (SRP).

First principle of SOLID is the Single responsibility principle (SRP). According to Robert Martin “a class should have only one reason to change”. In this article, I will try my best to describe this principle.

Let’s see the criteria of SRP.
1.One class has only one responsibility: This means one class only does a single task.

Example- InputManager class only responsible for collecting inputs from the input source. It should not have to worry about who and how uses the input data.

2.Attributes and behavior relevant to a given object should be bundled together and hidden from outside access: Same behavioral components should be together and it will be hidden from outside. To share their component with outside classes they have to maintain a protocol.

Example- An InputManager collects input from keyboard or other sources and MoveController moves the player according to that data. So MoveController script needs the input and it gets it from InputManager. But MoveController has no idea how InputManager provides them. And on the other hand, InutManager also does not know where and how that data is used.

According to Linus Torvald “Talk is cheap. Show me the code”. So let's dive into the Unity game engine.

Task Overview — We are developing a simple game where a user can move the player with keyboard input and if the player collides with an obstacle, it damages health.

The following script is very easy to understand and self-explanatory. It does the above task.

The above script violates the SRP because it does several jobs in a single script. Let's refactor the code according to SRP. The hardest part is to determine responsibilities. So first we list all of our responsibilities below-

1. Manage Input
2.Move Player
3. Collision Detection
4. Manage Player Health

Actually, we have already done 50% of our job. Now we just need to write separate pieces of code for the above responsibilities.

1. Manage Input: Following InputManager script is self-explanatory. If you need to change input logic just change it here.

2. Move Player: The responsibility of MovePlayer.cs scrip is to handle player movement based on user input. It takes user input from the InputManager script.

3. Collision Detection: It is the most tricky and fun part. We use an interface named ICollidable. Every collide-able object has to implement this interface. You will get the idea when we discuss the Health Manager. OnCollisionEnter callback function is called when a collision detected. In that function, we check the layer, and if the collided layer is the expected one then we called the interface(Discuss later on Health Manager).
So the most important part is the job of CollisionDetector is only to detect the collision nothing else.

4. Manage Player Health: Our logic is if a player collided with an obstacle then it receives some damage. We have already implemented our collision detection mechanism. So now we just need to reuse that. As the player is collide-able and we have to detect the collision so we need to implement the ICollidable interface in the PlayerHealth script. In Unity editor, You have to attach PlayerHealth and CollisionDetector script in the Player object. So after detecting the collision Oncollided (implemented function of the interface) function automatically called and damage player health.PlayerHealth need not worry about how CollisionDetector detects the collision, it just needs to worry about its own health-related logic.

I hope you get the idea about the Single Responsibility Principle. At first, it will take some time but eventually, you will be used to it. This principle will help you to write reusable, clean, scalable, and testable code.

Check the full project here.

If you have any questions/ideas please comment here or knock me at my linkedin. I will write about the Open Closed principle in my next article.