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 and 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!
The Bulldawg Blawg 
Hiya!
You do a pretty good job of describing what you do, how you do it and why you do it and also whatever problems you’ve had in your work. I definitely think that this post could be helpful for those studying simple beginner AI, well, apart from the problems you mentioned yourself. The execution of the code and your comment are both well done.
Calculating the hypotenuse for the distance is really the way to go when it comes to the “aggrozone”; it gives the enemy a nice circle area to detect the player in.
I was wondering though, are the guards going to be having a “cone” of some sort in the future where they detect the player or will they simply locate the player as soon as he gets close? I think that gameplay-wise the latter would be rather confusing for some people since we are used to guards who change their direction to also change their point of view.
Also, something I was thinking about was if the guards going to be able to see the player’s light-source or not or are they simply looking for the Player himself (I am going to guess that you were one of the groups with dynamic lightning). That might be kind of hard to implement though.
That’s… pretty much all I have to say, in summary your post is pretty informative and your code is well-written. That’s all I can say, really.
Good night and good luck with the rest!
Thank you for your comment, it is very well written.
The guards will have a mixture of both a circular detection area and a cone, the circle will be in very close proximity to the guard while the cone reaches as far as his “flashlight” can see.
There is also some tweaking to be done to account for the walls in both of these detection-triggers, but that is a problem for another day.
The player doesn’t have a light source but a field-of-view (apparently he has very good night vision) in that he doesn’t see things that are not visible in a straight line, meaning that he can’t see behind walls and such.
I hope I’ve answered your questions and good luck to you too.