Suggestion for new Pathfinding Behaviour

Discussion and feedback on Construct 2

Post » Wed Jan 30, 2013 8:32 pm

@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!
slap it onto the flappy bird template...
bang it on google play with all the other shovelware...
sorted...
B
36
S
7
G
4
Posts: 322
Reputation: 8,170

Post » Thu Jan 31, 2013 12:57 am

Added to the todo list.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Thu Jan 31, 2013 8:36 am

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))
Image Image
B
161
S
48
G
90
Posts: 7,356
Reputation: 66,767

Post » Thu Jan 31, 2013 9:33 am

@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.
slap it onto the flappy bird template...
bang it on google play with all the other shovelware...
sorted...
B
36
S
7
G
4
Posts: 322
Reputation: 8,170

Post » Thu Jan 31, 2013 1:23 pm

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?
B
8
S
2
G
3
Posts: 83
Reputation: 2,668

Post » Thu Jan 31, 2013 2:18 pm

@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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Thu Jan 31, 2013 4:11 pm

@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.
B
8
S
2
G
3
Posts: 83
Reputation: 2,668

Post » Thu Jan 31, 2013 4:33 pm

@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!
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Thu Jan 31, 2013 5:43 pm

@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:
tanoshimi2013-01-31 18:37:11
B
8
S
2
G
3
Posts: 83
Reputation: 2,668

Post » Thu Jan 31, 2013 7:52 pm

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.Arima2013-01-31 19:52:52
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Next

Return to Construct 2 General

Who is online

Users browsing this forum: gamecorpstudio, WhosWho and 10 guests