Synchronization between clients/server

Networking & Multiplayer
#1

Hey Guys, I need some help.

OK, basically, my update/sync code looks like this:

//This gets run every 33 ms.
public void run() {
frame = (frame + 1) % 600;
if (frame % 60 == 0) {
frameCount = “” + (framesPerUpdate / 2);
framesPerUpdate = 0;
}

  if (frame % 4 == 0) {
        try {
              if (owner instanceof JApplet)
                    dout.writeByte(UPDATE_CLIENT_TCP);
              else
                    dout.writeByte(UPDATE_CLIENT);
        } catch (IOException ie) {
              System.out.println("Connection closed!");
              System.exit(1);
        }
  }
  if (avatarSelected != null)
        currentMap.updateVelocity(keyState, avatarSelected); //for caching
  currentMap.update(Theme.UPDATE_FREQUENCY);

}

so every 99 ms, I ask the server for an update. When the server gets a request for an update, it sends all of the locations, states, and extra avatar information to the client. Right now it sends about 100 bytes per avatar, which is obviously ridiculus, but I can use dirty bits and stuff to fix that.

The problem is this: When the user htis a key, say “go right”, the client instantly starts going right. The server has to wait for the command, then starts going right. Then when the server updates the client, the movement that the client did before the server knew that the player was moving gets taken away.

The end result is this jerkiness when you start to move or do an action.

I could try to emulate the server latency in the client somehow by adding delays or something, but that would be kinda tough.

I could also let the server handle all of the state changes,but that might have some weird consequences.

I figured that everyone who does network programming must have the same problem. What do the experts do to fix this situation?

#2

Youve got a few choices…

(1) Show something to indicate that motion has been recieved but dont do it until you hear back from the server. Kid of ugly but okay for slow enough paced games (eg ‘turn based’ ones and such.)

(2) Do all the motion on the client and just ‘sanity check’ on the server for cheating. Fast and realtively but difficult to make work in multi-player games.

(3) Synchronize clocks and use dead reckoning. This is what just about alll “real time” online multi-player games do.

The first thing you need is a synchronized time base between client and server. You can do that with ntp. Then, when you start a move on the client, you send a packet out to the server that includes the p[recise moment the movmement was started on the client. The server updates itself and the other players, taking into account the delta between whenh the action really started and when it gets the iformation. Obviously it has to ‘catch up’. How much work you put into hiding that catching up can make the difference between a “smooth” or a "laggy’ game.

Often (but nto always) its possible to predict the movmement beore you get the information based on the last information you receieved. This is soc alled “dead reckoning.” Good dead reckoning can do a lot to help minimize those adjustments.

Obviously because here are periods of motion that re goign to be missed or glossed over by the server, you need to do at elast some collision detection on the client. Its a good idea ot snaity check that on the server though to prevent cheating.

In a really breif form, thats what people do.

Hope it at elast gets you thinking along the right lines.

#3

awesome, thanks a bunch!!