A possible implementation of AI line-of-sight and awareness


So I can’t sleep because I came up with a pretty solid implementation of line-of-sight for my robot enemies, and I can’t stop thinking about it. The technique gives an enemy different degrees of awareness depending on its distance from the player. It gives the enemies pretty human abilities while, I think, keeping things fair. Requires testing, of course. The technique is as follows. There are two awareness levels: LOS only, and LOS and Sound.

LOS only:

  1. Every real time second, each enemy checks if they are facing the same direction as the player (120° arc?).
  2. If an enemy is facing the direction of the player, it does a quick vector maths check to see if its XY vector position is equal to or less than 90% of the max draw distance the player has set. Set this max detection range as maxEnemyViewDistance, and update it every time the player adjusts draw distance..
  3. If so, the enemy draws three rays from its own head directly to the player’s head, center of mass, and knees. This helps avoid silly situations like a player being invisible behind a chest-high fence.
    • At max range, three out of the three collision rays must be unobstructed by opaque objects (will have to join such objects to a purpose-made opaqueNode.
    • At three quarters enemy view distance, only two of the three rays must be unobstructed.
    • At or above 4/5 maxEnemyViewDistance, all three rays must be unobstructed for the enemy to have LOS. Count “gapped” objects like bushes and grass as total obstructions.
    • At or above 3/5 maxEnemyViewDistance, two rays must be unobstructed. Count gapped objects as obstructions.
    • At or above 2/5 maxEnemyViewDistance, one ray must be unobstructed. (Maybe require at least one opaqueNode object collision for the player to remain undetected, like a player who is completely hidden by a tree, and whose knees are behind a rock?)
    • Below 2/5 maxEnemyViewDistance, the enemy switches to LOS and Sound mode.

LOS and Sound

The enemy is surrounded by two half-sphere ghostCollisionDomes. The one at the front 180°(like a shield) is sight, the top 180° (like an umbrella) is sound (larger radius than sight).

  1. Player actions that create sound within the Sound dome make the enemy look in the direction of the sound. (Running, reloading. Thrown objects?)
  2. Enemy makes a per-frame (maybe per half second?) collision ray check on the player, this time with multiple rays to cover head, center of mass, knees and arms. Collisions with opaques are ignored.


Back on the horse. Today I want to finish implementing my randomisation stuff on the bird launching, then go on to do player controls.


End of day. I lost a lot of time refactoring my code today because I didn’t fully consider the objects I was making. I made a bird method, a pellet method, a launchBird method and a launchPellet method, and after a few hours of this I finally realised that birds and pellets were similar enough to combine into a single projectile method, and likewise with the launcher methods.

A big chunk of the day, aside from that, was spent on the maths of trying to randomise the vector headings of launched objects like birds and (especially) shot pellets. All of my previous solutions resulted in the shot pellets being propelled away in a horizontal line.

I learned how to use Line geometries to debug vectors by placing them at the start and ends of my vectors, and then made an empty testing area to test different methods of randomisation and have the results displayed to me as lines. I eventually hit upon the method of randomly generating a float between 0 and some arbitrary number, and then adding it to the X and Y components of the common aimpoint vector. The method works wonderfully, and I went on to apply it to my birds as well.

Here’s an interesting image. Making my birds behave in the way I want them to has been hit-and-miss, so I used my newfound line-drawing skillz to visualise what they were doing.

The red line is the common aim vector that all birds head towards (their actual heading vectors are slightly randomised). The white cones coming from each station are the ‘actual’ aimpoints that my code is firing the birds towards, but strangely, they actually do travel along the red line. It makes no sense and I want to debug it tomorrow, even though the game is doing what it’s supposed to.




Nike Air Max classic Nike Free Run sale Nike Air Max kopen Nike Air Max shop Nike Air Max classic goedkoop Nike Air Max 90 goedkoop Nike Air Max 1 kopen Nike Air Max sale Nike Air Max 90 sale Nike Air Max kopen online