Technical solution to eliminate desync in single-player sessions

remember complexity as well, qwave.

anything is possible to do deterministically (well almost :) ), but the true question is "at what cost?".

if the "cost" of one reproduction is "too much" by as much as a byte of extra data, or an extra millisecond of calculation - a thousand reproductions running simultaneously for a thousand users, will be one hell of a problem.

Okay, if I understand your current proposal correctly, you have both the client and server "playing the game", with the server acting mainly as a cheat-prevention mechanism. In order for this to work, the server must transmit RNG seeds to the client so they both keep running the same simulation Your first proposal had an elegant way of solving that particular problem - only transmit them during loading times.

If I understood correctly, your current proposal is to limit the amount of RNG seeds that you need to send. You seem to achieve this by the server forcing the client to maintain communication, so it doesn't have enough time to "predict the future" and get desirable outcomes(which I don't like in theory because cheaters with high-end setups will force GGG to introduce limits to the desync feature that will cut off players with lower-end setups, but maybe in practice the impact isn't that noticeable).

But what about the situation I meant in my first post? Death situations are something that the player might not be able to predict his way out of, but what about loot drops? If loot dropping is handled by the server, then you would still have massive desync issues when players kill mobs fast enough. Remember, your situation relies on the simulations running perfectly in-sync with each other. You would need to introduce some lag when loot drops(client waiting for server to finish validating the current state, then generating loot and sending it), which could be just as deadly as current desync(e.g. killing the minions of a really dangerous rare).


EDIT: Also, how much would these calculations slow down the client?

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.

"

But what about the situation I meant in my first post? Death situations are something that the player might not be able to predict his way out of, but what about loot drops? If loot dropping is handled by the server, then you would still have massive desync issues when players kill mobs fast enough.

Since loot drops do not effect combat/pathing, they will not impact the system at all. If loot caused effects or collisions, it would indeed interrupt the synchronization. As long as there is no loot that causes 'effects' while on the ground, then everything should be fine.

"

Also, how much would these calculations slow down the client?

These calculations will not impact the client performance. The mathematics involved with calculating things such as damage, critical strike, etc are menial compared to the rest of the game engine.

"

cryptc wrote:

The discussion of floating points makes me think about this:

Spoiler

Oh my, this made me laugh so hard. Thanks! :D

"

These calculations will not impact the client performance. The mathematics involved with calculating things such as damage, critical strike, etc are menial compared to the rest of the game engine.

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.

"

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.

No, the roundtrips do not exist. The client sends his snapshot (input/state) to the server. The server does not need to send a response if the state is valid.

"

qwave wrote:

"

But what about the situation I meant in my first post? Death situations are something that the player might not be able to predict his way out of, but what about loot drops? If loot dropping is handled by the server, then you would still have massive desync issues when players kill mobs fast enough.

Since loot drops do not effect combat/pathing, they will not impact the system at all. If loot caused effects or collisions, it would indeed interrupt the synchronization. As long as there is no loot that causes 'effects' while on the ground, then everything should be fine.

So the actual effect is loot simply dropping "a while" later?


Alright, another issue. You say that the client will keep sending snapshots to the server, I don't think the discussion has actually gone into detail how they would be implemented. What if the two computers have timing mismatches(e.g. the client's clock is faster than the server's, for whatever reason) - wouldn't that make the game unplayable for the client, since its information would almost always be *wrong* when the server tries to apply it(since the timing on its decisions would be off by a bit)? I suppose you'd have to implement some sort of synchronization mechanism, where the server and client make sure their timings are in sync? I admit I don't actually know much about timing issues, so this might be a moot point.


I'd like to also note that your point IV - Is this offline play? doesn't mention that once you have such a client, offline play wouldn't be too hard to implement.

"

I suppose you'd have to implement some sort of synchronization mechanism, where the server and client make sure their timings are in sync?

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.

qwave is trying to cure path of exile from its disease





ITS HAPPENING