multi-player synchronisation

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.

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

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

what about a constant stream of uninterrupted mostly empty data? the changes in delay should be small, more predictable and manegable?

********


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

hey, walkingcarcass, i can''t help but notice u also use lower-case letters only!

---
shurcool
wwdev

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

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.