more efficient line of sight on tilemap?

0 favourites
  • 9 posts
From the Asset Store
solution for games like "fruit ninja" and drawing applications
  • Hi,

    i need to check if NPCs on my tilemap can see each other.

    my problem is that the built in line of sight behaviour is way to cpu consuming for my project.

    here is how i did it, make a second tilemap with all the sight blocking obstacles, make this tilemap solid, then use LOS behaviour and bam this game isnt build for running on mobiles :/

    i think the los bevaiour is way to powerfull for my needs and im pretty sure there are many many algorithms that do that more efficiently (bresenham, raycasting) and when i read about it, it seemed so easy but im to dumb to understand any of them to do them in construct2. My floodfill approach did either too much or to less, i dont get how to check if the tile isnt just empty but also seeable from the position, so yeah, i did understand the raycasting approach but not how to build it.

    My dream would be that i overlooked an plugin where i just specify the range of sight in tiles, blocking obstacles and then use it

    can anybody help me? im not a native speaker so its possible i overlooked some good tutorials, the main problem in finding information was to me that there where so many and most of them where with complicted code that i didnt understand.

  • Your method seems OK. Do you have a example capx?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • right now, i just have a broken mess and a theoretical concept that lacks the knowledge of how to implement it in an algorithm.

    The best approach i had till now was to make a function that gets four parameters (X & Y of the tile to check, direction and an loopindex to controll the distance of view).

    The function then checks if the tile is ground or wall, if ground then this tile is seeable and if the loopindex isnt too high it will call the function again to check the next tile in that direction. That works for four directions, if a blocking element is found it will stop to look further in that direction. But there arent just four surrounding tiles, there are 8 and all my approaches to also check the other tiles AND stop looking further when a blocking element where found didnt work.

  • I meant the line of sight behavior approach should be sufficient, also not too heavy unless you really have tons of objects, so I wanted to see how badly it was lagging and if there was anything else causing the lag.

  • heres my approach http://fldr.de/lostest

    here it is with los behaviour, even in this striped example you can see the cpu spikes http://fldr.de/lostest2

    here is a capx http://fldr.de/lostest.capx

  • Both examples don't have much impact on my cpu. I would recommend sticking with the LOS behavior. It runs smoothly on my phone as well.

  • fldr The game runs fine here as well. No high CPU detected. By the way, how did you make the LOS a cross on http://fldr.de/lostest

  • its also in the capx above, its everything that is disabled in the event sheet but beware that this isnt a full line of sight, it only checks to four directions. And trust me, both solutions arent good for use, they will make your phone hot and youre battery empty if you use them in a game context where it doesnt only have to check this for one sprite.

  • its also in the capx above, its everything that is disabled in the event sheet but beware that this isnt a full line of sight, it only checks to four directions. And trust me, both solutions arent good for use, they will make your phone hot and youre battery empty if you use them in a game context where it doesnt only have to check this for one sprite.

    I see. Thanks for the heads up.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)