Animate player sprite movement with pathfinding

Get help using Construct 2

Post » Wed Oct 12, 2011 4:06 pm

[QUOTE=Wastrel]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.
[/quote]
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.

[QUOTE=Wastrel]- 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.[/quote]
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.

[QUOTE=Wastrel]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![/QUOTE]

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.Kyatric2011-10-12 16:07:27
New to Construct ? Where to start

Image Image
Image Image

Please attach a capx to any help request or bug report !
Moderator
B
247
S
85
G
40
Posts: 6,998
Reputation: 57,791

Post » Wed Oct 12, 2011 4:41 pm

[QUOTE=Kyatric]
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.
[/QUOTE]
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.
[QUOTE=Kyatric]
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).
[/QUOTE]
I will give this a try.
[QUOTE=Kyatric]
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.
[/QUOTE]
I will re-size the sprites. I thought earlier that this might cause an issue, but then forgot to go back and change them.
[QUOTE=Kyatric]
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.
[/QUOTE]
Of course I don't mind. Thank YOU for working on the path-finding!

Wastrel2011-10-12 16:42:36
Don't see the fnords and they won't eat you!
B
75
S
16
G
12
Posts: 322
Reputation: 11,608

Post » Thu Oct 13, 2011 10:52 pm

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!
Don't see the fnords and they won't eat you!
B
75
S
16
G
12
Posts: 322
Reputation: 11,608

Post » Mon Jan 09, 2012 7:13 pm

@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.
B
47
S
3
G
5
Posts: 56
Reputation: 4,630

Post » Mon Jan 09, 2012 8:20 pm

@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.
New to Construct ? Where to start

Image Image
Image Image

Please attach a capx to any help request or bug report !
Moderator
B
247
S
85
G
40
Posts: 6,998
Reputation: 57,791

Post » Mon Jan 09, 2012 9:48 pm

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.Kyatric2012-01-09 21:49:03
New to Construct ? Where to start

Image Image
Image Image

Please attach a capx to any help request or bug report !
Moderator
B
247
S
85
G
40
Posts: 6,998
Reputation: 57,791

Post » Mon Jan 09, 2012 10:00 pm

Amazing, I wasn't expecting it to happen right away you know :) Thanks a lot. Now that I'm looking at the .capx I'm thinking it's no wonder I couldn't figure it out on my own :) Smooth movement logic part is begging to be turned into some kind of plugin. Maybe one day. Also big thanks to Yann. :)
B
47
S
3
G
5
Posts: 56
Reputation: 4,630

Post » Mon Jan 09, 2012 10:37 pm

@Wronghands
lerping is fairly easy once you get the hang of it (don't be impressed by the size of the expression... size doesn matter you know :D)
B
60
S
22
G
14
Posts: 1,479
Reputation: 16,346

Post » Thu May 19, 2016 3:52 pm

Could you guys tell me how do you did this? The capx link doesn't work,if you have can you upload it again?
B
12
S
5
G
1
Posts: 70
Reputation: 1,540

Previous

Return to How do I....?

Who is online

Users browsing this forum: Radulepy, Yahoo [Bot] and 7 guests