Enemies and Interactions Devlog

Hello and once again welcome back to my devlog series for Dont Get Caught By The Cat!

If you read my last entry regarding basic level blocking, you'll know the game now has a world for the player to explore. However, it's a bit empty at the moment making the player very lonely. So today we'll be discussing enemies and interactions.

First let's get into some quick updates on the level blocking and design. Since my last devlog I have added torches to walls and armored guards at dead ends. I have also removed walls within the maze as planned. Here's how a level looks at the moment. Take particular notice of the mini map to see the changes removing walls makes.

As suggested by the title of the game the main enemy will be a cat with the sole aim of chasing and catching you as you navigate your way through a maze. Clawdius, the humanoid cat and owner of the castle your trying to escape, will serve this purpose. The basic idea for his behavior follows this logic. At the beginning of each level he will simply be roaming around the maze, but if the player is within a certain vicinity to him, he will begin to hunt them and move faster. If the player manages to escape him by leaving this vicinity, Clawdius will go back to roaming his castle.

To implement this behavior I needed to tackle the confusing and challenging task of pathfinding. My method of choice was the A* algorithm that finds the shortest path from node to node by calculating the cost of the movement and moving to the node with the lowest cost. I came across this lovely pseudocode at the end of a YouTube video explaining the algorithm. 

Here's the algorithm working in Unity.

With the pathfinding working nicely, I began animating Clawdius with another sprite sheet made by my mum Sara Hollingsworth. For now Clawdius only walks but soon he will be running on all fours when hunting the player. 

The next and by far the most underestimated hurdle to date was making Clawdius follow the path and generate a new one upon reaching its end. Going into this task I thought to my self,

"I've made a maze generator and an A* pathfinding algorithm this is going to a piece of cake for someone as great as me!!!!!"

I was able to get Clawdius following the path pretty smoothly but getting him to follow the newly generated path, now that was a different story. For some reason, upon reaching the end of one path and generating another, sometimes Clawdius would seemingly make a random turn resulting in him walking straight into a wall.

After several hours of debugging and considering dropping out of university multiple times, I realized that in classic overly confident coder fashion, I had made a small and what should have been an easily noticeable error. I was never adding the node Clawdius was standing on to the start of the path. 

Now that Clawdius was moving around the maze, I started implementing his hunting behavior. I did this by adding a CircleCollider2D to him and setting it as a trigger. When the players collider enters this trigger Clawdius immediately makes a new path towards the player and starts moving faster. If the player is still within the trigger by the time he reaches the end of his path, another path is made to the player, otherwise he goes back to roaming.  

In addition to Clawdius hunting the player, I decided to make use of the armored guards by making them charge at the player if they enter their line of sight. I wanted there to be two possible outcomes of their charge:

1: They charge into the player stunning them for a brief time.
2: The player dodges them and they go crashing into wall destroying themselves.

To accomplished this I added a trigger to each guard that extends to the length of the corridor they're guarding.

Playtesting feedback was generally positive with people taking a liking to Clawdius and feeling his behavior was mostly balanced. The guards however received a bit of a beating.

" I like how the cat works, I did have an issue sometimes where after getting hit by a guard instead of being stunned my character would move"

We talked more about the issue and found that it occurs when you have already been stunned and are then hit by another guard. People also felt that the guards made the game feel slightly too difficult and thought that it would be a good idea to either decrease the amount or to decrease their speed. At the moment I'm unsure which approach to take but am leaning towards decreasing the number spawned.

 Additionally, as if the guards weren't already feeling bad enough about themselves, players were frustrated with the lack of visual cues to show they were being stunned upon a collision.  

" I couldn't tell that I was stunned, if I didn't know that's what was supposed to happen I would've thought it was a bug." 

To fix this issue I'll add an animation that indicates being stunned such as some ducks floating around the players head. Similar to this animation I found.

https://www.artstation.com/artwork/yJqKw5

Thank you for stopping by and I'll see you again next time :)