Design pattern suggestions for syncing multiple-user data in an online game in real-time

Question

I'm working on a project to learn node.js, and was looking for some suggestions on how to handle syncing user data in real-time.

Say you have a 2D rectangular map (roughly 600x400), with a number of players occupying x,y positions on that map. Each user can navigate around with the arrow keys and interact with the others in some basic way. Given that this would be played over HTTP, what would be the best design pattern in terms of handling and syncing user data to give the smoothest, snappiest experience?

I can think of several options, but would appreciate some more ideas / clarification:

1. Client sends positional data to server, server distributes all positions to all clients, screen is rendered with the result. Repeat. The downside would be that the client side is lagged by the time it takes for a data round-trip, but the upside is that they are synced with all users.

2. Client renders where it thinks it is constantly, sends positional data to server, server distributes all positions to all clients, and then screen rendering from client data is corrected with server data. Upside is a snappier response, downside is a slight loss of sync.

3. A blend of the two, but instead of using (x,y) co-ordinates we use a vector of [previous x/y and time, current x/y and time, suggested x/y at time interval] which can then be used to draw projectile paths that constantly shift. It seems like this would be tricky to implement.

Any pointers?

Answer 1

Most games use some form of dead reckoning http://en.wikipedia.org/wiki/Dead_reckoning which allows for delayed updates distributed from the server but preserves some illusion of real time updates on the client.

The best option is 3. It's not particularly complex - just track where you expect each actor to be based on the mechanics of the game, and when you receive an update from the server you bring the two states in line over time.

If you find the server sends you a state that is too far from the state your client is assuming (too far needs to be defined) then you may just jump to the server state and accept the discontinuity on the client.