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.