Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

"

In practice, producing precisely deterministic results in a system of open-loop, asynchronous simulators is an extremely difficult challenge to either achieve or verify.

Again, this is why the snapshot state is continually streamed to the server. Thousands of games have built network architectures on top of deterministic simulations.

It's evident from your overarching generalizations that this is not an engineering challenge you have attempted to accomplish yourself. 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.

"

No offense qwave, but all of the stuff you are saying is high sky theory which does't work in practice, and in a lot of cases its apparent you don't completely understand what you are saying.

High sky theory? I've linked white papers, code, and provided detailed explanations on each component. Software developers implement these sort of systems on a regular basis.

"

Its practically impossible for the server to be completely deterministic in how the client calculates stuff (and more importantly, how the server perceives the client calculates stuff, things like packet loss may mean even if the client is correct, the server wont care)

A shared deterministic seed is used to provide completely deterministic state hashes. TCP packets provide guaranteed delivery, they don't get 'lost' like UDP packets, they will be resent when lost.

"

The amount of games that have 2 simliar states that have to be synced is actually incredibly rare in modern standards, mainly because internet has become so widespread and cheap, that getting low latency is a basic need, not a luxury nowadays.

Where are you pulling these statistics from? Anyway, from the get-go, the server would not be simulating the state, it would be overwriting the state from the hashes. If GGG wants to also perform a server simulation to improve state hash delivery in high latency situations, that's up to them, but it's not mandatory for this proposal.

"

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 it DOES want to run a simulation in parallel (that's up to GGG), then the client state hash can overwrite the server's state hash upon validation. They are not two asymmetrical simulations, the server is just acting as an authoritative cache of sorts.

The packet's time of arrival does not matter, as long as it falls with the leniency allowed by the server.

"

RogueMage wrote:

"

qwave wrote:

"

In practice, producing precisely deterministic results in a system of open-loop, asynchronous simulators is an extremely difficult challenge to either achieve or verify.

Again, this is why the snapshot state is continually streamed to the server. Thousands of games have built network architectures on top of deterministic simulations.

It's evident from your overarching generalizations that this is not an engineering challenge you have attempted to accomplish yourself. 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.

In any case this already happens, thats what a resync is, its ends the entire server state to the client so the client is forced to resync.

Thing is, the amount of data that is sent is insane, basically its the location of every mob on the map, what buffs they have, etc etc. You can continuously stream this data, and its never going to be instant

Long story short, GGG chose a shitty network model for the game, they should have gone with completely server side and maybe just have movement done client side (either that or use UDP for things like movement). Latency nowadays is so low that delay is hardly noticed, and many games that require just as much reaction time (i.e. DotA2) use this model, and they do fine

At the end of the day, an action taking slightly longer is not going to kill you because you get used to, and your brain predicts. Desync however will kill you, because its random, and it means you can't respond for seconds in time

"

qwave wrote:

A shared deterministic seed is used to provide completely deterministic state hashes. TCP packets provide guaranteed delivery, they don't get 'lost' like UDP packets, they will be resent when lost.

TCP is not deterministic, it has such high overhead that even though you may have a guarantee that you will receive the packets, and in order, you have no idea how long they will take

Again you don't know what you are talking about.

If you done basic level of networking at uni, you would know this

"

TCP is not deterministic

When did I say TCP packets were deterministic? The time that it takes them to arrive has nothing to do with any of this.

"

qwave wrote:

"

TCP is not deterministic

When did I say TCP packets were deterministic? The time that it takes them to arrive has nothing to do with any of this.

Yes it does, your argument only makes sense when you assume that everything is instant and time doesn't exist, which of course makes no sense

PoE doesn't happen to be a turn based game

"

Yes it does, your argument only makes sense when you assume that everything is instant and time doesn't exist, which of course makes no sense

You are a fountain of wisdom.

"

PoE doesn't happen to be a turn based game

Oh good, thank you for informing me of this. I formulated this entire proposal assuming that TCP packets arrived instantly and that PoE was a turn-based game.

"

qwave wrote:

Oh good, thank you for informing me of this. I formulated this entire proposal assuming that TCP packets arrived instantly and that PoE was a turn-based game.

Thats the only way your suggestion is going to work

I am going to call bullshit on this until you provide evidence of what you are claiming works, with the same amount of complexity that a game like PoE has to deal with

"

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.