Technical solution to eliminate desync in single-player sessions

"

SkyCore wrote:

The way i see it: in the games current state there is a lot of back and forth communication between the client and the server, since the server is virtually always out of synch with the client they regularly dont agree, when this happens the server asserts the game state resulting in rubberbanding and such.
With the propsed model this is as a whole eliminated since the server is basing its calculation on what the client has already done, here the client asserts the game state at all times. except when cheating is detected via an impossible action reflected in a snapshot.

"

LogoOnPoE wrote:

"

SkyCore wrote:

The way i see it: in the games current state there is a lot of back and forth communication between the client and the server, since the server is virtually always out of synch with the client they regularly dont agree, when this happens the server asserts the game state resulting in rubberbanding and such.
With the propsed model this is as a whole eliminated since the server is basing its calculation on what the client has already done, here the client asserts the game state at all times. except when cheating is detected via an impossible action reflected in a snapshot.

Pretty much this. Under the proposed system, desyncs would only happen if the client tries to cheat, or if there is a bug.

Also, i have to apologize to you SkyCore, for suggesting ignoring you. It seems a misunderstanding can really put a negative attitude and derail a thread.

"

gonzaw wrote:

GGG, why don't you make PoE open source so qwave can code all of this himself? :P

"

Yes Fixed-point math can alleviate some of these problems, but that is not always an acceptable solution (there are drawbacks to this approach as well which are well documented and do not need to be discussed here)

"

but it now also has to verify at every step

"

The client is not in full control it still relies on the server for information about drops and gear (possibly a few other things as well). Changes to any of these are points of potential desync. For anyone that has raced, changing gear while moving/fighting is common place.

"

This is a single-player only solution that does not work at all with a multi-player model. This alone means that it is not a good solution for the game as a whole.

"

DestroTheGod wrote:

"

gonzaw wrote:

GGG, why don't you make PoE open source so qwave can code all of this himself? :P

Nobody would do this work for free. Nobody.

"

Dreamer000 wrote:

Instead of thinking of why it can't work, try to figure out how it could work.
Maybe then we can come up with a solid solution.
We all want the same thing here, being negative and facepalming every idea doesn't help.
Instead start with an imperfect/unfinished idea and and... improve upon it.

"

Tantabobo wrote:

He has proposed a simple verification engine. Whereby the client is non-trusted and thus a second party (the server) is tasked with verifying all results. This is indeed a simple solution to think about, but it is far more complex to actually implement as it requires not only running the entire simulation as it normally would, it also has to at every stage check it against what the client did. The difficulty is directly associated with how often you have to check values (is it at every stage of a damage calculation or only against the final value, for instance) GGG eluded to this in a previous post.

This having to verify that the client is correct is where the issue of FP math comes into play and why it matters that the numbers be accurate. Yes Fixed-point math can alleviate some of these problems, but that is not always an acceptable solution (there are drawbacks to this approach as well which are well documented and do not need to be discussed here). The proposed "variance" to get around this problem can only occur if the verification points are sufficiently small so that only 1 calculations worth of error can be introduced otherwise the client will invariably always be at odds with the server. Or the variance has to be so high that cheating becomes realistic.

Further, this system, despite what the OP believes, is actually more work on server as it now has to run the entire simulation as before, but it now also has to verify at every step. I would argue that the client and network load would also increase, though the amount is unknown.

The client is not in full control it still relies on the server for information about drops and gear (possibly a few other things as well). Changes to any of these are points of potential desync. For anyone that has raced, changing gear while moving/fighting is common place.

This is a single-player only solution that does not work at all with a multi-player model. This alone means that it is not a good solution for the game as a whole.

Finally, the question of how this eliminates desync is answered by: "It doesn't. What it actually does is alter the users perspective such that desync is no longer as apparent and jarring in most cases of client/server disagreement." The argument only cheaters will desync is naive, as any number of conditions can cause the verification to fail between the client and the server.
Would this proposal reduce desync? Yes.
Is it a cost effective solution? Likely, no.
Is it a good solution for the longevity of the game? No (like it or not this is not a single player stand alone game. Implementing a costly solution that only affects one part of the games population will alienate the other. This is NEVER a good thing for a game.)