Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

- Scaling down the 'pace' of multiplayer play (Fewer but harder creatures, everything moves slower to reduce bandwidth, etc)

This is not an issue. As long as the game is defined by few timestamped and numbered actions/commands, clients does not have to send snapshots of the game, but only commands.

For multiplayer, just copy and adapt the GGPO philosophy. [http://ggpo.net/]

In multiplayer, the server must be authoritative in confirming that each player is sending the same data both to other clients and to the server. This can be done with little amount of bandwidth by using hash-functions.

Baxta, not quite. Currently, the server is doing authoritative checks rather than trusting clients, hence the constant desyncing.

"

This is not an issue. As long as the game is defined by few timestamped and numbered actions/commands, clients does not have to send snapshots of the game, but only commands.

The client sends input commands, but it becomes out of sync due to latency. The client needs to instead be authoritative until the server performs the sanity check (when the user leaves the instance).

Unfortunately, as the game state changes due to other players, there is a greater chance of desync. However, I think that there needs to be FAR more tolerance for pathing in these scenarios to prevent the more extreme cases of rubberbanding.

"

qwave wrote:

Baxta, not quite. Currently, the server is doing authoritative checks rather than trusting clients, hence the constant desyncing.

I don't think those checks are the cause of desync but I'm waiting for clarification.

If bouncing checks off the auth server was the problem, more logic client-side wouldnt help.

In single player, the client does not need to be authoritative, it needs only to know what is the effect of its commands. In the same way you do not have to be authoritative in defining the chessboard status: as long as you send the command "B5-B4", and the command is valid, both you and the server will know how the chessboard will look like.

In single player there is no such thing as out-of sync if commands are timestamped and numbered. You are 'out of sync' only if you do not communicate for a long while, or if you send an invalid command: in this case the server disconnect you.

With a similar framework +GGPO techinque, in multiplayer you can desync only for latency, and not for lack of info, because there is no bandwidth issue for the server: commmunication is small (only commands are sent) and also p2p (less server loads).

With current implementation you are out of sync because the server does not give you info about what is happening.

qwave, what if server would NOT be verifying actions during combat.... Maybe there could be some conditions when monsters are around, server trust client (and verify it later..when grabbing loot or just running from place to place?)..not sure if this would change much..but I believe verifying all actions upon instance close could take some time..will account just hang on while all simulations will be replayed?

SO MANY DESYNC APOLOGISTS...

Holy hell it's pathetic...

Notice how they all have "supporter" next to their names...

No wonder GGG won't do shit to address the problem, they got a horde of lemmings throwing money at a broken game the whole time denying problems and defending flawed code...

The fuck is wrong with this world...

"

...but I believe verifying all actions upon instance close could take some time..will account just hang on while all simulations will be replayed?

Remember, the server is already currently verifying all actions in realtime. I am just suggesting that they hold off on this verification process until you leave the instance. As it stands, the server is currently doing a lot of work to maintain the game state because it has to:
- Cache the existing state and likely persist it to database.
- Listen for updates, and re-access the cache.
- Persist the new state and send a response.

With the new system, it could skip all these steps because it would perform the entire validation process all at once. Since the entire snapshot would be in-memory, it could process a full '1 hour run' in a few seconds and then perform a batch SQL update. =)

"

qwave wrote:

"

...but I believe verifying all actions upon instance close could take some time..will account just hang on while all simulations will be replayed?

Remember, the server is already currently verifying all actions in realtime. I am just suggesting that they hold off on this verification process until you leave the instance. As it stands, the server is currently doing a lot of work to maintain the game state because it has to:
- Cache the existing state and likely persist it to database.
- Listen for updates, and re-access the cache.
- Persist the new state and send a response.

With the new system, it could skip all these steps because it would perform the entire validation process all at once. Since the entire snapshot would be in-memory, it could process a full '1 hour run' in a few seconds and then perform a batch SQL update. =)

I am just curious here.. :) as I see you understand whole logic and logistic behind it..

But anyway..what would happen, if server would be verifying all actions in "realtime"..like now..but just with some delay. So..server would trust client... but verifying it in background let's say with 30 seconds delay or something like that..

And if server will find some abnormalities, it will flag that account/character and also warn player during gameplay..rather than waiting until instance will close.

"

StinkFinger wrote:

SO MANY DESYNC APOLOGISTS...

Holy hell it's pathetic...

Notice how they all have "supporter" next to their names...

No wonder GGG won't do shit to address the problem, they got a horde of lemmings throwing money at a broken game the whole time denying problems and defending flawed code...

The fuck is wrong with this world...

Errr... We are brainstorming solutions. We know its a problem... Can you read?