mastodon.gamedev.place is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon server focused on game development and related topics.

Server stats:

5.1K
active users

@toerror @runevision it might work but I had problems with this sort of approach when players were moving / turning quickly (it yanks the interpolation too hard and looks weird) hence why I simplified it to more of an attraction force. Might have another go

@sinbad @toerror I once came up with a movement approach that’s somewhere in between lerping and seeking. To make a point go towards a target spread over e.g. 10 frames you move it 1/10 of the remaining distance the first frame, 1/9 of the remaining distance the second frame, etc. This is fixed time (no swarm following) and does not have issues with sudden target movements.

The Seven Voyages Of Steve

@runevision @toerror this is what I’m doing currently. Works great for point to point motion, trickier to add a curve on top

@sinbad @toerror Ok hear me out, you might be able to combine traits of multiple movement approaches.

If we call your current approach (the one I also described) for trerp, regular linear interpolation for lerp, and a spline/curve approach like @toerror described for curvp, then you could calculate separate "current positions" according to each of those and combine them like this:

combined_pos = curvp_pos + (trerp_pos - lerp_pos)

@sinbad @toerror That is, use the curve based position, but add the difference of the trerp approach compared to the lerp approach. For a stationary target that difference is zero, but for a moving target this difference should help the curve approach work better for abrupt changes in movement.

@sinbad @toerror The trerp calculation should keep track of its own "current position" which is not the combined position. The combined position on the other hand does not need to be saved for the next frame.