Sequential Grid-Based Movement

This is an extension of Tile Movement, except instead of moving one-by-one based on player input, the idea is that there is a single player input (the destination) and that the object needs to move there in a grid-based fashion (one space at a time).

Take for example this image:

<img src="http://i.imgur.com/MmZdqCJ.png" border="0">

Every bright tile is one that the object can move to. Suppose the player clicks the bright tile at the far right (3 spaces to the right of the purple object). The idea is for the purple object to move to the clicked tile, one tile at a time until it gets there.

Does anyone have a good idea on how to accomplish what I'm trying to do?

BoardGame.capx

Currently I have a pathfinding object that will move from the selected object to the destination tile, 'tagging' tiles that it overlaps on the way there. Once it reaches its destination, the object will then move one space at a time through the tagged tiles until it reaches the destination.

However, my pathfinding object never reaches its destination:

<img src="http://i.imgur.com/s4OyVpq.png" border="0">

Anyone know why?

I'm able to get the moveFinder to arrive to the destination now.

<img src="http://i.imgur.com/yieNyQb.png" border="0" />

I've checked in the debugger, and the tiles the moveFinder passes through on its way to the destination definitely are getting 'tagged'. Now it's just a matter of figuring out why the program never moves:

<img src="http://i.imgur.com/ZMu13BJ.png" border="0" />

Another issue I encountered during testing - obstacles aren't being set up properly.

<img src="http://i.imgur.com/55KZo3t.png" border="0" />

The pathfinding object goes through a space that is not allowed.

<img src="http://i.imgur.com/9qe7swq.png" border="0" />

Not sure why this is. Are invisible objects capable of being obstacles?

Here is one way to do it:

Boardgame movement

I used pathfinding and moveTo plugin (you'll need to get it to check this out).

Edit: Fixed the example a bit

Created a tutorial based on this .capx, explaining things a bit more. Check it out! :)

vee41 <img src="smileys/smiley31.gif" border="0" align="middle" />

You are my hero :)

vee41

Is there a way to make the object pause at every square? So instead of gliding to the destination, it makes a slight pause at every square.

I assume this means that every square on the way to the final destination will need a marker, and that the object will need to pause for a second each time a marker is destroyed.

Also, I'm having programs move off the grid for some odd reason, along with multiple marker points being generated in some strange spots.

<img src="http://i.imgur.com/9OAqLJr.png" border="0" />

I'm noting this topic, do you feel it has pac-man clone potential?

For a pac-man clone, basic pathfinding with walls as solids should work.

This is more or less an intermediate to advanced application, since each object has to account for other objects being in the way.

Few ways you could approach that:

1) Think I did breadth first search in similar situation one time. It replaces the standard pathfinding (which did not exist when I did this). The general idea would be:

• Create an array where each square has a value
• Give the start square value zero, and call a function that checks if squares next to it can be moved. The function gives those squares value one in the array, and calls itself for surrounding squares. Those squares are given value two, and they call surrounding squares etc.
• When the function hits the square we want to travel into, it stops executing.
• Now, we check the 'route' in the array we have built this way. From the square we want to travel to, we trace our steps back to the square one using the route of descending numbers. This is the shortest route.
• We generate the go to markers to each of those squares.

2) Stop the movement at center of each square for a second whenever arriving in new square. This is probably the easier way. :)

3) You could make the moving object pause always after certain distance traveled. This distance would coincidentally be the same as distance between two squares.

You could also use an older Pathfinding Plugin.

I couldn't upgrade my turn based grid game to the new pathfinding because I store every step of the path in an array. The new one only shows nodes at the turns. (still working in my game in r141.)

00Rez's plugin may do what you need.

http://www.scirra.com/forum/plugin-fast-path-finding-preview_topic50820_page1.html

vee41,

Can you explain in more detail what happens in the loop? Specifically, the For loop that goes through pathfinding nodes.

I'm having some weird marker placements but my code is almost exactly the same as in your example.

I haven't opened the capx but you should be able to get it to work without any path finding at all. I mean when you highlight all the possible moves for a piece you already have a number for how many spaces away it is from the piece.

So if you select a spot four spaces away you can select a spot three spaces away next to that. The process can be repeated to find all the grid positions in the path. So you end up with a list of positions that you could move to in sequence with the move to behavior.

At least that's a thought. I don't have access to c2 ATM to implement it.

R0J0hound, removing pathfinding would greatly ease up on CPU demands. I like this idea.

I'm actually probably going to scrap this overall thread idea and have the player only be able to select a square next to the currently selected object. This prevents suboptimal pathing when there are 2 or more ways to get to a certain square. It also gives the player full control of his objects.

Had a tinker with the idea and it does end up with an optimal move path. I also tested out some ideas i had for implementing turned based mechanics. It may have some use to give someone some ideas...

https://dl.dropboxusercontent.com/u/5426011/examples18/turn_based.capx

r139, 43 events

I agree moving your units one space at a time would give the player more control and could be a better control mechanic.