Animate player sprite movement with pathfinding

I am trying to use the pathfinding behavior, and am having problems trying to get the player sprite animation working. I think it is fairly simple, I'm just ignorant of how to get it to work.

Here is the capx I've been working on: dl.dropbox.com/u/38038537/TestPathfinding.capx

Here are the steps I think should happen:

1. Initialize pathfinding

2. Generate pathfinding based on a mouse click

3. Move player sprite to target location along path

If you have reference to a demo I've missed, or can just tell me what I am doing wrong, I would greatly appreciate it.

Please let me know if you need any more information.

Thanks!

There isn't yet a reference to how to move a sprite accordingly to a path because, truth to be told, I haven't yet implemented it in a way I'm satisfied with.

Anyway, you have the correct logic idea. The "flaw" in your capx is that you make all the movements through the path in a single tick (as you are using a "Repeat loop").

So far, I've followed the same idea, just letting the movement itself handled by an 8direction behavior.

I simulate right, left, up or down arrows pressure by checking the actual distance between the sprite and the PathFinder.getCtXPathList (and getCtYPathList).

Pseudo-code:

If Sprite is on right of NextCellInPathList => Simulate left key.

If Sprite is on left of NextCellInPathList => Simulate right key.

Etc...

As I said, I yet have to implement a satisfying way of incrementing (in your case) indexPath when the sprite is rightly positionned on the next cell of the pathlist.

Instead of going through emulation of the 8dir behavior, you might as well calculate yourself the distance and angle to go (through system math expressions) and apply some bullet behavior, or even move it in events each tick.

That's the tricky part where I don't have a releasable solution yet. Let me know if you can come up with something.

It seems to me that you would want to keep the path-finding and movement behaviors separate. You would use the path-finding behavior to generate a path list, then use a movement behavior to execute the path list.

Looking at the bullet behavior, for instance, behind the scenes, it is generating its own linear path, then following that path every tick.

What we would need is a modified movement behavior which could accept a path list as a parameter. That path list could be from any source, whether it be from the path-finding behavior, or a more linear function.

I am working on building something using events, and i will post the capx once I have something working. Iam still trying to wrap my head around the JavaScript SDK and building plug-ins, so I will have to do it the hard way for now.

Automated Movement.capx

I just found again this example of an automated movement I had made.

It could be quite quick to adapt it so that target is the NextCell position and that it gets automaticly updated.

I don't want to include automated movement within the pathfinder as the movement the user wants will depend from a project to another. The pathfinder provides a path, it's up to the user to walk it the way he like best. (consider people wanting grid movement, those who will want a smooth rotating-like vehicle movement, those who will want something more floating, etc...

Hard to make everybody happy with a single automated behavior)

I will check out the capx when I get home.

I totally agree that the path finding and movement should be completely separate behaviors. I'm trying to come up with a movement pseudo-behavior (i.e. all event driven) that will accept an array of positions, but I think I have a basic mis-undertstanding about how the event sheet is processed.

Made Path Array to store points whenever you click. The textbox shows you the first 4 points, but you can have as many as you want.... couldn't get sprite to follow them though.

https://www.dropbox.com/s/wla75aaygef4dht/PathStuff.capx

ScottP: The link isn't working for me.

Sorry! It's my first time sharing from Dropbox. Let's try again...

http://db.tt/5Z4p9vww

ScottP: thanks for the example

I was finally able to find time to work on the mouse-click movement using Kyatric's path-finding plug-in.

Here is the example capx:

http://dl.dropbox.com/u/38038537/TestPathfinding-00.capx

There are still some issues I need to resolve:

• I need to refine the setting of the player sprite angle towards the target.
• I need to refine the final movements of the player sprite to the target. The final position of the sprite always seem to be a bit off of the actual target coordinates.
• It appears that when setting the path-finding obstacle, it only recognizes the final obstacle set in the event sheet. I think I may not be setting the obstacle list correctly. In the example, you can see that the only obstacle recognized is the horizontal wall. The player sprite will walk right through the vertical wall and the column obstacles.

Overall, it seems to work pretty well. I am open to any suggestions for making it more elegant or precise.

Also, I am still getting up to speed on JavaScript and the SDK, but I am wondering if this type of movement using a path list would translate well to a plug-in, or if it is better handled through events.

Thanks!

There are still some issues I need to resolve:

- I need to refine the setting of the player sprite angle towards the target.

- I need to refine the final movements of the player sprite to the target. The final position of the sprite always seem to be a bit off of the actual target coordinates.

This is because the pathfinding is made as a grid like in the example with S and D. When you drop the Destination icon wherever on a cell, it is automaticly repositionned to its center. That's because the center of the cell IS the target, its X and Y position, its center.

The pathfinder will locate the X and Y of the target object and will check in what cell this position actually is (so if your target object is put in between 4 cells at the same time, having bits of it being present in 4 cells, only the cell which contains the actual X and Y coordinates of the object will be set as destination of the pathfinder.)

Same principle goes for the Source object. It's X and Y defines the starting cell.

I may be unclear, I'll document it more in the next version of the pathfinder.

- It appears that when setting the path-finding obstacle, it only recognizes the final obstacle set in the event sheet. I think I may not be setting the obstacle list correctly. In the example, you can see that the only obstacle recognized is the horizontal wall. The player sprite will walk right through the vertical wall and the column obstacles.

This is possibly a bug in the behavior. I was thinking about it lately, did not run any test, I'll look more into it.

A workaround that could work for now would be to have a single object "Wall", set as obstacle.

Its animation would contain different frames, holding the several textures (WallHorz, WallVert and WallColumn).

On startup you assign the right frame to the object (you might "mark" the instances with an instance variable and display the correct frame for the setted value on start of layout).

Also be sure to keep consistency in the size of the objects. Your player is 80 pixel of height, be sure that your obstacles are also 80X80px.

For the obstacle, it's not taking only the X,Y position into account, but the bounding box.

Meaning that on the path calculation, if any bit of the bounding box of the obstacle is colliding/overlapsing a cell, the cell will be marked as unwalkable.

I'll document on that too.

If you don't mind, I'll use this example of yours (and work on it for tests and improvements) for the future releases of the behavior.

I'll also try to give the option to choose between bounding box collision and polygon collision mask, even if it won't change a lot of things. The slightest bit of obstacle being on a cell will still mark the full cell as unwalkable.

Overall, it seems to work pretty well. I am open to any suggestions for making it more elegant or precise.

Also, I am still getting up to speed on JavaScript and the SDK, but I am wondering if this type of movement using a path list would translate well to a plug-in, or if it is better handled through events.

Thanks!

Having an automated movement, moving the sprite from grid cells to grid cells might be handy as a behavior. Associating both the PF and this should give a "fully" fonctionnal automated PF behavior in the end.

I had sources at a time that were a first implementation of this, but it got lost somewhere in my backups.

I'll check on those too, but I will focus first on the PF as we obviously can handle/workaround the movement via events for now as demonstrated through this topic.

Thanks for the working on the behavior.

This is because the pathfinding is made as a grid like in the example with S and D. When you drop the Destination icon wherever on a cell, it is automaticly repositionned to its center. That's because the center of the cell IS the target, its X and Y position, its center.

The pathfinder will locate the X and Y of the target object and will check in what cell this position actually is (so if your target object is put in between 4 cells at the same time, having bits of it being present in 4 cells, only the cell which contains the actual X and Y coordinates of the object will be set as destination of the pathfinder.)

Same principle goes for the Source object. It's X and Y defines the starting cell.

I may be unclear, I'll document it more in the next version of the pathfinder.

No, that makes perfect sense. I will work on modifying the events so that the correct coordinates get assigned. I think that will take care of things being slightly off.

A workaround that could work for now would be to have a single object "Wall", set as obstacle.

Its animation would contain different frames, holding the several textures (WallHorz, WallVert and WallColumn).

On startup you assign the right frame to the object (you might "mark" the instances with an instance variable and display the correct frame for the setted value on start of layout).

I will give this a try.

Also be sure to keep consistency in the size of the objects. Your player is 80 pixel of height, be sure that your obstacles are also 80X80px.

For the obstacle, it's not taking only the X,Y position into account, but the bounding box.

Meaning that on the path calculation, if any bit of the bounding box of the obstacle is colliding/overlapsing a cell, the cell will be marked as unwalkable. I'll document on that too.

I will re-size the sprites. I thought earlier that this might cause an issue, but then forgot to go back and change them.

If you don't mind, I'll use this example of yours (and work on it for tests and improvements) for the future releases of the behavior.

Thanks for the working on the behavior.

Of course I don't mind. Thank YOU for working on the path-finding!

I fixed a few issues from before. Here is the latest capx:

http://dl.dropbox.com/u/38038537/TestPathfinding-01.capx

Fixed issues include:

• Precision of the movement to the final destination coordinates was fixed by adding an event that replaces the final coordinates in the path list with the original mouse-click x,y coordinates.
• Added a check for the initial movement in the path to see if the distance between the player sprite at the second path coordinate was less than the distance between the first and second coordinates. This fixed an issue where if the first set of coordinates were in the wrong direction (i.e. farther from the second set of coordinates than the player sprite), the sprite would turn and move to the first set, then move to the second set. If this situation occurs, the first set is just skipped.
• Worked around the obstacle issue (where is would only recognize the last obstacle set in the events) by only creating one obstacle sprite, then creating an obstacle layer, and setting it to invisible. This way, the obstacle matrix can be designed on one layer, and the environment objects can be designed on a different layer, using the obstacle layer as a reference. I tried using one sprite with animation, but I failed, and this solution seems cleaner.

There still seems to be an issue when a path is generated using cut-corner, the player sprite will still bleed over into to environment (i.e. the walls).

I also added a check to the mouse-click events to make sure the player can't click on an obstacle grid square. If they do, the player sprite will ignore the obstacle and move into the square. If you disable the condition in the Controls group, and them click on a wall, you can see the issue.

Thanks!

Kyatric

Do you have an ETA on the human readable example capx as a suggestion on how to implement a movement method? The one on this thread isn't for a grid based game and it's hard to follow what to do opening your and Wastrel's example side by side, trying to combine the ideas without some kind of grid-based example.

Yann had a very sweet capx in a few events I saw on IRC, maybe he could consider reproducting it/posting it.

Else I'll take a look at this later and try to provide a capx.

Finaly, it took less time than expected.

Check the first post of the PathFinder Behavior topic to download the update for the PathFinder behavior that fixes discovered bugs and check the example of how to move objects with the pathfinder behavior in a few events.

Proposed motion smooth and stepped.