Interfaces: IDamagable Interface in Unity

Just like abstract classes, interfaces are crucial part of object oriented programming that eliminates excessive coding and workload. Despite, interfaces are not classes and we cannot create instances of interfaces. Interfaces are especially handy if you have many different objects sharing a functionality.

Imagine the scenario where you are hitting an enemy and want to tell the enemy that you have given a damage to it. Normally, you would have reference the enemy script by using GetComponent and tell it to run the Damage method. In other words, the Player object needed to know which enemy it is hitting and reached to it in order to damage it. Well, what if you have tens of enemies and numerous objects that you can damage? Are you going to reach them one by one? Can you imagine the workload?

Using interfaces, we can eliminate this problem. Interfaces work as a binding contract to the objects applied. It simply states that the class that is implementing the interface has to include the property or/and method(s) that exist in the interface. Here, it shall be noted that interfaces are not inherited — but implemented. Irrelevant from their classes, by using interfaces we can simply force any implementing game object to implement a method.

For instance, as we hit an enemy that implements an interface, the player does not needs to know which enemy that he/she actually hitted on. We basically tell the other object to implement the Damage method — without using any GetComponent. As we know, using Get Component method is expensive and we should avoid using it unnecessarily.

Traditional syntax for interface scripts is to start with I and then the script name, such as IDamageable. Here, I denotes that it is an interface. An interface does not inherit from MonoBehaviour script.

Just like the abstract methods, the method(s) within the interfaces does not include any implementation. Using the interface simply forces the object that is carrying it to include the property and/or method(s).

Abstract classes and IDamageable Interface in the Dungeon Escape Game

Interfaces can not include any fields. Rather, they can include properties.

In the Dungeon Escape game, to create the damage behaviour, an IDamageable interface is created. As can be seen below, interfaces are not defined as classes.

public interface IDamageable{int Health { get; set; }void Damage();}

Although an object can only inherit from one class, it can implement infinite number of interfaces. To implement an interface, we simply add the name of the interface with a coma just after the class that the script inherits from.

As can be seen above, if we do not include the properties or methods from the interface that the script is implementing, we will get an error.

On my previous article, I have explained how to implement a hit box attack system in Unity and attached a hit box to the sword of the Player and an Attack script for detecting the objects that we hit on(click here for the article). The objects that we can damage with the sword will be implementing the IDamageable interface.

Here are the scripts for Attack (that is attached to the sword) and the enemy that we are hit on — I have included the comments to make things more clear. It is exciting that we can use the same IDamageable interface for damaging the Player also; an enemy hitting to the player does not need to gain access to the Player script.

That is how easy it is to use interfaces. I will do my best to build this habit on the games that will benefit from this. Exciting :)

Unity Developer