Mobile Games In Unity: Enemy Design — Abstract Classes
Right now all the enemies are sharing the data in the Enemy class via their own individual scripts. What if I want the Moss Giant to have a unique attack method? It wouldn’t make sense to write out a whole new method inside the Moss Giant script to handle the attack especially if I want to borrow some of the functionality from the Enemy class’ attack method. This is where virtual methods come in handy.
Virtual methods allow me to overwrite the parent attack method, but allow me to use implementation from it as well. In the enemy class I want to change the attack method form public void to public virtual void. The virtual keyword is going to allow me to rewrite the base implementation.
So now in the MossGiant script, in order to overwrite the implementation from the Enemy class, all I need to do is make an attack method and say:
public override void Attack().
Now whatever implementation I want to put in there, I can. If I wanted to run the implementation from the base Enemy script all I’d need to say is base.Attack beforeth implementation inside the new virtual method.
For Example:
This is the console after running the game. I have the moss Giant calling its own Attack method while the spider enemy calls the attack method from the base Enemy class.
I want this Enemy script to define the enemy behavior. If I have 50 enemies, I dont want to have to type out a bunch of code for each one. My goal here is to define waypoints for the enemies to move to and from. This will be controlled through an update method.
So I could force an update method on the enemies, but each enemy is going to have different waypoints. So one thing I can do is force them to have their own update methods. So using what we’ve already learned I could put a public void Update() in the Enemy class and they could all share that OR I could use a virtual method to override in each enemies script. public vitual void Update(). This implementation makes the update method OPTIONAL though. I dont want that. This is where Abstract Classes come in handy.
Simply changing the Enemy class from public class Enemy to public abstract class Enemy is how to start this.
Doing this allows me to make whats called an Abstract Method. I’ll make an abstract Update method next.
It is initialized without any implementation code.
Now in my MossGiant script and Spider script I should be getting an error. This is due to the fact that I am not implementing the abstract update method in these scripts.
So I’ll need to make sure each enemy has their own unique update methods that are overriding the parent.
This ensures each enemy will be built the exact same way. The program just wont work if we run it without the enemies having this. To test this out, I’ll put some simple Debug.Logs in their respective classes and run the game.
Each enemy is updating within their own unique update method while sharing the common traits such as health. :)
In the following articles I’ll go over setting up some movement so that we can really see how handy using abstract classes can be!
