Time to make some abstract enemies.

Image by Lucas Benjamin found on unsplash.com

So far in this journey, when we have wanted to add in a new enemy, we added more methods to an already cluttered script. By using something called an Abstract class and combined with some class inheritance, we can make a script for each enemy and make things neater.

To start off, let’s take a look at the class inheritance side of things. This can be done super easily and is really useful. Say you want all your enemies to have health, speed and how many gems they drop when they die. Instead of having to code all that in each and every enemy, we can use class inheritance.

First, we need a base script to hold all the common parts for the enemy, this can even include methods.

You can have the variables as either public or protected, where public will let anyone change the values, and protected is like saying private on each script. Since we want the different enemies to have access to these values we can’t use private since it will limit it to just the enemy script, hence why the “protected” in this case.

With all that done we can now go to one of our enemies. To inherit from the enemy class all we need to change is MonoBehaviour to Enemy and we are done.

As you can see, we have full access to the variables we made in the enemy class too without having to add them to the moss giant.

Now to change to an abstract class for the enemy, to do this all we need to do is add in “abstract” before the class on the enemy.

Now we can make some abstract methods, this makes it so the enemies that inherit from this class must have the method but have to implement it themself.

In this example we are using the update method, all that was added was again “abstract”, this time before the void. Now when we change back over to the moss giant we should have an error.

We can use the auto-fix function in Visual studios or just add in the public override void Update(){} ourselves.

Virtual lets us choose to override but abstract forces us to override. This can be handy, after making 20 enemies and one isn’t working because you forgot to add a method or oh I have an error, oh yeah… adds method. I know what one I would choose.

And with that, we have a basic overview of adding in an abstract enemy class that we can build on later to make all our enemies from.

Game Developer in the making~

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Dixel Club Introduction

Pandas vs. Numpy? Test it yourself!

Making and inspecting model relations for user story system in GSOC’20

Configuration Validation Software — Video Demo

DevOps helps with technological debt in five ways.

Auto-scale instance on VPC using Terraform


Kafka Producer Overview

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Rose Owen

Rose Owen

Game Developer in the making~

More from Medium

[ SDL2 — Part 8] Rotating textures

Create an object pool in Unity part 2

Computer Languages, or some things never change? Maybe even Deja Vu?

Automate Player Input with Unity Test Runner and NSubstitute