# XNA move from start position to target position exactly in 3D

If I have a list of positions that map out a path a character should follow. What would be the best way to move at a constant speed to each position making sure the character lands exactly at each position before moving onto the next?

For example the character is at position A, we then queue up position B and position C. The character cannot move towards position C until it reaches position B exactly.

It would be great if the solution worked at slower frame rates/update speeds as well.

-
I'm not sure what you are asking - the best way to move at constant speed between each pair of waypoints would be a simple linear interpolation between the two positions - I don't think that's what you are looking for? – melak47 Oct 14 '12 at 19:02
Yes but if I use linear interpolation how do I ensure the character reaches the exact target location? Ie: if I move in the direction of the target location on each update how do you end on the exact target location if the speed you are travelling * the elapsed time overshoots the target location? – robasaurus Oct 14 '12 at 20:22

Why do you necessarily want the character to get to a point when a frame is drawn? You want your logic to be separated from view, that's why you use a timer and not onEnterFrame event, in first place. at smooth 30 FPS or more, a player won't see a difference.

What you want to do is not actually drawing the character on desired position, but behaving like if he was there. What you do now is probably calculating a `delta_time` everyframe by substracting old timestamp from an actual time: `delta_time = Now() - old_timestamp; old_timestamp = Now();`. And then using this data to move objects (e.g. `x += vx * delta_time`) etc. and then update them on screen. What you want to do in this case is to calculate objects (at least these that can be altered by the character's position) twice - at the moment the character reached a point, and at a moment right after, that is, delta_time after previous frame:

1. Calculate when the character will come to point B (from A): `journey_time = distance / speed`.

2. On next frame, get the `delta_time` from previous frame.

3. If `delta_time >= journey_time` go to next point (4). Else `journey_time -= delta_time` and go to point 2.

4. Calculate everything for the moment the character reaches destination point, e.g. `simulatePhysics ( journey_time );`

5. Add actions special to the event (because you want to detect reaching the point for some particular reason I suppose), e.g. make the character ghostlike: `physics.removeChild ( character );`

6. Calculate second part of the 'frame': `simulatePhysics ( delta_time - journey_time );`.

7. Redraw the frame.

-

There is no solution that satisfies this demand precisely.

1. You would need to cap the framerate to a framefrate the player's machine can handle constantly. (the lowest framerate the game reaches when computation is heavy)
2. Calculate the distance from the current position to the first destination.
3. Divide that distance by the speed you wish the character to move at divided by the current framerate to get the amount of frames it would take to reach the destination. `distance / (speedPerSecond * (1.0/frameRate)) = framesLeft`
4. This could be a none integer number such as `framesLeft = 54.76`. We round this number to the nearest integer number `roundFrameCount = 55` and calculate a fake speed of `fakeSpeed = (distance / roundFrameCount)`.
5. We now move the object at this rate each frame.

Otherwise, when the object is too close to the first destination, you have to deduct the distance from that destination from the `stepSize = speed * delta` and use the rest of the `stepSize - distance` to move towards the next destination.

-
 "There is no solution that satisfies this demand precisely." - this may be true to XNA, that I don't know, or when limited to some engine, but otherwise it should be achievable as in my answer, am I right? – Markus von Broady Oct 15 '12 at 15:01 You are right that the player will not see much of a difference in some real life cases(high fps, normal speed). however, lets say the speed is high and the frame rate is low. The player could see a difference. – Arthur Wulf White Oct 16 '12 at 7:42 I thought about it and I think that if frame rate is low compared to speed, then you rather have a bigger problem - either your frame rate is not smooth, or your objects move too fast, and therefore you don't perceive them as moving, but as teleporting very fast from place to place. Second issue could be solved by drawing the object many times with different opacity. – Markus von Broady Oct 16 '12 at 7:51 I agree you are right in most real life gaming situation. There are some old game situations like Sonic, where the sprites move in very high speeds and you may want to have control on where they appear to go through like key frames in computer animation. – Arthur Wulf White Oct 16 '12 at 7:57 @MarkusvonBroady - Could you chat with me? chat.stackexchange.com/rooms/5993/dices – Arthur Wulf White Oct 16 '12 at 8:14