Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualpapalazaru

Posted 11 November 2012 - 06:49 PM

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.

#4papalazaru

Posted 11 November 2012 - 05:22 AM

Wow, wow, slow down...

Posted Image


All right, back to the start...!

<quote>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?</quote>

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.

<quote>Does placement of buildings need to be executed 2 turns ahead too?</quote>

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.

<quote>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?</quote>

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.

#3papalazaru

Posted 11 November 2012 - 05:22 AM

http://imgur.com/f1Wv4"><img src="http://i.imgur.com/f1Wv4.jpg

All right, back to the start...!

<quote>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?</quote>

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.

<quote>Does placement of buildings need to be executed 2 turns ahead too?</quote>

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.

<quote>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?</quote>

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.

#2papalazaru

Posted 11 November 2012 - 05:21 AM

<a href="http://imgur.com/f1Wv4"><img src="http://i.imgur.com/f1Wv4.jpg" alt="" title="Hosted by imgur.com" /></a>


All right, back to the start...!

<quote>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?</quote>

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.

<quote>Does placement of buildings need to be executed 2 turns ahead too?</quote>

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.

<quote>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?</quote>

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.

#1papalazaru

Posted 11 November 2012 - 05:21 AM

<a href="http://imgur.com/f1Wv4"><img src="http://i.imgur.com/f1Wv4.jpg" alt="" title="Hosted by imgur.com" /></a>


All right, back to the start...!

<quote>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?</quote>

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.

<quote>Does placement of buildings need to be executed 2 turns ahead too?</quote>

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.

<quote>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?</quote>

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.

PARTNERS