Jump to content

  • Log In with Google      Sign In   
  • Create Account


RTS lockstep


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 polyfrag   Crossbones+   -  Reputation: 1732

Like
0Likes
Like

Posted 11 November 2012 - 01:03 AM

Can someone explain RTS lockstep architecture?

http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php/

So lets say I issue a command to move 3 units at turn 1000 and all the players get it at turn 1001 and everybody acknowledges the command and executes it at 1002.

But what if a player doesn't get the packet and only gets it at 1002? That player would be 1 turn behind. How does the game stop to wait for the player? Since this is peer-to-peer does the issuing player have to tell everybody to stop until the lagging player has acknowledges the command?

Sponsor:

#2 polyfrag   Crossbones+   -  Reputation: 1732

Like
0Likes
Like

Posted 11 November 2012 - 01:52 AM

Oh, the issuing player has to send out a "turn done" message.

Edited by polyfrag, 11 November 2012 - 06:38 PM.


#3 polyfrag   Crossbones+   -  Reputation: 1732

Like
0Likes
Like

Posted 11 November 2012 - 02:23 AM

So:

1.) Player A sends out a command at turn 1000.
Player A sends out end turn 1000.

2.) Players receive command at 1001 but one doesn't get it. Players send back acknowledgements.
Players see that everybody else ended turn 1000 and send out to end turn 1001.

3.) Everybody gets an end to turn 1001.
Player A doesn't get an acknowledgement from the player that didn't receive the command and doesn't send out an end to turn 1002.
Thus player A doesn't send out to end turn 1002.
Player A tries to resend the command.

4.) The players didn't get an end to turn 1002 from player A so they wait.
The missed player acknowledges the resent command.

5.) Player A receives the acknowledgement and sends out to end turn 1002.

6.) All players receive end to turn 1002 and start 1003.

#4 polyfrag   Crossbones+   -  Reputation: 1732

Like
0Likes
Like

Posted 11 November 2012 - 02:32 AM

Does placement of buildings need to be executed 2 turns ahead too?

#5 polyfrag   Crossbones+   -  Reputation: 1732

Like
0Likes
Like

Posted 11 November 2012 - 03:15 AM

You know how to reduce the lag caused by pathfinding you only do 1 unit per 200 ms? If you don't send unit ID's for created units, how do you know in what order to find paths for the units each turn?

Edited by polyfrag, 11 November 2012 - 03:16 AM.


#6 0BZEN   Crossbones+   -  Reputation: 2004

Like
4Likes
Like

Posted 11 November 2012 - 05:21 AM

Wow, wow, slow down...

Posted Image


All right, back to the start...!

But what if a player doesn't get the packet and only gets it at 1002? That player would be 1 turn behind. How does the game stop to wait for the player? Since this is peer-to-peer does the issuing player have to tell everybody to stop until the lagging player has acknowledges the command?


Yes, everyone has to run in lock-step and wait for everyone's inputs. That's why you have all this command scheduling delay system, to give time for the remote players to receive and process your inputs.

Does placement of buildings need to be executed 2 turns ahead too?


I suppose. It is a way to hide the latency and synchronisation, so that everyone processes the command at the same time. Locally, you will have some short animation / sound effect between the time you press something and the time the command is executed.

You know how to reduce the lag caused by pathfinding you only do 1 unit per 200 ms? If you don't send unit ID's for created units, how do you know in what order to find paths for the units each turn?


The process relies on determinism. Given a game state, a set of inputs, all machines should produce exactly the same output, to the last bit, and processes executed in the same order. So for the process of creating units, if your system is truly deterministic, those units will be created and pathed in the same order and the same way on all machines automatically.

This is one of the requirements of those kinds of RTS games, and can be difficult to achieve consistently. However, determinism is a given (since computers are deterministic in nature), but the programming itself may break that determinism (random number generators for example). So usually a matter of tracking down those problems, rather than forcing determinism to happen. That applies for single-threaded application, multi-threading requires extra more care.

Think of it as a replay system, where you record an initial game state, a stream of inputs, and then playback those inputs for the replay. It's generally a good way to test your determinism, and that's how replay systems for starcraft and what-not works, and why the manage to be very small in size. Then you also have cases of cross-platform determinism, which throws another monkey wrench.

Edited by papalazaru, 11 November 2012 - 06:49 PM.

Everything is better with Metal.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS