Best solution for a pong game

Networking & Multiplayer
#1

Hey fellow java people. I have a multiplayer pong game, and it’s network layer completely written and working. However, I’m new to networking games, and I’m not sure what the best method is to keep the games in sync in a real-time game such as pong.

When connected to a friend in the same state as me, I’m able to relay about 40 packets of data per second, each containing a serialized String of length 4 (11 bytes of data).

When the ball bounces off of a paddle, the angle at which it will travel in the opposite direction is dependant on the speed at which the paddle was moving when the ball hit it.

Does anybody have any thoughts as to what the best way to keep the two players’ games in sync would be? I’m not sure what sort of data to send to the other player, and when to send it. Also, even if using 1.5, or gagetimer, will timing be inacurate if the computer clocks on each computer are not perfectly in sync?

Thanks,
Breadstick

#2

If the ball movement is perfectly predictable (no random numbers used), then all you really need to transmit is the position & velocity of the opponents bat at the point of contact. presuming the bats only move in 1D, the time of the colliosion must be at a set point - given the balls current velocity and direction, there will be a specific time when it reaches the x coordinate f the front of the bat. the trick will be to have both players with the feeling the game is ‘responsive’.

One way to do this is have each players client being responsible for the ball movement from the point the other player hits it until they hit it back. That way they get to play ‘perfectly’ until it is the other players turn, at which point you send the start position & velocity of the ball to the other player and let them handle it until it returns. The player without the ball sends his paddle positions to the other, but this is merely cosmetic to let the other player see roughly what is going on.

Sychnonising a network clock is non-trivial. if you can avoid it, do. Otherwise, google for more details. Essentially you have to measure travel times between the clients and work out which messages had a ‘good’ round trip (very little delay) and use these to set the clock, ignoring any timer messages that were slower than average.

Hope this helps,

Dom

#3

Thanks for the tips. One idea I had was that when one player had to update the other player, they would send the current system time to the other player, along with the speed and velocity of the ball in that players game. When the other player received this data, that player would calculate where the current possition of the ball should be based on the ball info the other player sent, and how many ‘ticks’ have passed since the time that was received.

I wasn’t sure if I could handle this accurately though. Is it safe to assume the the two players’ system clocks are synced? If not, what can I use as a reference point for time? I was thinking about using some sort of key frame system, but wasn’t so sure if that would be the best solution here.

Hope that wasn’t too confusing…

#4

As th ball has a fixed equation describing its motion, you should be able to sync without worrying too much about time. Anyway, thats an extra complication for now :slight_smile:

To sync a clock, you basically decide which client is going to run the ‘master clock’ This ‘resets’ the clock by storing the current time. Thenthe game time is ‘currentTimeInMillis - startTime’.

The other client must ask for a time update, sending a request number with the message, and recording when it sent the message ‘msgTime’ and what number it used.

The master clock respons immediately to the message with the current game time (currentTime - startTime).

The other client receives this, and matches it to the stored sent request (using the request number I mentioned earlier), also noting the time it received the message ‘recvTime’. Note all client times can be done with the currentTimeMillis as we are going to be taking differences.

The approximate ‘game time’ for this client is then:

approxGameTime = receivedGameTime + ((recvTime - msgTime)>>1);

This is adding on half the round trip time (RTT).
However, that is not the end of it. You have to account for variations in the transmission.

To do this:

For the first timer message received just set gameClock and store RTT as ‘bestRTT’

For each subsequent clock update:

RTT = recvTime - msgTime;
if( RTT < bestRTT )
{   // Best result so far, average this with current clock
     gameTime = (approxGameTime + gameTime)>>1;
     bestRTT = RTT;
}
else if( RTT < bestRTT + (bestRTT>>2) )
{  // The RTT was pretty good, but not great
    // Take a 1/4 weighted average
     gameTime = (3*gameTime + approxGameTime)>>2;
}
clockOffset = gameTime - System.currentTimeMillis();

then the client has an offset he can use to get the game time:

long GetGameTime()
{
    return (clockoffset - System.currentTimeMillis());
}

This is a simple way of getting an OK shared clock.
To do it properly, you should measure the standard deviation of the RTTs, and use a weighted average based on this (instead of the 25% of best RTT I use above). This will give a better update behaviour over a noisy network than the scheme here, but this should work ok for a local area network or a good internet connection.

Apologies in advance for typos, syntax errors, & getting my +/- signs the wrong way around :slight_smile:

Hope this helps,

  • Dom