It seems to run smooth with 5 - the difficult bit, as you can imagine is working out which enemy has seen you. This is what i did to determine which one - probably needs work here …maybe even a raycast? but i shall test all the alternatives first before i give in to that one!. ill post the rest of the events once ive polished them up
does light collision work well?
Yes …as I mentioned above I need to refine determining which enemy did it when there’s lots of them. Also, if you don’t want search lights then it’s not the route for you.
I’m not saying that the methods I’m suggesting are better than raycasting…I’m experimenting!
What worked well was when I used three of the cone object that change scale …but how efficient that is …not sure …I need to look at it in the profiler.
Checking collision is not efficient
You want to limit it by distance which is still not ideal
Your method will lag game way faster than raycasting
But for that you will need a lot of objects obstacles/enemies
The light obstacle ones not using any collision checks, just read pixel every fifth frame.
I’m going to test the other one now with lots of enemy and see what its like
the red ray is not important right?
This is with three expanding sight cones and with 5 enemy. The profiler was .64ms with 3.59 percent of total on collisions and loads of pathfinding error calls
you’ll be happy to hear that im leaving it there!
I was passing by…just wanted to agreed on thes zero’s words.
the read pixel one should be more efficient than ray casting
I’m not criticizing the method—as long as it works. In fact, I think you did a pretty good job. But… You’re scaling in real time,(not just as object scaling…but as collider)…and checking collisions “almost” on each frame (since, in my opinion, that <600 px doesn’t help much).
Just saying: it works, it looks good, and for a game like this I guess it’s okay. But personally, I wouldn’t use it…in GD*
thanks -by the read pixel one i was talking about the light sensing using light obstacle …if you want enemy lights that one worked pretty well.
The other one does have timer check as well as 600 pix limit but it’s a lot of objects and so i would just consider using it if you want a visual effect like that.
U know @petlimpet this game should be in the gdevelop template section right here.
(if u already are giving templates on itch this is just embarrassing 
)
Thanks @zGameCreator - it is on there, it’s the top-down one. I just messed about with it.
I can send it to you. Charging for it would be like me charging people for my spelling!
I’m on itch …but i’m not exactly a heavy weight on the platform! If you subscribe i’ll be that bit closer to reaching double figures!
I’d be interested in a copy of the templates too. Both the triangle version and the dynamic lighting version
yes please! i love the way you did all of it. infact u should make topic so not only i can get it, but @AquaEcho and others as well! 
no silly 
, i meant the raycast thing u added!
How is that messing about? its pure genius no?
everybody like this post if u think its genius. 
Thanks for that …it’s not raycasting though. I was thinking of alternatives to raycasting. I’m not saying these are better than raycasting… just alternatives. The one with the three cone shapes for each enemy is more complicated than the light obstacle one. The light obstacle one is based on what mr men did in the thread i mentioned above but i’ve added the player pixel colour being read …its a light sensor. I used to play torch tig when i was a kid …it’s a bit like that.
I need to tidy them up - there’s pathfinding issues to sort out!
I’ve done this to the first idea. There’s Home and game scene, scoring, storage, level select etc. it runs fairly decent with 20 enemy but the pathfindings still seems clunky
link to project on itch - password ‘SQUID’
Hedgerow Hideout GDevelop Template by Pet Limpet
