Making a Game Part 2 – AI

This week I chose one of the more difficult artifacts on the sprint planning: making the enemies chase and then kill the player.

My first thoughts about this was to just make the player “lose the game” if he collided with any of the patrolling guards.
Now, instead of doing a collision-check I made a function that returns the distance between the player a guard (cycling through all the guards in their Update()-method):

Which basically just does a pythagorean calculation and returns the hypothenuse, the distance between the two.

For testing purposes I commented out the enemies patrolling-code and wrote the code for chasing after the player in its stead, the results were quite scary as the player now had every single enemy on the map moving towards him:

The code for chasing the player:

This calculates the unit vector and then moves the enemy accordingly (the *2.f is to make them faster while chasing, to simulate them running).

These screenshot were taken after I made the enemies also rotate towards the player, before this they were just coming at you while facing random directions which looked really weird, the method used for the rotation is the same as for rotating the player towards the mouse cursor, using atan2 to calculate how the enemy should face in radians and then converting it to degrees (radians * (180/pi)), the code for this calculation:

Now, if I was going to make the guards only chase after the player if they saw him or if the player got too close to a guard I had to either have a bunch of booleans (patrolling, chasing) or a AIStateManager handling this, I chose to go with the statemanager as it would have to be done eventually and its better to just write it now rather than having to rewrite the code later on.

This manager was heavily inspired by my statemanager from the last course, with a fixed number of states defined with an Enum (Patrolling, Chasing and Returning) and then just made an AIStateManager as a member variable for every enemy.
Now I used the FindPlayer()-method I showed earlier to determine what state the enemies would be in:

If the player is within 200 pixels of the guard it will switch to chasing-mode and if the player then moves more than 1000 pixels away from the guard it goes back to patrolling.
the “GetState() != PATROLLING” is because it started spamming the SetState().

Some issues with this: The guards have no collision and thus chase after the player while just walking through the walls, they also “see” the player from behind a wall so there are some tweakings left to be done in this.
What I have to do now is fix the two major problems I just mentioned, the first one will be solved with implementing some path-finding (most likely A*) but the second one I don’t really have a clear idea of how to solve, maybe I’ll try getting the unit vector between them and then go step by step checking to see if there is a wall anywhere along that line, and if there isn’t: CHASE.
There is also the possibility of soving both problems at once with A*, if the path between them is a line: CHASE.

That is all for this time, thank you for your time and I’ll see you next week!