Efficient approach to Enemy LOS involving Player and Obstacles?

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.
  • I have a little problem concerning detectors that I can't seem to figure out. More specifically how enemies can tell the difference between spotting a player and not being able to see him due to an obstacle between them.

    Behold! My artistic sketch(and notes below) to help illustrate my question:
    Please login to see this picture.


    A) Enemies in my game will chase you down upon detecting you. To detect the player I have 1 rectangular active object act as their line of sight. If it collides with the player the enemy will rush towards him.

    B) The problem is that if the enemy happens to be behind an obstacle it will just end up continuously knock into it forever since it will try to chase the player despite being blocked.

    C) So I figured why not chase player only if the detector isn't also colliding with a wall? Well... It turns out that you can also hit an obstacle behind the player...

    I'm coming up short on ideas. Best I've got so far is that I could have the enemies fire tiny detectors like bullets. Then if they hit the player, enemy start chasing but if detector hits a wall instead it'll just simply destroy itself. However having a bunch of enemies firing a bunch of detectors each isn't very efficient on performance, especially not when I want them to instantly react to the player's presence. Fastloops also become very performance heavy once multiple enemies starts checking for a player and obstacles.

    Please login to see this link. Please login to see this link.
    Freelance Dev | Currently Working on Jarvis | Please login to see this link.

  • Use a 1x1 dot active as the line of sight. Then, scale it on the X axis to be the distance between the enemy and player, and angle it using the angle between them. Now only chase if that line isn't overlapping an obstacle. You won't have to worry about the detector colliding with an obstacle behind the player since it always draws a line from the enemy's hotspot to the player's hotspot.

    To optimize this, you could only perform a LOS check if the player is within a certain distance of an enemy.
    It might also be better depending on the situation to make the line 2-3 pixels thick on the Y axis to avoid seeing through really thin edges between obstacles.

    Best person at writing incomprehensible posts. Edits are a regularity.

  • As a practical example and fitting addition to casleziro's post you may find the examples Line of sight and Nearest object on schrodinger's Homepage useful.

    Currently working on ... [SIGPIC][/SIGPIC] ... a Puzzle Platformer

  • In my game I've just 3 detectors evading from the PLAYER to left, right and up. Each of them scales down when overlapping backdrops and scales up when not. If enemies overlap one of those they spot you and quickly cool down if the overlap ended (they wait some seconds in front of obstacles for you to reappear). If an enemy is not facing in the player's direction the overlaps aren't checked, so you can sneak behind them.

    It's not as precise as line of sight drawing, but very easy on resources, as you only need to do 3 background overlap checks each frame and not a scaling operation plus background check for each enemy instance. IMO 100% accurate for enemies that have a mostly horizontal platforming moving pattern (like most in your game).

    There's also one additional detector for checking melee execution range, but as this one is extremely narrow anyway I don't have to check for background overlaps there. If you're in need to check various range scenarios for different enemies you could also replace this by a simple distance calculation if the enemy was already primed by one of the players detectors.

    edit: here's a quick demonstration of the detector method (horizontal detectors only)

    [video]Please login to see this media element.]

    Please login to see this link.
    Please login to see this link. | Please login to see this link. | Please login to see this link. | Please login to see this link.

    Edited 6 times, last by Julian82 (October 3, 2017 at 9:55 AM).

  • Does CTF not have trace hit functionality? That's kind of a basic fundamental component of game engines and has been for decades.

    But the last game I published was using a dev platform that didnt have raycast (trace hit, not the wolfenstein sprite skewing kind), and I had to resort to the bullet approach youre describing, and yes, it became a huge performance hit, so if you can avoid it,


    Sent from my iPhone using Tapatalk

  • Thanks for the ideas, guys!


    I'll probably use a bit of both of your approaches casleziro & Julian82. Most enemies really just need the basic "Oh is the player in front or behind me?"check where Julian82s approach is enough. Luckily in my case I don't think I need an Up detector either!

    But I can definitely see some special enemy types that could use casleziro's method, for instance to fire off ranged attacks. My bowmen are really, really dumb atm and could use an upgrade in their targeting!

    Please login to see this link. Please login to see this link.
    Freelance Dev | Currently Working on Jarvis | Please login to see this link.

  • Julian's solution is surely very practical and fitting, probably more fitting than a line of sight for a platformer
    (enemies could become too much sensitive to the player XD unless you add an extra test for a "viewcone" maybe)

    the line-of-sight test is quite efficient though, Fusion is very fast at scaling,
    plus you can use it at its best by considering some things that (perhaps) are not immediately evident:

    1) you need just one line of sight object for testing as many enemies as needed
    2) you can fire the test only for enemies in a range
    3) you can split the test through frames if really needed, if you have a *very* large number of enemies, you might not need to draw a line for all of them in the same hundredth of second XD
    4) to build the line better using ATan2 for the angle (more precision than OAngle at very little additional cost, especially needed when enemies are far)
    and ODistance instead of sqr(...) (much faster and worst case you only lose a fraction of pixel in precision)

    just to lay down some additional thought as this is a pretty wide-purpose solution,
    perhaps might be useful to someone else if not for Chrilley :)

    a selection of my Fusion examples can be found Please login to see this link.

  • btw if you need 360 detector without using extra actives - you can use builtin line of sigh by picking all objects in a line.
    1. Pick all objects in a line (X Chaser, Y Chaser, X Player, Y Player) - set on sigh "true"
    2. If on sight "true" - set on sigh "false"
    It's works pretty good. And you can use extra events like comparing distance to limit view.

    Please login to see this link.

  • btw if you need 360 detector without using extra actives - you can use builtin line of sigh by picking all objects in a line.
    1. Pick all objects in a line (X Chaser, Y Chaser, X Player, Y Player) - set on sigh "true"
    2. If on sight "true" - set on sigh "false"
    It's works pretty good. And you can use extra events like comparing distance to limit view.

    Oh wow I had no idea this was a thing. Fusion has so many built in things that flew under the radar for me.

    Please login to see this link.
    Please login to see this link.|Please login to see this link.|Please login to see this link.

  • @ alexexhowl: that unfortunately proved to be buggy in the past (not detecting objects in the line) - wonder if it's been fixed since, did you use it successfully?

    a selection of my Fusion examples can be found Please login to see this link.

  • @ alexexhowl: that unfortunately proved to be buggy in the past (not detecting objects in the line) - wonder if it's been fixed since, did you use it successfully?


    Here example from Sketchy. Please login to see this attachment.
    I guess that example
    1. works only with actives as obstacles.
    2. only one enemy can be triggered.

    Please login to see this link.

  • Sketchy's code is (obviously :)) good,
    but the builtin "pick-in-line" is unfortunately broken:

    Please login to see this attachment.
    as you see, the square object in this situation is not picked,
    while it falls clearly along the line :(

    not sure it's worth a bug report as we have other reliable solutions,
    maybe should be tested for speed to see if it's interesting enough..

    a selection of my Fusion examples can be found Please login to see this link.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!