I already have code that finds the closest point on a Path2D so that my bee can land there and start walking along the line. I think I want to use a PathFollow2D so I can figure out the rotation and to figure out the direction of the path, say, 10px back and 10px forward. I can use those to determine whether the player controls should be interpreted as going forward or backward.
Let me draw a picture.
Red is the player direction, green is the forward path, blue is the backward path.
On a relatively flat surface the player direction is fine for determining which way the path goes but that falls apart when the player is in a corner or on a tight curve. I don’t want the player to have to go all the way into the corner—like, right in there—before they can choose which way to go.
For example, in the right diagram, if the bee is just before the corner then the player direction will be straight to the right. If the controller direction is straight up then the player isn’t gonna move or there’s a 50-50 chance it could go left or right. I think what the player would expect is to continue moving to the right a little bit until it reaches the corner then go up.
Maybe I’m wrong and only testing it out will tell me but I think the player is looking slightly ahead to where they want to go and directing the controller there. Not directing it into the corner first, then to where they want to go, especially since that corner is going to be hidden from them.
Right now I have code that finds the closest point on a path but I’ll want to use PathFollow2D and it has a h_offset and v_offset… does that mean I can just set the PathFollow2D’s position and then ask it for the progress or progress ratio? That finds the closest point? Would be a little surprising… a little indirect but…
…
Okay, a bunch of progress.
First of all, h_offset and v_offset are not what I thought. They just offset the position of the follower from the path by a fixed amount. It’s basically like translating the path by that amount but instead the follower is translated.
Instead, Path2D has a curve property, a Curve2D, which I can call a couple useful methods on: get_closest_point() I already used for landing on the path. But since I’m working with a PathFollower2D that means get_closest_offset() is much more useful. I get that offset value then set the follower’s progress property to that value. Then the follower will have the desired position and rotation. I can use those values to update the player, using rotate_toward() to make the rotation a little smoother while I’m at it.
Changing the direction that the sprite is facing can no longer rely on a simple check for whether the controller direction’s x-component is positive or negative. I need to compare the controller direction to the angle of the player, the angle imposed by the path. That works pretty well, actually.
The problem I get now is in the corners. When the controller direction points in the same direction as the corner, the bee stutters back and forth in a sort of superposition of going forwards and backwards. It does make sense… the bee is trying to move into the corner but the algorithm advances it a specific distance along the path. That advances the bee past the corner slightly so now it needs to turn backwards to go towards the corner. That advances it past the corner again and now the corner is in the forwards direction.
So what do I do?
I tried doing the normal cartesian movement and then after the fact, force the bee back to the nearest point on the path. That does work, no more superposition bee in the corner. It just goes as far as it can into the corner and stays there.
Problem is parts of the path feel super janky. If your controller is not pointing in the correct direction then movement along the path grinds to a halt.
…
Rounding the corners of the path seems to have helped a bit. I might be getting too used to using this now. Fresh eyes or even better, some unwitting user testing might be in order. Not sure if this is really janky and unacceptable or if it’s maybe actually okay.
It is pretty exciting to see the interaction I imagined take shape in Godot, though. Like, this is super debug art yuck but I’m grinning watching this bee crawl into the flower.
Except, it doesn’t actually disappear into the flower yet but still.
Exciting progress.
So the big takeaway today I think is that forcing the bee to the nearest point on the path is better than using the controller direction to explicitly advance the bee along the path.
I wonder if a blend of both might..?