Technical solution to eliminate desync in single-player sessions

Tantabobo: That's not a performance problem. I thought we were discussing RPG calculations being too expensive for your processor to handle.

"

HellGauss wrote:

"

SkyCore wrote:

Precisely how would the server validate snapshots in your current design?

In a similar way that a chess player validate the b4-b5 move: if you have pawn in b4 and nothing is in b5 and your king is not checked, then your command is valid.

I cast fireball: do i have fireball gem? do i have enough mana? Am I stunned? Etc....

In order to do so the server would need to construct the gamestate. In this current design, the server does not maintain a mirrored copy. If it did, then desynch would still be an issue(see on the last page my post about los requiring exact positions)

LogoOnPoE: I think my work here is done. You can take over from here, haha.

"

In order to do so the server would need to construct the gamestate. In this current design, the server does not maintain a mirrored copy.

The server keeps the last state that was sent to it. It verifies using a delta between the last state and the new state.

It persists this into a full snapshot of the instance state. So yeah, it's a 'mirrored copy' of sorts.

The most important thing is that the server has just enough data to have the authority to validate the state. Each snapshot from the client is an atomic transaction that the server must approve. The server's only role is to act as a referee and not to help the client 'synchronize'.

"

qwave wrote:

Tantabobo: That's not a performance problem. I thought we were discussing RPG calculations being too expensive for your processor to handle.

Not going to get into a discussion about how this problem actually was a performance issue in the end (as the machine would not crash, it would simply give inconsistent results).

My prior point still stands. You have no basis for your statement that the client will not see an increased load that will further degrade performance for people who already complain about poor performance.

I am not even arguing that it will cause a problem, merely that you can't prove that it won't.

"

qwave wrote:

"

The problem with D2 was that items were being created in parallel to the destruction, as far as I could tell from an end-user perspective and it was sensitive to latency and multi-threading weaknesses in the code when it comes to verifying the object has been destroyed before re-creating it somewhere else.

You are correct. Item duping frequently occurs as a 'race condition' due to poor managed locks and mutexes involved with multi-threading or distributed computing.

Duping is rarely a problem nowadays because game developers are more aware of the conditions that cause it.

I wouldn't say it is not a problem if the solution makes the game barely playable.

Pretty much any ability which moves your character or erratically increased animation speed is not viable from a hardcore point of view. A friend of mine laughably put multi-strike on leap slam and he just vanished like he had a teleport spell, that can be fatal. And by vanishing he was moved to part of the map it was pretty much inconceivable that he would have got there in that period of time.

"

I am not even arguing that it will cause a problem, merely that you can't prove that it won't.

If my answer isn't good enough for you, then don't ask me the question in the first place.

"

qwave wrote:

LogoOnPoE: I think my work here is done. You can take over from here, haha.

"

In order to do so the server would need to construct the gamestate. In this current design, the server does not maintain a mirrored copy.

The server keeps the last state that was sent to it. It verifies using a delta between the last state and the new state.

It persists this into a full snapshot of the instance state. So yeah, it's a 'mirrored copy' of sorts.

So each snapshot which is sent once a second contains full gamestate? That seems awful.
And exactly whats your method for determining the delta between states? Such a thing would be one of the most complex formulations ever attempted by mankind. I doubt if every mathematician on earth spent 20 years developing optimizations that it would be feasible. And the server is expected to do it once a second, for each client connected?!

"

So each snapshot which is sent once a second contains full gamestate? That seems awful.
And exactly whats your method for determining the delta between states? Such a thing would be one of the most complex formulations ever attempted by mankind. I doubt if every mathematician on earth spent 20 years developing optimizations that it would be feasible. And the server is expected to do it once a second, for each client connected?!

Each snapshot contains the client's actions since the last snapshot (or whatever GGG determines is important).

The delta is definitely the most complex formulation ever attempted by mankind. It involves the subtraction of the new timestamp from the previous timestamp. And subtraction is super difficult.

"

qwave wrote:

"

I am not even arguing that it will cause a problem, merely that you can't prove that it won't.

If my answer isn't good enough for you, then don't ask me the question in the first place.

My position is that your given answer is insufficient for the statement. So I asked for clarification on how you arrived at it.

"

My position is that your given answer is insufficient for the statement. So I asked for clarification on how you arrived at it.

I arrived at it by being a software architect and understanding how long it takes to crunch numbers. Seriously, nothing I say is going to satisfy you. Go play PoE or something.