Suggestion for new Pathfinding Behaviour

Ashley, if I may be so bold as to make a suggestion for the new Pathfinding behaviour:

Can you add some form of currentAngleOfMotion variable akin to that found in the Bullet behaviour. This was essential to how I animated the characters in my game (I didn't rotate the sprites, but used the current angle of motion to determine if an animation should be mirrored or not). I can't think of another way to reproduce this, so I'd like to suggest its addition to the new behaviour.

Thank you for this fantastic new behaviour, it has made life far easier!

Added to the todo list.

If there was a currentNode expression you could use angle(Sprite.Pathfinding.NodeXAt(currentNode),Sprite.Pathfinding.NodeYAt(currentNode),Sprite.Pathfinding.NodeXAt(currentNode+1),Sprite.Pathfinding.NodeYAt(currentNode+1))

Ashley thank you, I'm extremely grateful :)

newt that's what I was trying to puzzle out last night, just to see if it was there and maybe just hidden, but I couldn't get it working.

Another suggestion - rather than having a single obstacle type that defines intersecting grid cells as non-traversable, would it be possible to define obstacle types with a variable property that added corresponding cost to the edges that crossed those obstacles?

For example, a "wall"-type obstacle would be completely impassable, a "rough terrain"-type obstacle would not be impassable, but any route that crossed a cell containing that obstacle would be given a higher path cost, making it less favourable than a (perhaps longer in distance) route over lower cost terrain.

I think this would be a relatively easy change to addCellToOpenList() where the g score is assigned (currently as var curCellCost = this.at(x_, y_) * 50; - not sure where the 50 comes from?), but don't know if it would make the behaviour more complex for users who don't need that functionality.

On a side note, I see the heuristic used in the estimateH function is dx * 10 + dy * 10;, which, technically, is not admissable for A* because it doesn't guarantee to underestimate the true cost to the target node. Was this chosen to avoid the square root needed to get a true straight line heuristic?

tanoshimi - that's a good idea - also added to the todo list. I've also been thinking about features to separate bunches of objects (someone mentioned flocking) but that's pretty complicated.

Ashley - to facilitate pathfinding+flocking (or other interesting movement behaviours) it would seem to me that the best thing to do would be to decouple the planning part of the pathfinding algorithm from the actual locomotion along the path.

In other words, the acceleration/max speed properties and the "Move along path" action shouldn't really be part of the pathfinding behaviour at all. Instead, the pathfinding routine should concentrate only on finding and returning the best route in a manner that makes it easy to iterate through the list of nodes along the way. Rather than use a simple "Move along path" action, a developer can then choose to implement whatever pathfollowing behaviour they want to negotiate between these nodes in sequence.

The seperation of "planning" from "following" behaviours would make it easier to create entities that followed the route calculated while also moving in a manner that obeyed, say, car physics, flocking, or aspects of platform behaviour.

tanoshimi - it's already separated, the pathfinding happens entirely in grid world then the movement moves smoothly along the grid-aligned nodes that are returned. I have experience with writing separation features from Construct Classic's RTS movement, and it's extremely complicated to pull off in an efficient and realistic way (i.e. objects never drive through each other or wedge too far inside another object). But it's still and interesting problem I want to look at!

Ashley - thankyou for your hard work so far, and it's great to hear you've got lots of ideas for further improvement! I look forward to seeing the progress :)

edit - In fact, I see the nodelist is exposed so it is possible to implement custom movement between the nodes. Primitive example of looping through the waypoints follows:

<img src="http://i46.tinypic.com/21ci0w6.jpg" border="0" />

I would love it added so that objects don't overlap each other too much when pathfinding. I managed the same effect using physics in a test I did a while ago in CC, but that gets pretty processor intensive doing it that way with a lot of units.

I'm using one of the pathfinding plugins, and would like to switch to use one that would allow uploading to the arcade.

But mine allows choosing the fastest route or the stealthiest route, sticking to the trees along the way. So I would have to wait for the value additions.

Mine is isometric, so I copy the screen to a hidden layer as a grid, and run the pathfinding on it. Then the results are followed on the big map.

edit: to clarify how I used the points, grassland had a higher cost than the trees, so on stealth mode, the trees were preferred.

For example, a "wall"-type obstacle would be completely impassable, a "rough terrain"-type obstacle would not be impassable, but any route that crossed a cell containing that obstacle would be given a higher path cost, making it less favourable than a (perhaps longer in distance) route over lower cost terrain.

This is exactly what I came here to suggest.

My second (related) suggestion would be to include logic that forces the path to always intersect a certain type of obstacle, rather than avoid it. For example, so pedestrians must always follow a sidewalk, or a car a road.

i have visions of zombies swimming in my head imagining pathfinding + some way to do a circling behavior.

Wow, thanks for making an "official" pathfinding module. This is a huge help to my current project.

I do have a suggestion for a possible change to the functionality. I'm making an isometric game, so to get the proper illusion of movement on an isometric grid, I need to set the vertical movement rate separate from the horizontal rate.

Would this be something supportable with the pathfinding behavior?

Nice work, everyone, and congrats on the Steam release!

Ashley: R118 has brought some very nice additions to the behavior.

Nevertheless, it brought an unexpected change on one of my project.

It seems that in r117, the behavior did not move in diagonal, which suits fine my project but in r118, it does.

Would it be possible to add a property/action to set if the algorithm should allow/disallow diagonal movement please ?