The Development

As I started the process of working on McShootie it again dawned on me the process required to make a game, but more importantly what became important to priorities when under constraints.

For me these constraints was that I worked by myself and that I had less than a month to complete the project, it's not my first self-made project but it is still a bit limiting to be forced to rely on yourself when it comes to animation, music and finding sounds (as I had no software to make sound effects at the time of making this).

Much of the development time was spent bugfixing, whatever it was AI and making sure it didn't get stuck on things. This went through around 4 itterations, starting with a weight based system. Namely setting out 8 points AI could go towards and setting a weight value for each (lower if obstacles in the way, higher if player was there). In the end this system ended up breaking down due to a number of mistakes made along the way so I scrapped it.
I afterwards tried to build up my own A* system, which I ended up spending most of a week on. Only for it also to break down as it became very difficult to have the enemy work with it for whatever reason (I probably just didn't understand it and leaned too heavily on tutorials). I tried to iterate and redo a couple times but by the time I was on my 3rd attempt the whole week had almost passed and I realised that perfecting it wasn't going to be a fruitful use of my time.

In the end I ended up using the public A* Pathfinding Project to make up for lost time and set it up. This did help quite a bit, even if it took iteration of enemy behaviour logic to get it to work.

I eventually managed to catch up to where I was meant to be and started focusing on what was more important: Gameplay. Having the character able to move around, shoot and run. Once I was able to get McShootie to do that in a good enough manner I moved on to making the first enemy work fully:
Zombie.

This was a bit of a task, because while the former A* pathfinding did help reach the player, moving around would make the zombies not keep up as well as they should. Either they'd move in a very back-forth way due to having to recalculate paths too often or they'd not react on that the player moved. I did implement two systems to counteract this eventually:
First, the enemy controller only checked for player during 2 points. An initial 'walk towards player location' and an additional recalculation once a player moved too far away from the initial location the enemy tried to reach. This worked fine enough, but at times as mentioned caused the mild rocky back-forth movement.
Secondly, once the enemy was close enough it ignored A* pathfinding and instead walked slowly directly towards the player. This meant that once close enough they wouldn't move in a too unnatural manner and would stop once in melee range.

The AI controller itself I did manage to make adaptive, with an ability to check enemy attack range and how it should behave (a meele enemy will approach once close vs how a ranged enemy will shoot a bit before entering their range). This allows me in theory if I want to update in future to implement an enemy easier without having to worry about specifically what the enemy is.

A small QoL thing I added towards the end was fixing that enemies could shoot one another, it was funny to see Hunter enemy shoot the enemies between them and you but wasn't conducive to gameplay. This was fixed by having bullet check both if the target hit and original shooter was a player, if neither was true then they were on same side. If the two bools were different they weren't on same side. What it did afterwards was just temporarily remove it's collision so it could move through an ally rather than kill them.
It ended up functional enough.

Some other side effects from how game worked was that etc. the Drone ended up being able to kill other enemies with it's explosion, it was a neat thing so I kept it in. It allowed some extra level of Crowd control, even if not intended as such.