Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualslicer4ever

Posted 15 June 2013 - 01:40 PM

so, i've been thinking of this problem as well. and my solution is similar to Polyfrags.

1. recieve input from client.
2. predict when all clients should receive the command based on known pings, and mark the command for execution then.
3. distribute command to all clients(including source client, since the commands execution window is changed).
4. recieve OK from all clients.
5. send-all clear to clients.

however, are you suggesting steps 4/5 can be assumed to be received by the clients, and the server doesn't require validation from the clients.
i've been thinking it might be reasonable, since it's possible to detect if a client is out-of sync. however my mechanism suffers from the potential of a sudden lag spike. this might not be a problem over a lan, but over the internet it could be a serious issue.

also, step 5 is problematic, because what-if the all-clear doesn't reach some clients in time for the command to be executed, and then they are out of sync.(similarly stopping at step 3 gives the same potential to occur).

I suppose lag is theoretically unavoidable, but my main concern is how to mitigate recovery, if a client get's out of sync, it'd be hard to get them back in-sync, one method would be to store snapshots of the game at various intervals, and then move back to the nearest interval where a command was run. speed the game back upto realtime, and continue forward. but that seems like a nasty/bloated method for recovery.

#2slicer4ever

Posted 15 June 2013 - 01:37 PM

so, i've been thinking of this problem as well. and my solution is similar to Polyfrags.

1. recieve input from client.
2. predict when all clients should receive the command based on known pings, and mark the command for execution then.
3. distribute command to all clients(including source client, since the commands execution window is changed).
4. recieve OK from all clients.
5. send-all clear to clients.

however, are you suggesting steps 4/5 can be assumed to be received by the clients, and the server doesn't require validation from the clients.
i've been thinking it might be reasonable, since it's possible to detect if a client is out-of sync. however my mechanism suffers from the potential of a sudden lag spike. this might not be a problem over a lan, but over the internet it could be a serious issue.

also, step 5 is problematic, because what-if the all-clear doesn't reach some clients in time for the command to be executed, and then they are out of sync.(similarly stopping at step 3 gives the same potential to occur).

#1slicer4ever

Posted 15 June 2013 - 01:35 PM

so, i've been thinking of this problem as well. and my solution is similar to Polyfrags.

1. recieve input from client.
2. predict when all clients should receive the command based on known pings, and mark the command for execution then.
3. distribute command to all clients(including source client, since the commands execution window is changed).
4. recieve OK from all clients.
5. send-all clear to clients.

however, are you suggesting steps 4/5 can be assumed to be received by the clients, and the server doesn't require validation from the clients.
i've been thinking it might be reasonable, since it's possible to detect if a client is out-of sync. however my mechanism suffers from the potential of a sudden lag spike. this might not be a problem over a lan, but over the internet it could be a serious issue.

PARTNERS