Corona SDK position prediction

Question

I am using Corona sdk to create a multiplayer game. Each device sends 15 messages per second containing the position of their character. This results in a choppy movement because some messages take slightly different times to be received and it only sends 15 per second in a 30 fps game. How could I take the difference in the position or rotation of the character from the previous frame to current frame to predict the position if no data is received in the next frame. I am completely open to other solutions too! Thanks!

Answer 1

If the send rate is fixed and known to both parties (sender and receiver), then the receiver can assume it. In that case, dead reckoning is a well-established technique that is easy to apply. For example, if sender sends data every 1/15th second, then receiver can assume that, after the first packet has been received, any other packets will be 1/15th second apart. If something is not received after 1/15th second, then receiver makes a guess as to what the data would be at 1/15th second if it had been received. Then when the packet actually comes, it corrects the guess.

The only thing to guarantee is the order of packets, and delivery. If packets never drop, and always get there in order (ie, TCP), you're laughing.

If order is guaranteed but some get dropped, then receiver needs to know when drop occurred. I think this could be corrected via a counter that is part of packet. So if receiver gets a packet with counter = X, and next packet has packet = X+2, then receiver knows that the packet was dropped because order is guaranteed, so time delta between the two is 2/15th second.

If no dropping but order not guaranteed, the counter will help there too: your receiver is guaranteed that if X has arrived, X+1 will arrive eventually, so even if it gets X+2, it should save X+2 and wait till X+1 arrives.

Finally, if neither delivery nor order are guaranteed (the case of UDP packets on a WAN), then once more counter is sufficient, but the algorithm changes: if it gets packet with counter=X, and it gets X+2, it could mean that X+1 has been dropped, or will arrive shortly, but there is no way to know. So the receiver could wait a small amount (maybe another 1/15th second) if X+1 hasn't arrived by then, declare it as dropped (so if does eventually arrive it will be ignored).

The near-constant frequency of sender is critical in the above.