Hello, I'm a newbie in network programming and I have a few questions about latency and synchronizing... I'd like to do isometric MMORPG. I'm in designing stage and I need to design my network protocol in such way, that I can synchronize from 2 to 100(inprobable) clients with different latencies. Because of my technology, it would be best to send over network only input you made and to run exactly same game on all machines, which enables me to do simple checksum on game state on all machines and decide whether the client is not cheating. But other solutions are possible(assuming that clients are highly trustworthy). Now I need to now how to synchronize it. Imagine situation when I atack another player. I click on him and start fighting him. After some delay dependent on latency I start dead reckogning fighting algorithm on his computer. It will be accurate if I want to kill him - algorithm will smoothly continue fighting him until he die, but what if I decide not to kill him and stop the action? In the delay between sending stop message to the server and from server to opposite client the opponent can be alredy death and corecting the algoritm to return him to life is bit stupid. Second question, related to first one, is what are the latencies I need to count in on these days internet? Thx [edited by - osh on January 13, 2004 2:25:27 PM]

C''mon! No ideas?!

Latency is an inherent part of the network, you''re not going to get around it. Running a MMORPG using a lock step method wont work well because, the''ll be 2-100 people on and they can have greatly varying latency. Waiting for all players to ack a step packet would be very time consumming. Use the standard server client model, and make your client a thin client which just plays back server events. That would work well for a MMORPG.

Latency today is around 10-30 ms within your wide area network, and 50-150ms for the interent within your general geograpic region. >200ms for people outside your continent i''ve found.

Good Luck

-ddn

Thank you! You helped me!
By sending only the input I mean things like ''I click by mouse on square XY''.
This would be best suitable because I''m trying to design hybrid, but mostly P2P, solution. And thus if I can do it this way, every client runs exactly same game and can checksum game state and send it to the server (which would be some of the client machines[different thread] too and which would only send the msg to other clients and compare checksums) and if some clients will have wrong checksum, they are cheating.
I think this is the only way that can be applied in completly trustworthy environment.

Btw: What if a hacker somehow hack the server thread he runs and confuse checksum compare algorithm that he''ll be able to play even he differs in checksum? Shit...

Well think about it, if your only going to send inputs, and you want the clients to be perfectly synchonrized. You have to marshall all the inputs that timestep and send it to all the other clients, so everyone has all the inputs that timestep. Then they have to acknowledge this before you can acutally step it on your central server, which you will need one for database access and event marshalling. If just one of the clients has a latency of 1000ms, the effective update rate of the server will be then 1 tick / 1000ms.

Good Luck.

-ddn

And what if I make some delay between putting action into effect? What do you think is the delay that wouldn''t be noticable. This is going to be isometric RPG, so it can be 200 ms, 400 ms...? By doing this, I can specify ''frames'' where every frame can be long say 200ms and if action happen in frame one, it''ll be received by others in frame two and it''ll be executed in frame three. So by this aproach I can smoothly handle clients with latency up to 200ms but what if they will have higher latency? Then I would need to set (according to ping) when it will be executed, and this will result in slow response, wouldn''t it?
Or what are another approaches in trustworthy environment? Approaches when clients wouldn''t be slowed by slowest machine like in previous method?
Still I like my method most, because server-side computing will be almost zero and thats definitly what I need.

If you feel the clients are trustworthy, and your intent upon keeping the peer 2 peer arch. I would do this.

To make the system more robust, the server is authortive but its still using the lockstep method. The clients send the server their inputs, and get all inputs from the server that step . The game runs at realtime, that is the server never stops and waits on its peers. If they fall behaind they can ask to be resynchonized with a log of inputs they missed. All events which never make it to the server, are consider lost, and you will have to deal with them, either resend or just leave them lost.

For this to be workable the clients must keep a readily available good past state from which to restart the game from quickly. So the game takes snapshots of itself every minute and saves that to disk.

New players can download a snapshot of a stable past game and an event log which will catch them up to nearly the current server time. Then they get the latest updates in one packet from the server, which catches them up to the current game.

Using the lockstep method you cant inject latency in the inputs, they all must be executed in the same order and timestep so the game stays syncrhonized. That is each node, server and client has a complete and full simulation of the game at all times.

Good Luck

-ddn