Tilemaps + Pathfinding grid help

Get help using Construct 2

Post » Fri Jan 06, 2017 6:40 pm

Hello there guys, I wanted to share a issue that me and my team are having with the pathfinding obstacle maps
and a collision tilemap.

The problem

The issue is that we couldn't do a balanced obstacle map in the borders because the wall tiles are in the side of each tile and the obstacle map ends up being imprecise and I don't know how to correctly do the obstacle map in a 16x16 tile resolution.

Besides that when I use the pathfinding Construct 2 code to check the obstacle map it shows that the collision registers 1 tile more than it should even when snapping it to the 16x16 grid, but apparently, it considers one tile more like it was 17x17 and ends up registering the next tile, because if I recall correctly, with only one pixel as an obstacle in the grid, the pathfinding with take the whole place (Grid) as an obstacle.

The tileset of collision. you can see the wall in the side of the tile.
Image

The enemies I have don't follow well the pathfinding, they either go through walls or get stuck if I try to avoid them going through them with solids, and probably it's because of this obstacle map being created incorrectly.

I'm using the code of the example of pathfinding to show the collision map in-game. The red area is the obstacle map.
Image

What we tried

We tried adding a new specific tileset of full square 16x16 for the obstacle collision for the pathfinding but the problem persisted because it has to be 16x16 grid based and the tile of the wall will always be in one side of the tile, the problem persists and we can't find anything precise.

What we want

A correct and balanced collision map in space terms even with the wall being on a side, which was created like this to make a more optimized tileset, comfortable and fluid for the tileset creation, it's not the first game to be done in this way and I'd like to find out how could this be solved.

Maybe something like this without unsnaping the grid:
Image


And here's some information about the tile collision. I have to say that I fixed the extra grid created for the obstacle map just reducing the edges of the colission but that probably will mean that the tilemap will do no optimization
for collisions, anyway, I'm not quite sure.
Image

Hope anybody can help me and thanks in advance guys.
B
9
S
2
G
2
Posts: 21
Reputation: 1,567

Post » Sat Jan 07, 2017 12:59 pm

What cell border have you determined in the Pathfinding behaviour's properties? It is "-1" by default - I'm not sure what this actually means, but could be related to your issue. Post a screenie of your Pathfinding properties if you can, it might help :)
The LEVEL GENERATOR TOOLKIT



24 functions dedicated to producing randomly generated terrain for all kinds of games.
B
25
S
7
Posts: 242
Reputation: 2,306

Post » Sat Jan 07, 2017 1:39 pm

Hello there, here's the properties! I tried many numbers but I'm not getting a solid solution bro.

Since everything is 16x16, I've been trying the cell size of 16.
Image

the cell border means how many cells do you want additional for the obstacle map, and -1 means that it will take 1 cell less of the map!
B
9
S
2
G
2
Posts: 21
Reputation: 1,567

Post » Sat Jan 07, 2017 1:55 pm

well, the additional cell is deleted when I use cell size 16 and cell border -1, but the results keeps giving me an unwanted obstacle map u.u help.

you can see that the walls only has one side of collision.
Image
B
9
S
2
G
2
Posts: 21
Reputation: 1,567

Post » Sat Jan 07, 2017 9:18 pm

Do you understand the strict relation between cell size & grid when showed this way ?

https://www.dropbox.com/s/486uuo5bd3j9j ... .capx?dl=0
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Post » Sat Jan 07, 2017 11:08 pm

Hello 99 and thank you for your response, so, the solution is doing the tilemap of the obstacles half size of the tileset of the level? so being 16 the prop tileset the collision would be 8, isn't that not optimal?
B
9
S
2
G
2
Posts: 21
Reputation: 1,567

Post » Sat Jan 07, 2017 11:12 pm

My guys also keep getting stuck in the walls if I don't use some kind of solid behaviour on then.

and If I use it either way they get stuck, check this out (using the obstacle cellmap of 8.)
Image
https://fotos.subefotos.com/61a2fe4c7f6 ... 77463o.png
the orange line should be their path and the red line is what they do.
B
9
S
2
G
2
Posts: 21
Reputation: 1,567

Post » Sat Jan 07, 2017 11:55 pm

oultrox1995 wrote:Hello 99 and thank you for your response, so, the solution is doing the tilemap of the obstacles half size of the tileset of the level? so being 16 the prop tileset the collision would be 8, isn't that not optimal?


Definitions:
'solids' = well solid, if you have obstacles in the pathfinding set to solids
'solids tilemap' = iffen you use a tilemap to represent the solids as obstacles
'obstacle cells' = 2 dimensional array used internal by pathfinding to store a value to represent an obstacle or a free place, based on the solids
'obstacle tilemap' = a tile map i use to represent the 'obstacle cells' in a visual way

Answer to the question:
If you gonna use half tiles in the 'solids tilemap', then the pathfinder cell size should be half the tile size (in the 'solids tilemap') . With a cell border of -1.
If you want to make the 'obstacle cells' visible, us a 'obstacle tilemap' with tile size = cell size.
The relation between cell size and tile size is strict.

The 'obstacle cells' are ready the NEXT tick.
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Post » Sun Jan 08, 2017 12:29 am

Thank you for the definitions, I got them once I checked the file!

but, would'nt that be CPU intense? 8 size... and did you saw the image? I don't know why they're not following the path correctly.
B
9
S
2
G
2
Posts: 21
Reputation: 1,567

Post » Sun Jan 08, 2017 9:06 am

Definitions are just between you and me, so we both know what we talk about. Else i make a big mess of it all.

Yes a cell size of 8 and a -1 border, with a big tilemap, is CPU intense.
You do realise that this is a new question eh ? The thing is, you wanted obstacle cells that exactly represent your solids tilemap. You dont want unwanted cells marked as obstacles. I think i answered that question for you.

Personally, i dont see any use in this. Because, see. The origin of an object moves over the found path, the pathfinder is totally dumb about the size of that object. Since it only keeps the origin on path, it will drive objects into the solids. The origin will always keep out the solids, ofcours.

Now there are many kinda-sorta solutions on the forum to deal with badly calculated paths due badly set cell-size and border-size. Me myself has tried and experimented a lot. And the only thing that helped me out, is to calculate good paths.

A good path is a path that stays half the size of the objects away from the solids. Or. The collisions cells have cells marked as obstacle around the solids. The opposite of what you wanted.

Or in you case: cell size = tile size of the tilemap holding the solids. Border size = half the size of the moving sprite , and to be experimented. (no other choice) Check the cells by making the cells visible in a obstacle tilemap. If it does not find a path, you need to change the solids.

Again, if you look at my 'blah example', did you see that you have to WAIT 1 tick. The obstacle cells are READY the NEXT tick. Even when starting up the game.

Additional. There is a difference between the graphical representation of a wall and the way/form/whatever it should act as an obstacle. You better have 1 tilemap for graphical representation and 1 tilemap + solid sprites (all invisible) to mark obstacles. Because, see, someone/thing got to do all the work, YOU or the players (victims) PC.

I am not harsh, i just type that way in bad english.
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Next

Return to How do I....?

Who is online

Users browsing this forum: brunopalermo, dop2000, jorgmaquoi, kiki4construct and 34 guests