Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

"

Your insistence on the panacea of a "snapshot state" that is "continuously" streamed to the server is indicative of your lack of experience in real-time synchronization. Even if the client's entire state space could be packed into a format with insignificant encode/decode latency, those packets cannot be instantaneously transmitted from the client to the server. The discrepancies produced by your naive attempts to synchronize the server with latency-ridden data from the client would only exacerbate the inexorable drift between the two asymmetrical simulations.

The server's only role is to store/validate the state hash. It is not running a simulation in parallel.

If the server does not run its own simulation in parallel, it has no reference of its own to compare to the client's results. In that case, the "validation" you propose would merely be a rubber-stamp verification of the self-consistency of the data sent by the client. The server would be entirely reliant on the client to report all game results, and would have no way to distinguish between legitimate and hacked results.

"

If the server does not run its own simulation in parallel, it has no reference of its own to compare to the client's results. In that case, the "validation" you propose would merely be a rubber-stamp verification of the self-consistency of the data sent by the client. The server would be entirely reliant on the client to report all game results, and would have no way to distinguish between legitimate and hacked results.

Have you even read my posts? The server validates each state hash and updates the in-memory snapshot. It can validate each new state from the saved snapshot. It does not need to run a simulation because the client is doing that on behalf of it. Only when there is a lapse in state hash data does the server begin simulating using the saved snapshot.

"

qwave wrote:

"

I am going to call bullshit on this until you provide evidence of what you are claiming works

Evidence? Read all the links ive posted, or do research on using deterministic seeds for synchronization in online games.

You have posted no evidence what so ever to support your theory. You have posted things that tangentially touch similar topics in different areas with different end goals. But there is no evidence to support your theory.

Tantabobo, what part of 'my theory' needs 'evidence'? All parts of this proposal are using well-known concepts in the software industry.


Deterministic seeds are a well-known concept.

Server/client sharing deterministic seeds are a well-known concept.

A 'state hash' is a well-known concept.

The client sending a 'state hash' (input) to the server is already being done by PoE.

Validating a 'state hash' (user accounts, input, item link authentication, etc) is already being done done by PoE.



What part needs elaboration? I would be happy to go into further detail on any of this if you are having a difficult time understanding.

What would be better would be you showing some code demonstrating this

Oh wait

I've included numerous code snippets throughout my posts. It's not a difficult concept. What would you do with the code snippet anyway?

"

qwave wrote:

Tantabobo, what part of 'my theory' needs 'evidence'?


Deterministic seeds are a well-known concept.

Server/client sharing deterministic seeds are a well-known concept.

A 'state hash' is a well-known concept.

The client sending a 'state hash' to the server is already being done by PoE.

Validating a 'state hash' is already being done done by PoE.



What part needs elaboration? I would be happy to go into further detail on any of this if you are having a difficult time understanding.

This is exactly my point, you have taken individual concepts and thrown them together and just assumed that since they all work separately that they will all work in tandem.

Firstly, while seeds are well known and can be deterministic they are not used for what you propose them to be used for. In fact, how you propose to use them will simply not work.
Second, keeping a client and server always synced is an unsolved problem in computer science. There are really good models and things that work really well most of the time, but it is still an open problem. Look at NIST and how they keep their atomic clocks synced.
Third, yes. currently PoE does a state hash but you want to expand it and you provide no details on the increase in information required and how that will affect performance.
Finally, validating the state hash is what causes the desync to begin with. The client and server differ over what happened/should happen and we end up with a desynced state. You provide no details on how your solution will resolve this, GGG engineers have provided several examples where your solution will obviously not solve the desync issue and you so far have simply glossed over it stating that it will work fine. With no evidence, no real reason why.

"

qwave wrote:

I've included numerous code snippets throughout my posts. It's not a difficult concept. What would you do with the code snippet anyway?

No one has issues understanding what you are saying, we are saying that your concept doesn't work in reality

"

Firstly, while seeds are well known and can be deterministic they are not used for what you propose them to be used for. In fact, how you propose to use them will simply not work.

This is their ONLY purpose! They are seeds to generate random numbers in a deterministic manner. Why are you even posting this?

"

Second, keeping a client and server always synced is an unsolved problem in computer science.

Again, you have no idea what you are even saying. The server stays in sync because it is just a validator for the state hash. This is no different than when you log into PoE with your username/password.

"

Third, yes. currently PoE does a state hash but you want to expand it and you provide no details on the increase in information required and how that will affect performance.

I've already indicated the 'information required'. The player's input and a timestamp. The same stuff that the game is currently sending.

"

Finally, validating the state hash is what causes the desync to begin with. The client and server differ over what happened/should happen and we end up with a desynced state. You provide no details on how your solution will resolve this

I've provided full details on this, several times. Read my posts. Heck, I have even answered this question on the page before this one. The state hash does not differ with this system, unless the player is cheating.

"

qwave wrote:

"

Firstly, while seeds are well known and can be deterministic they are not used for what you propose them to be used for. In fact, how you propose to use them will simply not work.

This is their ONLY purpose! They are seeds to generate random numbers in a deterministic manner. Why are you even posting this?

Yes, but there is a reason why they aren't used to do what you are proposing to use them to do

Unfortunately because you have no clue what you are talking about, you don't know why deterministic random seeds aren't used for what you say they are being used.