Hi,

I am currently making a game where the enemy chases the player and avoids obstacles if they get in the way.

For that purpose I have made waypoints around the obstacles by which the enemy navigates around them.

My problem is this:

The first time the enemy encounters an obstacle when chasing the player the enemy knows where the player is at that time. But if the player still keeps hiding from the enemy by the time the enemy has approached the earlier position of the player the enemy does not know for sure where the player is hiding. So what should the enemy do at that point? Below I have posted some images to illustrate my problem. I hope somebody can help me.

The enemy is marked green and the player is marked orange. The white rectangles around the obstacles are waypoints.

The waypoint marked green in the second image shows the waypoint at which the enemy starts its search for the player.

In the third image the player keeps hiding from the enemy and the enemy does not know for sure where the player is hiding.

If the way points are known to the enemy, maybe something where the next way point to inspect is based on how recently those way points were inspected (with uninspected points being a priority), proximity of the point to the enemy, and last known position of the player.

You need to implement a navmesh, then make the enemy follow all the lines with raycast on.

@NeedHelp12 I'm making a FPS game where the player fights robots. I had a similar problem as you, and here's how I managed it:

First, I made use of Finite State Machines (FSM). I learned about FSM by reading this great book. When the robot is in the ‘Attack Player’ state, it's attacking (shooting at) the player. But it does more.. It casts a ray to the player to verify the player is still visible. It also continuously records the player's last visible position, and records the player's last visible velocity (direction).

Now say the player runs behind one of your obstacles. When the robot casts a ray to the player's new position, it comes back FALSE because there's an object in the way. The robot cannot remain in the ‘Attack Player’ FSM state, so it changes to a compatible state. The robot may do a couple things:

1. Enter a ‘Standing’ FSM. It will stop where it is, stand and look around for the player, waiting for him/her to reappear.
2. Enter a ‘Search’ FSM. It will walk to the last known position, then it will walk in the player's last known direction for ‘a while’.
   1. If the player is not spotted after ‘a while’, it may:
      1. Return to its original position, and reenter the ‘Standing’ FSM state.
      2. Enter a random ‘Walk Around' FSM state.
      3. Enter the original ‘standing’ FSM state at the current location.
      4. Enter a ‘Patrol' FSM state, where it walks back-and-forth from the current location to the original location

When a robot enters the ‘Standing’ or ‘Search’ state, I add some simple animations that move the robot's head and torso from side to side. Since the rays are cast from the robot's eye, this means it's likely to see the player, even if they're hiding in a corner.

Besides FSM states, that book does a great job describing how to use messages in games. In my game, every sound (footstep, weapon firing) results in messages being sent to all robots in the game. The message basically say , ‘The player made a sound at position XYZ’. Upon processing the message, the robot decides what to do: it may use position XYZ and enter a ‘Search’ FSM if it's close enough to hear the sound.

-Scott

PS I remember the author of the book has a website where you can read it all for free!