Mutli Player Game synchronization

Question

The Situation:

I would like to ask what's the best logic for synchronizing objects in a multiplayer 1:1 game using BT or a web server. The game has two players, each of them has multiple guns & bullets, the bullets are created dynamically and disappear after a while, the players my move objects around simultaneously.

The Problem:

I have a real issue with synchronization, since the bullets on one device may be faster than other, also they may have already gone or hit an object on one device while on the other its still in the air.

Possibilities?

What is the best way of handling synchonization in this case? Should all the objects be controlled by one device acting as the server, while th other just gets the values, positions and does very little thinking. Or should control be distributed where each device creates, destroys and moves its own objects and then through synchronization tells the other device.

What is the best to handle transmission delay in this, since BT might be faster than playing over the web? The best would be a working sample - thanks very much!

Answer 1

You seem to have started on some good ideas about synchronization, but it's possible there are two problems you are running into that are getting overlapped: the synchronization of game clocks and the sychronization of gamestate.

(1) synchronizing game clocks you need some representation of 'game time' for your game. for a 2 player game it is very reasonable to simply declare one the authority.

so on the authoritative client:

OnUpdate()
  gameTime = GetClockTime();
  msg.gameTime = gameTime
  SendGameTimeMessage(msg);

on the other client might be something like:

OnReceivGameTimeeMessage(msg)
 lastGameTimeFromNetwork = msg.gameTime;
 lastClockTimeOfGameTimeMessage = GetClockTime();

OnUpdate()
 gameTime = lastGameTimeFromNetwork + GetClockTime() - lastClockTimeOfGameTimeMessage;

there are complications like skipping/slipping (ie getting times from over the network that go forward/backward too much) that require further work, but hopefully you get the idea. follow up with another question if you need.

note: this example doesn't differentiate 'ticks' vs 'seconds' nor does is it tied to your network protocol nor the type of device your game is running on (save the requirement 'the device has a local clock').

(2) synchronizing gamestate after you have a consistent game clock, you still need to work out how to consistently simulate and propagate your gamestate. for synchronizing gamestate you have a few choices:

asynchronous

• each unit of gamestate is 'owned' by one process. only that process is allowed to change that gamestate. those changes are propagated to all other processes.
• if everything is owned by a single process, this is often called a 'client/server' game.
• note, with this model each client has a different view of the game world at any time.
• example games: quake, world of warcraft

to optimize bandwidth and hide latency, you can often do some local simulation for fields with a high update frequency. example:

drawPosition = lastSyncPostion + (currentTime - lastSyncTime) * lastSyncVelocity

of course you to having to reconcile new information with your simulated version in this case.

synchronous

• each unit of gamestate is identical in all processes.
• commands from each process are propagated to each other with their desired initiation time (sometime in the future).
• in its simplest form, one process (often called the host) sends special messages indicating when to advance the game time. when everyone recieves that message they are allowed to simulate the game up to that point.
• the 'in the future' requirement leads to high latency between input command and gamestate change.
• in non-real time games like civilization, this is fine. in a game like starcraft, normally the sound acknowledging the input comes immediately, but the actually gamestate affecting action is delayed. this style is not appropriate for games like shooters that require time-sensitive actions (on the ~100ms scale).

synchronous with resimulation

• each unit of gamestate is identical in all processes.
• each process sends all other processes its input with its current timestamp. additionally a 'nothing happened' message is periodically sent.
• each process has 2 copies of the gamestate.
• copy 1 of the gamestate is propagated to the 'last earliest message' it has receive from all other clients. this is equivalent to the synchronous model, but has the weakness that it represents a gamestate from 'a little bit ago'
• copy 2 of the gamestate is copy 1 plus all the remaining messages. it is a prediction of what is gamestate at the current time on the client, assuming nothing new happens.
• the player interacts with some combination of the two gamestate (ideally 100% copy 2, but some consideration must be taken to avoid pops as new messages come in)
• example games: street fighter 4 (internet play)

from your description, options (1) and (3) seem to fit your problem. again if you have further questions or require more detail, ask a follow up.

Answer 2

since the bullets on one device may be faster than other

This should not happen if the game has been architected properly.

Most games these days (particularly multiplayer ones) work on ticks - small timeslices. Each system should get the exact same result when it computes what happened during a tick - no "bullets moving faster on one machine than they do on another".

Then it's a much simpler matter of making sure each system gets the same inputs for each player (you'll need to broadcast each player's input to each other player, along with the tick the input was registered during), and making sure that each system calculates ticks at the same rate.