Well I’m doing this game for an assignment we’ve been given. I haven’t faced many coding issues other than the occasional “bullet not firing” kind of problem.
While everything’s going ok, it feels strange because from the way I’ve been using this game engine I really haven’t found the need to structure the code in such a way which includes abstract classes or interfaces for example. I could if I wanted to, but to be honest it seems like I don’t really need to because of the way the Unity’s scripting mechanism works.
My question is; am I the only one with this school of thought? Would it be better in terms of game development practice if I implement this structure into my code? Does the engine like working with abstract classes more than regular “attach and go” code?
It’s possible to use abstract classes and interfaces in Unity, yes.
Should you use them? I don’t know. Do you need to use them?
Some useful tips:
Public interface type fields can’t be set via the inspector.
Public abstract class type fields can be set via the inspector.
You can’t use polymorphism on System.Serializable tagged classes or you will experience type slicing.
You can get components implementing an interface via GetComponent(typeof(MyInterface)) but you can’t use the generic version.
As a rough guide:
Normal classes extending from MonoBehaviour are easy and works for most problems you need to solve
Normal sub-classes works as you’d expect. If your goal is code reuse favor composition over inheritance.
Abstract classes are not much harder to use (remember you need a concrete implementation)
Interfaces are working against you if exposed in public fields, shown in the inspector
From my experience, abstract classes can better be used as interfaces (just leave all methods abstract). I say better, because at least you can serialize the references properly. However you can only inherit from a single abstract class (or chain them). Interfaces have the benefit that you can implement multiple interfaces. You can’t do the same for abstract classes.
You will also carry the baggage of MonoBehaviour. This can be both a relief and an annoyance.
public abstract class Explosive : MonoBehaviour
{
public abstract void Explode();
}
I really haven’t found the need to structure the code in such a way which includes abstract classes or interfaces for example.
This is a good thing, generally. You should favor composition over inheritance. Unity makes it very easy to do this and you should favor composition when you have no need for inheritence. However it gets awkward when you want to decouple from Unity, like if you want to run Unit Tests separately.
If you feel lost on the topic of composition over inheritence, I suggest you pick up a book on design patterns as they will discuss it until your ears bleed. One that I found good was Head First: Design Patterns but there are more canonical books on the subject like Design Patterns: Elements of Reusable Object-Oriented Software by the gang of four. I found Head Firsts book to be very easy to follow and I’ve had a lot of use of the skills it taught me.
If you don’t know what Unit Testing is, I can recommend a book called The Art of Unit Testing which I found good.
I say, as far as possible,split your codes to bunch of components.
For example suppose you need the reload function. You know that all of weapons need to reload
so you write an abstract class “weaponsystem” and an abstract method reload,then you write several classes(SMG,AK47,M16,G3) that implement the reload function.it is cool but suppose that G3 and AK47 have the same reload function but M16 and SMG have the same one. what to do. You need to copy and paste reload codes for G3 and AK47 (and M16 and SMG). It is not bad? surely it is bad and causes problems.
now suppose you write an interface IReloadable and implement it in Reload1 and Reload2 class.
So you can use Reload1 for SMG and M16 class and Reload2 for AK47 and G3 easily.
Component based procedures give you a power you can easily extend your codes and programs.
Use abstract class or common class for inheritence only when you are sure you need them.