Tilemaps + Pathfinding grid help

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.

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.

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:

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.

Hope anybody can help me and thanks in advance guys.

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

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.

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!

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.

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

https://www.dropbox.com/s/486uuo5bd3j9j ... .capx?dl=0

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?

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.)

https://fotos.subefotos.com/61a2fe4c7f6 ... 77463o.png

the orange line should be their path and the red line is what they do.

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.

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.

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.

Alright 99, to be honest, you helped me a lot, but at the end, I do not want some perfect map collision of obstacles, just what you said, that they follow the path correctly.

I'll try this: "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."

And i'll look around on the forum to see tips for making the pathfinder correctly.

I do have event sheet where I can see myself the collision cells! but yours is interesting too.

How do you get half of the sized of the object for cell border in order to follow the path, If I even put 0 border, they will not follow properly.

edit: Heya, I made a .capx for you to visualize more deeply my problem with 16x16 tilesets and the cell size of 16.

8 size is too small for the job, and it won't be optimal.

check it out if you want please!

https://www.dropbox.com/s/ywset1901frys ... .capx?dl=0

Press 'M' to show the collision map cells.

I did't realise that you grid is this tight.

Got to loosen the grid some, and then path finding with the official plug in is possible.

https://www.dropbox.com/s/1gxmepuzkvsv9 ... .capx?dl=0

To my knowledge, however, it is not possible to force it to find a path each short period of time, in such a tight grid. The curvy paths will force the moving object into as obstacles marked cells. And from there it will not be able to find a new path.

You going to have more luck with:

roguelike-plugin-c2-rot-js-interface_t118452

or

behavior-easystar-js-pathfinding-for-tilemap_t129056

Thanks, so, you're telling ME that I can't official plugin pathfinding in a 16 size tilemap? that's HELLA weird!

Really there's no way to do it? every short periods -> Follow the player?

what If I increase the cell size even if my tilemap is 16x16?

I'm really trying to avoid using third party plugin of this kind. pathfinding is something really important in the game right now. :/

Ashley could you help me on this? Maybe I'm doing something wrong in order to use the pathfinding plugin!

The 'curves' depend on the 'turn speed'. But they will stay a bit 'absolute'.

You can of-course code your own Dijkstra algorithm, or use a flood fill.

But in the end, that is what the plugins do, but optimised.

You can try (i never tried that) use a like 100 pixels grid. And scale the layer. Its easyer for a path to make a turn round a 100 pixel corner then round a 8 pixel corner, thats what you do.

I am always this stupid to dive into this things, but i got this urge to tell YOU about things YOU ask.