Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

"

qwave, your example "player said he dealt 1284 damage, but the server arrived at 1283.4" is a bit simplistic. The rounding error of a small difference, over a large amount of calculations might mean a difference of several hundred in damage, so setting the leniency is not possible for the final calculation result, only for each calculation. And that would require the client to send each intermediate result.

The client needs to send just enough explicit data to allow the server to gather the implicit values and arrive at the same numbers. Depending on the number of GGG's calculations, the client may or may not need to send additional data.

How did you counter the pathing desync argument? ie you attack a monster on one side of a rock but pathing around the rock client vs server is different.

Baxta: The client would include his movement in the snapshot. The server would validate the path by simulating it from the state of the last received snapshot. You would no longer desync because the server now has perfect knowledge of your path, rather than predicting it.

Currently the server tries to guess where you are, which causes desync.

Even more awesome is that the client would be smart enough to send enough pathing data to the server that the server can infer how it moved around obstacles. The current server does not predict obstacle avoidance because it uses collision checks against straight pathing segments.

This means that you could run through dungeons and around obstacles with ridiculous movement speed and you would not desync! =)

Oh yeah, and you could make that leap slam build that you always wanted to.

"

qwave wrote:

Currently the server tries to guess where you are, which causes desync.

That's not how desync works.

The server doesn't guess. The server knows.
The client tries to guess where you are.

"

qwave wrote:

Baxta: The client would include his movement in the snapshot. The server would validate the path by simulating it from the state of the last received snapshot. You would no longer desync because the server now has perfect knowledge of your path, rather than predicting it.

Currently the server tries to guess where you are, which causes desync.

Even more awesome is that the client would be smart enough to send enough pathing data to the server that the server can infer how it moved around obstacles. The current server does not predict obstacle avoidance because it uses collision checks against straight pathing segments.

This means that you could run through dungeons and around obstacles with ridiculous movement speed and you would not desync! =)

Oh yeah, and you could make that leap slam build that you always wanted to.

Nothing "guesses" really with pathing. They have some sort of engine (also subject to floating point number issues)

More data would help the logic but more data = more problems and still would cause syncing issues.

My poor flicker strike/cyclone scion :(

"

I don't see how the server can know where the error occurred. It has one start point, one (suspect) end point, but all you can do is run the simulation forwards and see that it doesn't match what the client has. You can't just switch over to the client's values and run it backwards. That doesn't tell you anything. Besides, some calculations CANNOT be run backwards, because there are multiple inputs with the same output, etc.

The server doesn't need to know WHERE an error occurred, it only needs to know that a significant enough error occurs in the ->outcome<-. The outcome is what the server needs to validate. (The player did 100 damage, can I reproduce this deterministically with X lenience?)

You never run it backwards. You start from the last snapshot and simulate the action that the player says he performed. The player says he performed 'heavy strike'. Your server performs heavy strike from the last snapshot while simulating the entire state (mobs are attacking, moving, etc). Does your heavy strike value fall within the lenience of the explicit value? If so, validate and save this snapshot.

"

Also, I wonder why is your "lockstep synchronization" solution so different to what other games do? All the others seem to say that you need to sort out the FP determinism to make it work (unless you rely on resync packets). No-one else has error-correcting like this.

I have used this solution on an application I wrote recently in the transportation industry for a client. They have transports which go 'in and out' of network coverage and send data that needs to be corrected/validated. There are times that the data is invalid because of the way GPS tracking works. We can infer errors based on the explicit values. We can also discern their implicit path based on the missing data as well.

You may not find exact citations for this in the gaming industry, but it is used in numerous industries that need to validate disconnected client data. Many peer-to-peer games use a very similar method for validation as well.

If you can solve the issue of desynch, i suggest you contact GGG through email. The forum is hardly the place for this.
Request thread lock.

"

qwave wrote:

It's like a crossword puzzle. If the client sends enough state, the server can easily fill in blanks to evaluate whether the state is authorized.

You would be amazed at how much you can actually optimize this. Suddenly you start to discover that all your calculations can be done by the client and server with very little exchange. The implicit values fill themself in automatically.

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?

"

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. With the proposed system, the client does not need to wait. This can actually eliminate the effect of latency, which is key in producing responsive gameplay.

The discussion of floating points makes me think about this: