This week I can report good progress on the enemy behaviour work, which was the core thing to get right for the very first enemy. The aim is not perfection or to have perfect enemy interactions, but to have something usable and functional that can gradually evolve.

On top of that, I managed to work a little bit on the gun shooting and weapon swapping logic to make weapons more usable by allowing quick swaps and to also buffer the player choice and to also make the weapon swap animation cancel-able, just feels like the right thing to do.

But lets just start with the meat of the work first, which is the enemy behaviour.

Charger enemy – defining the behaviour tree

The first enemy I started to make smarter is the Charger enemy. The premise of this enemy is very simple – it will just charge at you and try to hit you with the charge until the player dies or until the enemy goes off screen (for example if the player is trying to run away).

Here is an image of the scene structure. I am using the Beehave Godot addon to define the behaviours and so far loving it.

The hole logic evolves around a few states – is the player detected and has the enemy lost health if patrolling (this is important because if the player is not in the visible area of the enemy, we want the enemy to reach of being hit from behind)

Patrol patterns implementation

This one was not very hard to get. I mostly followed the example on the Beehave docs about implementing this, so I set two points on the level that the Charger can use to move between.

The logic basically boils down to getting the points as an array and alternating between the indexes in that array and moving between them, pretty simple.

In this example I have enabled the collision shapes to be visible to see the area that serves as a vision cone for the enemy.

Enemy Detected implementation

From this point on, things began getting tricky. I had to think about what that means, what is the logic here, some questions I had were:
“What does it mean for a player to be detected?”

I decided to keep things simple and added an Area2D node to serve as the vision detection area but more issues appeared.

Since our enemy is a RigidBoody2D, rotating that body, to rotate the area when the enemy goes left to right and so on, just did not work properly. Instead, I decided to implement a Pivot Point that contains the detection area and the sprite and only pivot them when the rigid body changes directions. This took me a couple of days to get right.

That was one side of the work, the next was making the enemy reach to the player hits from behind.

Thankfully this was not difficult to implement since we just could reuse the same logic that was used in the area detection but wrap it around some health checks of the enemy.

Enemy charging implementation

This one took the most work. Making the motion of the charge and splitting it into meaningful logic that I could implement was the hardest, here is a piece of the logic showing the different stages that make the charge:

This is because I realised that a charge is not a sudden thing, there needs to be a wind up, an indication, a motion preparation, speed ramp up and execution. This worked nicely one way, the issue was making the enemy turn when the charge is finished based on where the player was relative to the Charger, i.e on the left or right.

This was he simplest thing I could come up with and works just fine, for now. There is an issue where the sprite flips a bit too soon but that is a problem for later, the core of the functionality works.

Hand Canon work (Blunderbuss)

I have also spend some time making the gun work a bit better in terms of shooting. I have added what would be pellets, so now we shoot in a random patterns, for a short range, good for finishing damage.

Each pellet has its own base damage because not all pellets could hit the enemy and some could miss:

This seems to work just fine but not sure as of yet if I should display the damage individually or aggregate the damage and display at as one number, time will tell.

Weapon swap animations

Finally, here is the improvement to the weapons swap system.
It allows for a quick switch between the different weapons by using a slightly better buffering system:

I figured it might be better to have this as an option and include it as a feature and let the player decide if they want to use it or not.

Closing thoughts

Overall pretty happy with the progress this week, I think the foundations for the enemy behaviour is coming along nicely. It is not perfect but I do now have an enemy that I could engage in combat and kill, although it won’t be fair fight because I have not given the functionality to the enemy to do damage to me! Oh well, it will be like that for now 🙂

Core focus remans working on the CORE LOOP, which is the combat and interaction between the player and the enemis, this remains the focus for the forseable future. Next week I will work on the second enemy, which I will tell you more about next week.

Thank you for reading all of this, any questions or advice, please let me know! See you next week!