Archived

This topic is now archived and is closed to further replies.

walkingcarcass

multi-player synchronisation

Recommended Posts

in my ideal environment, when the server sends a message, the players all recieve it at exactly the same time. in a predictable simulation, this would allow each player to run at their own maximum framerate and recieve low-bandwidth instructions to act on in exactly the same manner with exactly the same outcome. as if. what if one player recieved the instructions later, their simulation will have advanced further in time and the result may be different and we are no longer in sync. i see only two solutions: everyone operates at a fixed rate: send info, recieve info, act on info at an agreed time, repeat. queue data and send at a fixed rate (ie 5fps). the other problem i see is that what if one player doesnt recieve the data at all while everyone else has already skipped to the next stage? any suggestions would be much appreciated.

Share this post


Link to post
Share on other sites
What sort of game is it?

I''m thinking of how multiplayer FPS games seem to work, IE: if you experience bandwidth congestion, you can see the other players "Skipping" from place to place, rather than moving fluidly. I imagine the locations of the other players are being sent, and your PC then updates the enemy locations. When data packets are late, this does allow "Catch-up" but it''s not always pretty for the player to look at...Are the data packets being sent similar to this, or are they more complex?


Chime - SNES Mariokart veteran, 10 years on and still red-shelling on a weekly basis.

Share this post


Link to post
Share on other sites
my packets only send basic inputs like "step left" in a bit array; positions etc are calculated at the client end.

since the engine is deterministic if unhacked, there will be no out of synch problems if all players act on that input at the same time (in the simulation''s local time)

the problem is if a packet is late, someone may start running later than on another machine. this is ok in a small time, but the collision detection might have a bullet hit the arm instead of a head if the animation is delayed.

i dont want to have schedule "act at time T" because this will cause the input to be laggy even if the framerate is high.

having input at a fixed rate ie 10 fps would probably feel ok, but again, what if a packet was late, or worse, lost?

A Problem Worthy of Attack
Proves It''s Worth
by Fighting Back

Share this post


Link to post
Share on other sites
You must send the positional updates at some point. You can NEVER rely on a network, LAN or internet, to deliver packets on time. Even the persons machine has a factor in it.

Stephen Manchester
Senior Technical Lead
Virtual Media Vision, Inc.
stephen@virtualmediavision.com
(310) 930-7349

Share this post


Link to post
Share on other sites
wc:

This is something I''ve been reading a lot about.

When I worked on a multiplayer Rpg school project it was perhaps the biggest problem that we never got a chance to fully address.


Since that time I''ve kept my eyes open for any research or algorithms that could be used to help handle synchronization issues.


If I remember correctly, one article I read suggested using a time stamping mechanism, whereby all clients would receive a timestamp from the game server when they initially connect.


In conjunction with the timestamp, the players would send out flags when they change direction or begin moving. (Sounds like what you are doing now).

Additionally, I''ve also read that you could include regular updates from the server that would include the information you''d need to correctly the position of your character at that particular time. (according to the timestamp contained in the packet).

In this case, I believe UDP was the protocol being used.
So you''d also create a mechanism to reject packets that weren''t fresh (not close enough to the current timestamp).

The packets from the server contain the exact position, impulse and orientation of the player at that time.

So if some packets do get dropped, you will see the stutter step
typical to high latency. But the players position will roughly correspond to what it should for the given time.

In normal conditions the updates will arrive and the position will be interpolated smoothly.


You might want to check out this article:

citeseer

The citeseer site basically is an online library of a bunch of research papers regarding all areas of computer science.

But if you go to the main page and enter synchronization, multiplayer as search keywords you''ll find quite a few interesting articles.


Cheers,

frost-byte

Share this post


Link to post
Share on other sites
im using position and alignment data only for a car racing game with a time stamp.

accelerations and deacells are sudden but position in reality changes less so accuracy is greater, bandwidth is lower.

dead reckoning with velocity, position, acc, timestamp to me seems like lots more data than just position, alignment and timestamp. So potentially more position updates can be given, or or better latency gained.

oh yeah, and position+time stamp lets u predict behaviour just like the other type of dead reckoning except the warps are less.

Share this post


Link to post
Share on other sites