Alright, hopefully that wasn't too difficult,
and you've now had a Walker enemy walking along your surfaces.
Hopefully looks something like this.
There is one. There we go.
Alright. We have an enemy walking along
a surface which is one of the things that a Walker must have.
More importantly is not falling off which is
definitely one of the things that should not have.
This is an enemy that's actually going to challenge a player slightly.
There's one issue but it's not actually having to do anything with our enemy.
When our character attempts to jump on it,
we are not squashing this enemy like we should.
However, this is something I'm going to change in my character script,
rather than introduce and to every single one of my enemies.
We've successfully used enemy base class to create
a more complex enemy to challenge or player and that's fantastic,
and we can create another one and another one,
and dozens more based on that base class and get a whole bunch of coding for free.
Well, we also have to introduce our flying enemies to help
our player bridge the chasms that they have to jump over.
An enemy on the ground,
an enemy in the air are going to be behaving in different ways
so it might help us to create an extra layer of abstraction,
further differentiating an enemy into an Air enemy and a Ground enemy.
Each one of those coming from the enemy base class.
The enemy base class will handle health
and what it means to get squashed and add to the player's score.
The ground enemy will incorporate all that and also include
all the mechanics for detecting what is ground and what is a deadly cliff.
Whereas, the air enemy will handle flight stuff,
handling gravity and making sure it doesn't fall into the abyss or go too high.
By further differentiating these codes,
we will save ourselves more times as we further branch out,
and we also get the ability to tell scripts to only
use an air enemy or only use a ground and enemy and not just any enemy.
This will help to make our code a little safer,
we will definitely be checking to make sure what an enemy type is,
and we'll be saving ourselves time.
And we can go even further than that,
the Walkers are movement, but the Jumpers,
they don't actually move left or right so we might have to
further break it down and this is where we're going
to start designing our zoology of NPCs.
We're going to start at the base class at the top,
split into our ground and air enemies,
and if Steve gets creative one night,
there might be a third enemy, I don't know.
And from there we can break down further and further making
extra layers of what an enemy is and is not.
It's almost like making your own taxonomy of NPCs.
And every time you go up a level,
NPCs get a little bit more similar,
a little bit more similar until you get to the base class
where all enemy share the exact same attributes.
Mapping out your zoology of NPCs is going to help you design them in
the long run by figuring out what shared attributes are necessary at what points,
and where a branch off is required.
When you're done mapping out your zoology of NPCs,
go ahead and start coding out the various NPCs you want in your game.
I'm sticking with the GDD of course,
but it never hurts to experiment a little if you see a good idea.
I know designers are generally very happy to receive improvements on their own genius.
At the end you should have a playable game.
It may not have a lot of feedback and the controls might be a little weird.
It might be a little bit more difficult than you hoped for,
but it's playable and we're on the right direction.
Go ahead. Get your NPCs working and get your game into a playable state.
In the next module, we're going to introduce some user feedback
to help you test the game and make it a bit more fun to play.