LockStep Sync
I want to know what is "LockStep Sync Model"...
I can't find any useful(good..) documents to explain that model..
Google would not teach about that...:(
Please let me know sites, books or articles related to that...
Help me~
Basically all hosts hold the same state at all times, and the game only progresses when all hosts are in synch. This method is used for a lot of RTS games, and by extension any game where the input and logic are easily discretizable. The major advantage of lockstep synch is that only have to send the input (a couple of hundred bytes a second at the most) instead of sending game state snapshots which are much larger. The major disadvantage is that it is not tolerant of dropped packets in the same way as a compressed-state-snapshot scheme such as Quake3.
Thank you...but, answer is too simple...
I want to know more and in detail...for example, psuedo game loop, information of messages exchanging between each peer and so on...
I want to know more and in detail...for example, psuedo game loop, information of messages exchanging between each peer and so on...
You need to be 100% determinist to be able to do lock step so basically, what you do is make sure that everything happen on both machines, at the same time. That means probably buffering your input and re-injecting them in your engine when the correct "tick" is reached + making sure that you synchronized time, simulation and your random generator on both side (probably having 2 seeds, one replicated for gameplay element, the other, not replicated, for graphics that don't affect gameplay).
Let say, you buffer 2 frames, when the user press "move foward", you send the input to the other player with the timestamp when it will need to be executed. On your side you put it in a list of input to be processed. On both station, when you reach the timestamp, you process the input.
This method works well if you don't have many players ((like 2 players in case of a real-time game) or you're in a turn based game (where split-second reaction is not mandatory). Also, in the case of a real-time game, latency of more than 150 ms will probably make the player scream as it will be harder to hit something that was moving (in the case of an fps).
The problem with this approch is that it doesn't scale well (at all). If you have as much time between frames as you want it's ok, but if you don't (like fps) you will start experiencing early. And remember, if something goes out of sync, you're screwed since you rely on having the exact same thing on both side (actually you could always send a checksum and resend the complete state in case a checksum failed but that imply stopping the simulation until you're back in sync). Also, you will need a garanteed delivery protocol (either using a modified UDP or using TCP) as you need every single packet.
Gizz
Let say, you buffer 2 frames, when the user press "move foward", you send the input to the other player with the timestamp when it will need to be executed. On your side you put it in a list of input to be processed. On both station, when you reach the timestamp, you process the input.
This method works well if you don't have many players ((like 2 players in case of a real-time game) or you're in a turn based game (where split-second reaction is not mandatory). Also, in the case of a real-time game, latency of more than 150 ms will probably make the player scream as it will be harder to hit something that was moving (in the case of an fps).
The problem with this approch is that it doesn't scale well (at all). If you have as much time between frames as you want it's ok, but if you don't (like fps) you will start experiencing early. And remember, if something goes out of sync, you're screwed since you rely on having the exact same thing on both side (actually you could always send a checksum and resend the complete state in case a checksum failed but that imply stopping the simulation until you're back in sync). Also, you will need a garanteed delivery protocol (either using a modified UDP or using TCP) as you need every single packet.
Gizz
Should every peer wait for some message indicating that this turn is OK to proceed, every time ticks? Even when I have no input, do I have to send a message indicating "You can advance at XXX time tick" to match step?
Depends on your network architecture but you will need a way to make sure everything is ready for the next frame. Normally you buffer input and send a "ok msg".
Ex: When all packets for frame 17 are received, you can send a msg "frame 17 ready" so that when the time comes you will know that frame 17 is ok to process.
That's why you won't be able to play a FPS game with latency over 150ms with this approch since if something is not received by the time you are ready to "play" the frame you will need to wait.
Ex: When all packets for frame 17 are received, you can send a msg "frame 17 ready" so that when the time comes you will know that frame 17 is ok to process.
That's why you won't be able to play a FPS game with latency over 150ms with this approch since if something is not received by the time you are ready to "play" the frame you will need to wait.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement