Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

johnKeys: This proposal significantly reduces the overhead of the communication process. I believe that they will be able to cut their bandwidth requirements in half for the game sessions which use this strategy.

This is because the client is sending highly compressed snapshots, and the server does not need to respond with state anymore.

Not to half to 1%. The input of the client to the server is about the same (maybe a little bit increased). But the output of the server is \epsilon. Theoretically, all the server needs to give is an initial rng seed and info about loot, craft, and vendor recipes (some of them must be serverside only becaouse they are secret).

Practically, it is more convenient to send more than an rng (a new rng seed each x seconds, with some buffer) to prevent the cheater to multiple calculate/rewind an entire game session without being connected. This is still \epsilon% of server output bandwidth with respecto to now.

Of course it is a massive pain for developers to turn the game to deterministic. If GGG choose to follow this way, i do not expect any result before PoE2.0. But IT IS THE ONLY WAY to solve the desync bug for single player, and to turn to very acceptable levels in multiplayer.

"

qwave wrote:

"

How is this a feature exclusive to hosting the primary gamestate on the client? Couldn't you achieve this by continuing to host the primary gamestate on the server, having the client send virtually nothing (just inputs), and then having the server send enough state for the client to easily fill in the blanks?

If filling in the blanks with limited state-sending is really so easy, why isn't it already happening?

The problem with this is that you have to wait a full round-trip from the server. Anytime the client is unable to perform the calculation on its own, it has to wait for a response.

Why would it need to wait? Why would the client be unable to perform the calculation on its own?

The crux of your argument is: have the server share the random seed with the client prior to rolling RNG, and then the entire gamestate becomes deterministic with the sole exception of user input, allowing both to be on the same page. This has security risks, which I've previously mentioned, but I understand there is a tradeoff in enhanced client-side gamestate prediction, no longer having to wait on server-side random number generation; but that's not what I'm asking about.

What I don't understand is why you insist on the server playing second fiddle to the client, verifying all of its calculations as legitimate in the (hopefully rare) instance of a disagreement, when it would be so much easier to just have the client accept the results of the server's calculations when such an event occurs.

"

qwave wrote:

For one, the server can review the 'delta' of each snapshot (the amount of time that has PASSED since the last snapshot). Timing problems are generally so miniscule that they do not manifest in the delta. Also, the server is able to provide leniency on certain values calculated by floating points.

But the whole premise of the suggestion - the client and server *can* maintain perfect synchronization depends on this. It seems to me that if you could guarantee this, then your proposal is wholly feasible and worthy of consideration(although I don't think GGG would implement it, because it still doesn't tackle multiplayer). But if it's not feasbile(due to such issues), then you wouldn't have cured desync at all, simply made gameplay smoother at the cost of much sharper resyncs.

"

Baxta wrote:

So we're still stuck on pathing and client server sync.

@Rhys Can you give an explanation on the pathing system?

@qwave I still for the life of me can't understand how your solutions reduce desyncs. These "roundtrips" will still exist except you are calling them snapshots.

That's because several pages ago the thread was glitched by a massive desync caused by qwave's inability to comprehend Rhys' last post. The thread is now a dead man walking, slowly expiring from a DoT that the OP has not yet rewound.

Have not read 60 pages, nor gonna do it; all I am gonna say that the degree og desync people with good lines and connections are experiencing in this game, is borderline ruining the game. With the state of the game I can not understand people that want to play hardcore.
I hope GGG can look into the problem, and at least make it less of a problem.
From my experience playing Euro servers, and I am pretty sure it is directly linked to number of players in the game. In low pop hours the problem normaly is smaller.

"

What I don't understand is why you insist on the server playing second fiddle to the client, verifying all of its calculations as legitimate in the (hopefully rare) instance of a disagreement, when it would be so much easier to just have the client accept the results of the server's calculations when such an event occurs.

It's much easier for the client to push data to the server in intervals without expecting anything in return. This means the client can continue to kill monsters without ever receiving any data from the server saying that its 'okay'.

"

But the whole premise of the suggestion - the client and server *can* maintain perfect synchronization depends on this. It seems to me that if you could guarantee this, then your proposal is wholly feasible and worthy of consideration(although I don't think GGG would implement it, because it still doesn't tackle multiplayer).

They can remain in sync because the client defines the synchronization and the server's only role is to say, "Yeah, thats alright" or, "Nope, im calling bs on that.".

If they tackle this for single-player sessions then I will explain to them how to apply it to multiplayer sessions (although I know they are smart enough to figure it out after applying these techniques). But that's a much bigger ball-game, and you have to fix one thing at a time.

I just want to say, and agree with most people..

They need to fix it to the point where it's barely noticed.
Ive seen some really big desyncs and for competive play (Ladder, n races)
It's a factor that's going to ruin the game.

I wouldn't mind to drag my friends into PoE, but I doubt anyone of em
is going to be excited about going HC when you can die to something like desync.

"

qwave wrote:

"

What I don't understand is why you insist on the server playing second fiddle to the client, verifying all of its calculations as legitimate in the (hopefully rare) instance of a disagreement, when it would be so much easier to just have the client accept the results of the server's calculations when such an event occurs.

It's much easier for the client to push data to the server in intervals without expecting anything in return.

How is that any easier than pushing input data to the server as it occurs without expecting anything in return?

"

qwave wrote:

"

But the whole premise of the suggestion - the client and server *can* maintain perfect synchronization depends on this. It seems to me that if you could guarantee this, then your proposal is wholly feasible and worthy of consideration(although I don't think GGG would implement it, because it still doesn't tackle multiplayer).

They can remain in sync because the client defines the synchronization and the server's only role is to say, "Yeah, thats alright" or, "Nope, im calling bs on that.".

How is it that they remain in sync when the client defines the synchronization, yet do not remain in sync when the server defines it? How is it somehow worse when the client's only role is to send mouse clicks and keyboard presses, and to say "Yeah, that's right" or "Oops, made a mistake there, let me fix that"? The server remaining in sync is important for security, which is something you seem to remember at times and forget at others.

"

How is that any easier than pushing input data to the server as it occurs without expecting anything in return?

That's exactly what the client would be doing. It needs to send the minimum amount of input/data that the server can validate that it is not cheating. The server needs enough data to completely simulate the client's actions perfectly. If that's only the input, then so be it. The client should be able to play the game without the server constantly responding to it.

"

How is it that they remain in sync when the client defines the synchronization, yet do not remain in sync when the server defines it? How is it somehow worse when the client's only role is to send mouse clicks and keyboard presses, and to say "Yeah, that's right" or "Oops, made a mistake there, let me fix that"? The server remaining in sync is important for security, which is something you seem to remember at times and forget at others.

Because in the current system, the server is performing predictions. In the proposed system, the server is performing validations.

"

qwave wrote:

It's much easier for the client to push data to the server in intervals without expecting anything in return. This means the client can continue to kill monsters without ever receiving any data from the server saying that its 'okay'.

This is patently dangerous.

If you can't see why, then it is pointless to argue with you.