A simple example of movement prediction

Question

I've seen lots of examples of theory about the reason for client-side prediction, but I'm having a hard time converting it into code. I was wondering if someone knows of some specific examples that share some of the code, or can share their knowledge to shed some light into my situation.

---

I'm trying to run some tests to get a the movement going (smoothly) between multiple clients. I'm using mouse input to initiate movement.

I'm using AS3 and C# on a local Player.IO server. Right now I'm trying to get the Client side working, as I'm only forwarding position info with the client.

I have 2 timers, one is an onEnterFrame and the other is a 100ms Timer, and one on mouseClick listener.

• When I click anywhere with a mouse, I update my player class to give it a destination point

• On every enterFrame Event for the player, it moves towards the destination point

• At every 100ms it sends a message to the server with the position of where it should be in a 100ms.

• The distance traveled is calculated by taking the distance (in Pixels) that the player can travel in one second, and dividing it by the framerate for the onEnterFrame handler, and by the update frequency (1/0.100s) for the server update.

• For the other Players, the location is interpolated and animated on every frame based on the new location.

Is this the right way of doing it?

Answer 1

Does the server know the destination point? If not, it might be a problem if you get lost or late messages, which is always a risk with networking.

Even if, on the second lost message in a row, you add the player's velocity again to keep moving them by the same distance as they moved in the previous 100ms, it will overshoot the player if messages are lost after player reaches the destination point. What you could do is either transmit the destination point to the server as well so it knows when to stop.

Also make sure things don't break badly if the client's frame-rate stutters, or a later message gets to the server before an earlier one, or arrives after you thought you'd stopped listening for it. A player position going astray for a few frames probably isn't a big deal, but make sure nothing can get permanently corrupted or out of synch.

Answer 2

Yes, I think that would be the right way. If that doesn't work out, you should try using the x/y velocity to predict where he'll be, based on how often you run an update, and how fast he's going, for instance, if you run an update every 50ms, and the player is going at 1 pixel x per update, and 1 pixel y per update, than you predict the player to be two steps ahead, assuming that his velocity is consistant.