Populate a list with instance id that are within FOV

T

Taddio

Guest
I need to know if this is is a sound principle, and if there's potential wallbumps ahead before I start doing the maths ans coding. A picture is worth a thousand words, so lets start with a visual of what I need


Basically: top down game, where the view is blocked by an obj_wall.

I only ever used this sort of maths to draw light, so that's kind of my only starting point. Obviously not going to be the same functions, tho, so tell me if this is sound if I just used those same player/wall_corners coordinates to make a triangle and then try to loop through all the triangles using point_in_triangle() to populate a visible_enemies list? Also, Ive been thinking about how to actually get the number of triangle, is there some obscure functions that I should look into, or just make my own counter and forget about trying to make my life easier? :p
Point in triangle will return ALL ids if I don't use it with an instance variable, but with an object's name, right?
If so, I think this sounds like it would work, but also sounds kind of innefficient in a case where multiple instances would need to run this just to set their AI state.

Do you have tips or cues when you need to get the id of the instances in your field of view? Very curious about this, and also doing my homeworks before I get to dive into it. I would rather it be as efficient as possible since this is probably need to run often (step or every few frames at most) with a couples of instances, and going to be the basics to set the AI state
 

Slyddar

Member
I've done this in a top down game recently. First get the id's of all the enemies in your range. Then run a collision_line against each one to see if the player is blocked by a wall. Resulting list will be be valid instances who you can see and vice versa. Only need to run the check every 4-5 steps though.
 
T

Taddio

Guest
I thought about that too, and I admit it does sounds more efficient than using a bunch of triangles checks, but how did you managed the field of view (say 120 degrees field), this will return instances behind the player, if you use a radius? Id still need to use some sort of "triangle" clamp to simulate that, right? I guess I could a hack a couple of angle_difference stuff together to clamp it, tho...
 

Slyddar

Member
I didn't make fov too complicated. If their facing direction was facing the player, that was enough to spot him. If I wanted to get more specific though, each enemy has a moving direction, so it would be easy enough to test a range of degrees against that to see first if the players direction was within that.
 
T

Taddio

Guest
I didn't make fov too complicated. If their facing direction was facing the player, that was enough to spot him. If I wanted to get more specific though, each enemy has a moving direction, so it would be easy enough to test a range of degrees against that to see first if the players direction was within that.
Yeah man, it works perfectly! FOV was simple since I'm grid based and already have a facing variable set to some macros (0/90/180/270) alrealy working good.
Works way faster than expected even in my tests updating in the step event. Whay bogs the thing the most is actually drawing the lines and circles to debug the whole thing!
Thanks man, I really think you did save me quite some time and trouble right here!

Next thing I want to mess with is priority lists, I'm thinking setting part of the behavior based on how many enemies are in sight, so I'll try to use the list size as a weighting factor... Short night ahead of me, I guess :p
 
Haven't played around with it (though it's definitely one of those things I -should- know) but I'm thinking dot_product might be useful here. Have a read of the entry in the manual.

EDIT: Or you can solve the problem while I'm typing ;)
 
T

Taddio

Guest
I never heard of that, gonna look at it right now and maybe get back to you, bro!

Edit: Well, looks really nice. Still not quite sure if this returns an angle, a cos, or what, but I can see the usefulness.

I wonder if doing a check like this instead of sorting through all instances, checking for angles, and then checking for walls would actually make it smoother/change something computation-wise...
As it is, it takes less than 5-6% to run the script step event for 8 instances...yeah, typing this makes me thibk it could be better, but I can just run the script in a self-repeating alarm in the worst-case scenario.
 
Last edited by a moderator:
Top