Unexplained code change

[Guybrush]

Hi,

At 3.52 the code looks like this:

public class Player : MonoBehaviour

[SerializeField] IGun activeGun = null;

void Update()

If (Input.GetKeyDown(KeyCode.Space))
{
FireWeapon();
}

void FireWeapon()
{
activeGun.Fire();
}

At 4:07, it turns into this, with no explanation:

public class Player : MonoBehaviour

[SerializeField] MonoBehaviour activeGun = null;

void Update()

if (Input.GetKeyDown(KeyCode.Space))
{
FireWeapon();
}

void FireWeapon()
{
if (activeGun is IGun)
{
(activeGun as IGun).Fire();
}
}

Does anybody know why this happens? Thanks.

[bixarrio]

Why did it change with no explanation?
I don’t know.

Why did it change?
Because Unity cannot serialize interfaces at the time of the video, which mean you cannot have an interface as the type of the fields. Well, you can, but they won’t show in the inspector. Perhaps Sam realised this and changed it, but did not update the video to explain.

[Guybrush]

Thanks for the answer.

So can we say that back then, the two were almost equivalent (the exception being you were not able to assign an interface in the inspector) and today they are equivalent (you can assign an interface in the inspector)?

[bixarrio]

I tested (Unity v2021.3.12f) and the answer is no. We still can’t use interfaces as types to assign objects in the inspector. In general we can use interfaces as types, but Unity will not expose it in the inspector. So, this leaves us with having to refence GameObject (or MonoBehaviour like Sam did) and cast when we use it. What I tend to do - if the project allows it - is to create a base class (from the interface, or raw) and then reference that.

[Guybrush]

Thanks a lot.

In this case the use of an interface is very similar to an abstract class. The responsibility of implementing the interface method or inheriting an abstract method belongs to the child class.

Do you have a recommendation as to when to use an interface and when to use an abstract class in this type of situation?

[bixarrio]

The way I think of it is to use interfaces when the implementations are vastly different. Perhaps we have a weapon. Weapons can be swords, axes and hammers but weapons can also be pistols, bows, rifles. These are quite different from each other. One have projectiles, the other doesn’t for example. An interface is good for the weapons as a whole, but I’d have a MeleeWeaponBase base class for swords and axes, etc. and a RangedWeaponBase for the pistols and bows. I’d use a base (abstract) class because these types are quite similar. They have lots in common and may share functionality.

When it gets to Unity, we have the problem that we encountered here where we can’t reference the interface in the inspector. For this, I’d maybe make the interface, but then create a base class that implements the interface but provides no functionality. So, basically a class version of the interface. This way I would be able to reference it in the inspector.

This is not necessarily the best way to look at it, but that’s how I tend to use it. There are other pros and cons to using either that I didn’t get into. Some google-fu will get you finding what you need to know

[Guybrush]

Thanks a lot

[Brian_Trotter]

@bixarrio

Perhaps Sam realised this and changed it, but did not update the video to explain.

This is exactly what happened. It was a long time ago, but I confirmed this with him quite a while ago.

[Guybrush]

Ok thanks