Grid Pathfinding

AnD4D

Even that it sounds like you looking for something very specific and I'm sure that this is not what you want I couldn't resist to try it

https://www.dropbox.com/s/pgvuvd0ijtwy1tp/SpaceShip%20PathFinder2.capx?dl=0

To avoid the collisions checks you can use MoveTo >>>On Hit Target >>Pick Nearest selected Tile >> set selected to False and so on

And on this two Places, I'm not sure if you needed to move on diagonals or to avoid those Grey pictures so I add one Blue square Tile on each to stop the diagonals, you can remove them if you don't need them

This is With the MoveTo Behaviour

https://www.dropbox.com/s/ou6o7jppmwk1vua/SpaceShip%20PathFinder%28MoveTo%29%20Behaivor.capx?dl=0

Wow! Amazingly, I had just finished doing something similar. Mine doesn't use line of sight, nor 'nearest', but rather it will create sprites on the pathfinding node and will move toward the lowest node.

It's pretty much perfect for what I need.

Now I just need to figure out how to set the destination to a grid, rather than the mouse X & Y. If I recall correctly, it's something like: X % 2) * 32... but I honestly don't remember. Will need to search around again.

> AnD4D

>

> Even that it sounds like you looking for something very specific and I'm sure that this is not what you want I couldn't resist to try it

>

> https://www.dropbox.com/s/pgvuvd0ijtwy1tp/SpaceShip%20PathFinder2.capx?dl=0

>

> To avoid the collisions checks you can use MoveTo >>>On Hit Target >>Pick Nearest selected Tile >> set selected to False and so on

>

> And on this two Places, I'm not sure if you needed to move on diagonals or to avoid those Grey pictures so I add one Blue square Tile on each to stop the diagonals, you can remove them if you don't need them

>

>

>

> This is With the MoveTo Behaviour

> https://www.dropbox.com/s/ou6o7jppmwk1vua/SpaceShip%20PathFinder%28MoveTo%29%20Behaivor.capx?dl=0

>

Wow! Amazingly, I had just finished doing something similar. Mine doesn't use line of sight, nor 'nearest', but rather it will create sprites on the pathfinding node and will move toward the lowest node.

It's pretty much perfect for what I need.

Now I just need to figure out how to set the destination to a grid, rather than the mouse X & Y. If I recall correctly, it's something like: X % 2) * 32... but I honestly don't remember. Will need to search around again.

It sounds very similar to the other one that I was doing without (Tiles, Line of sight)

https://www.dropbox.com/s/v7jborvkpax1dra/SpaceShip%20PathFinder4%20TileMaps.capx?dl=0

Glad you found the Solution

Now I just need to figure out how to set the destination to a grid, rather than the mouse X & Y. If I recall correctly, it's something like: X % 2) * 32... but I honestly don't remember. Will need to search around again.

Use TileMap expressions: SnapX, SnapY, PositionToTileX, PositionToTileY, TileToPositionX, TileToPositionY

>

> Now I just need to figure out how to set the destination to a grid, rather than the mouse X & Y. If I recall correctly, it's something like: X % 2) * 32... but I honestly don't remember. Will need to search around again.

>

Use TileMap expressions: SnapX, SnapY, PositionToTileX, PositionToTileY, TileToPositionX, TileToPositionY

It's likely I won't be using tilemap anymore, so it won't be as easy as snap. I want to be able to create the walls at runtime, so the layout can be different, and the walls are automatically placed. It'll mean combining either normal sprites or tiled backgrounds with tilemap offset.

It'll be tricky. I think I'll be able to save the positions of said items in an array so that multiple ships could be called on demand.

I like to do things tough at the start so it'll be easier later on.

Just in case anyone stumbles across this, the place on grid code is:

Create object

x=round(Mouse.X/64)*64

y=round(Mouse.Y/64)*64

This should make it easier to produce a level editor. Manually placing walls and doors.

*UPDATE*

Having tested this, the above code is perfect for placing a sprite in the centre of a grid, but it's not superb for placing objects on the edges of the grid. Simply altering the code to:

(round(Mouse.X/64)*64)-32

puts the sprites in the correct location, but the mouse cursor is very much to the side of where you expect it to be. Of course, you can change the code so that instead of 64 it reads at 32, but that allows you to place walls in the middle of tiles as well as the edges. Very frustrating.

Why not

X=int(mouse.x/64)*64

Y=...

It's likely I won't be using tilemap anymore, so it won't be as easy as snap. I want to be able to create the walls at runtime, so the layout can be different, and the walls are automatically placed. It'll mean combining either normal sprites or tiled backgrounds with tilemap offset.

I would still use a Tilemap (or several). You can make them invisible and put sprites over the tiles. Use tilemaps as solid obstacles for other behaviors, for collision detection, pathfinding, LoS etc. You can create different tilemap layouts and load them from JSON string for each ship. Tilemap basically works as an array, so it will make many things easier.

Why not

X=int(mouse.x/64)*64

Y=...

I usually use int, but didn't think it would matter in this case. Wouldn't it still create an issue when trying to shift the snap position to either the left or right? Say I want to place a 64x64 tile, then surround it with walls, I still ideally want to work with a 64x64 snap, but shifted 32px so that I'm now working on the edges?

> It's likely I won't be using tilemap anymore, so it won't be as easy as snap. I want to be able to create the walls at runtime, so the layout can be different, and the walls are automatically placed. It'll mean combining either normal sprites or tiled backgrounds with tilemap offset.

>

I would still use a Tilemap (or several). You can make them invisible and put sprites over the tiles. Use tilemaps as solid obstacles for other behaviors, for collision detection, pathfinding, LoS etc. You can create different tilemap layouts and load them from JSON string for each ship. Tilemap basically works as an array, so it will make many things easier.

Tilemap would work quite well, but while trying to do it, I found that corridors require 2 collision polygons, as the square pixel is open on 2 sides, while closed on the other 2.

Tilemap would allow me to store the positions quickly, but I would then likely have similar issues with doors. If I build it using sprites instead, then store the positions and have the system rebuild it from an array, I can edit the tilemap quickly without issues. Say I suddenly want a different floor colour, or my doors to change. Rather than changing the tilemap, I could just change the frame on the individual sprites. Also, FTL tracks oxygen, so giving each sprite a variable also allows me to make this easier.

dop2000 At the moment, my walls are 2/3 times larger than FTL's, and either the objects struggle to get through, or they phase through the walls. The pathfinding plugins seemingly don't have an issue with corner cutting either, which is really annoying.

AnD4D as mOOnpunk mentioned, use Rex's Edges as a starting point. But when you do, there is a bit of an issue regarding diagonal movement and edges. Edges only cover the 4 'cardinal' directions (N, S, W, E) not the diagonal ones (ie corners). I've written some research notes about how to overcome this. These notes are assuming you already now how to use SLG movement and how to set the proper movement cost. Not for the faint of heart <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":-)" title="Smile">

https://c2isogame.wordpress.com/2017/04 ... oss-edges/

Also, another separate issue that you may encounter:

https://c2isogame.wordpress.com/2017/04 ... dge-issue/

If anything is unclear, let me know.

Shame there's not a simple plugin/behaviour this late in C2's lifetime.

By any chance are you using Tiled (the tilemap editor) to do your levels? While that would certainly increase your setup complexity, I find that once you set up your TMX reader in C2, you'll find the Board system quite robust.

I will admit that the Rex's Board plugin is complex, but what I like about it is that it's scaleable and predictable. Once set up, it's easy to apply the behaviour to any number of NPCs.

On other hand, if you are only doing pathfinding on a few characters and your maps are generally small, then perhaps you don't need the 'scalability'.

So i had another pass at my event based pathfinding. It works by the user placing node sprites all over the map in whatever configuration, and then modifying the "pick neighbors" function to pick the connected nodes from any given node. So then you call "astar" with the start and end node uids, and the function returns a comma separated string of the node uids that make up the path. I also added some events to then move along that path, but there may be cleaner ways to handle that.

Anyways here's it with thin walls.

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

And you can also do different kinds of pathfinding by changing up the "pick neighbor" function.

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

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

R0J0hound That's some brilliant code there. I especially like the little bounce. I do, however, note that it's quite a large number of events. I understand you don't like to use plugins, but I use them if it means fewer events. The more events I have, the greater the chance that I make a mistake.

However, I will give it a go, as it looks like it can be integrated quite easily into many projects.

As FTL has a series of different layouts, however, I feel it may be easier to create the levels with a runtime program, and converting the sprite positions and angles.

I therefore created the following: http://bearboxmedia.com/Temp/Clone2.capx

BUT I don't know if I'm looking at a bug, or if there's something I'm doing wrong. When I run a function to convert the positions to an array, it'll do the first set, but not the second. When I disable the first set, the second will be added, so I think everything's correct with the code. I put in a delay in the hope that it'll fix it, as well as create a separate function for the second group, but that's not working either.

I'm also still having problems with the positioning. I don't like the fact that I can place a wall in the middle of a floor. Also, I tried "INT" instead of "ROUND", but that also caused problems.

Honestly, I thought this little exercise would be a lot easier than it is. Genuinely surprised, as it really does appear a lot more simple than it seems to be.

Instead of using "set at (loopindex, 1)", use (array.width-1, 1). The first loop pushes stuff to the end and loopindex ends up being at the end of the array. In the second loop, loopindex is not the end of array. You could also use loopindex+TileFloor.count instead of loopindex in the second loop.

You can offset the grid using this.

grid_position = round((x-offset)/gridsize)*gridsize+offset

For example when the walls are vertical.

x = round((Mouse.X-24)/48)*48+24

y = round((Mouse.Y)/48)*48

Ah, of course. The second loopindex effectively resets the loop back down to zero. Silly mistake to make.

Thank you very much!