Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

"

RogueMage wrote:

In this case, there are no "encrypted passwords" for the server to decrypt and validate. The only things that are "deterministic" about the random number seeds are the emergent game simulation results they produce. The only way for the server to "validate" the client's results as legitimate is to reproduce its own simulation of the game session. That time-shifted, open-loop simulation would be subject the same timing discrepancies that a real-time simulation would incur. Such a system would be incapable of producing reliable results.

Yes, the server validates the state hash by performing a simulation of it against the current in-memory snapshot. This would be around 1 second of simulation. It is not going to experience any timing discrepancies because of the short segmented simulations.

"Around 1 second"? On what engineering experience with open-loop, real-time simulator synchronization would your guesstimate be based? Any programming experience on commercially published game titles you'd care to mention?

"

"Around 1 second"? On what engineering experience with open-loop, real-time simulator synchronization would your guesstimate be based? Any programming experience on commercially published game titles you'd care to mention?

The server performs a simulation of the delta since the last state hash. This is the amount of time since the last packet, which is up to GGG and the interval that they feel is optimal. Any value they choose is up to them. Latency also plays a role in it of course, but again, that's why it uses a delta.

I have been a software engineer for around 12 years now. But I don't see why my credentials matter in this conversation.

"

qwave wrote:

"

RogueMage wrote:

"Around 1 second"? On what engineering experience with open-loop, real-time simulator synchronization would your guesstimate be based? Any programming experience on commercially published game titles you'd care to mention?

The server performs a simulation of the delta since the last state hash. This is the amount of time since the last packet, which is up to GGG and the interval that they feel is optimal. Any value they choose is up to them. Latency also plays a role in it of course, but again, that's why it uses a delta.

"

Rhys wrote:

I strongly suspect that Roguemage is correct. The system is absolutely dependent on two massive simulations running in parallel that need to be exactly the same. Small, inevitable errors from floating-point calculations will cause desync. I am very skeptical on creating a system that relies so heavily on determinism when floating-point arithmetic is inherently non-deterministic.

"

qwave wrote:

"

"Around 1 second"? On what engineering experience with open-loop, real-time simulator synchronization would your guesstimate be based? Any programming experience on commercially published game titles you'd care to mention?

The server performs a simulation of the delta since the last state hash. This is the amount of time since the last packet, which is up to GGG and the interval that they feel is optimal. Any value they choose is up to them.

So either you run a simulation constantly for every client every time it receives a packet while predicting time based delay is going to take one second, lolz? When IEEE standard has no absolute definition of deterministic results for floating point arithmetic

That's even stupider than using hashing

RogueMage, he posted that before he realized that the server is not running a parallel simulation. I have explained since then that the server only needs to perform a delta since the last state hash.

deteego: It's obvious that you are just trolling at this point. I am not replying to any more of your posts until you read and understand the main post. You have yet to make a single coherent reply that illustrates any understanding of the situation. You are just taking random words you've seen in the conversation and then trying to form sentences out of them.

If you understood IEEE standard for FP precision you would realize your idea is balony

"

Daxtreme wrote:

Can you guys wait for the next GGG answer instead of arguing pointlessly? It seems clear to me that the OP has somewhat of an idea of what he's talking about, or else the discussion would have ended way before. So let GGG decide if it's worth something or not?

That would be much more constructive than the last like 4 pages which were mainly double posts and arguing.

You are right, it is pointless to try and argue with the OP. GGG has made it clear repeatedly why his system wont work and he has outright ignored their statements. GGG will never do something like this at it simply doesn't do what the OP thinks it will. The OP has no idea what he is talking about, if he had any idea of what he was talking about he would of never posted this idea to begin with.

No company is going to introduce a system where-by a rounding error (appears as though the client was cheating) would wipe out what a customer had done over what could be a long play session if they took a long time on their map. Of course, this was later changed to being more continuous after GGG pointed out how it would never work in blocks that large. The smaller the block, the more desync. (a point that Qwave has failed to grasp, though perhaps I failed to explain it well enough)

He is using a random seed that has been sent to the client to generate the content, completely ignoring the amount of computational power that is needed to do this. Further increase loads on client systems for what many claim is an already non-performent game. He claims that it will change so often that it will be hard to hack, yet he also claims that this will cause no extra burdens on the server. Because clearly physics changes when dealing with computers and more work doesn't create extra server load.

He states that crafting/looting do not cause desync. Which GGG has pointed out is not always correcct. There are a number of scenarios that they can cause desync. The OP flat out disagrees with GGG over this. Because clearly, they don't know their game.

Finally, GGG has pointed out that do to synchronization issues (which I have pointed out is an open problem still) it is still possible for deaths to occur/be avoided around even his large map based sync times. Again, the OP has flat out rejected this possibility.

So again, you are right, it is pointless to argue further.

"

GGG has made it clear repeatedly why his system wont work and he has outright ignored their statements.

No, Rhys_GGG have been exchanging posts / counter-posts. This is how software development gets done. The proposal is evolving to a working state. I have provided answers to each of his queries, and we are down to 3 remaining issues that I have recently responded to. Solving desync is not something that can happen with a single post, it is going to take a discussion and an evolution of ideas. I have compromised on several points in order to come to a solution. (for example, projectile range)

"

No company is going to introduce a system where-by a rounding error (appears as though the client was cheating) would wipe out what a customer had done over what could be a long play session if they took a long time on their map.

A. I have proposed leniency on floating point math. Problem solved.

B. The server stores a persistent snapshot, so progress is saved in realtime. Where are you getting these ideas from?

"

He is using a random seed that has been sent to the client to generate the content, completely ignoring the amount of computational power that is needed to do this.

There is no computational power required to generate random numbers. You can generate billions per second, it will not effect performance, even on a mobile phone.

"

He states that crafting/looting do not cause desync. Which GGG has pointed out is not always correcct. There are a number of scenarios that they can cause desync. The OP flat out disagrees with GGG over this. Because clearly, they don't know their game.

I stated that crafting should be done using the current system because crafting does NOT cause desyncs. This proposal is strictly related to combat/pathing.

"

Finally, GGG has pointed out that do to synchronization issues (which I have pointed out is an open problem still) it is still possible for deaths to occur/be avoided around even his large map based sync times. Again, the OP has flat out rejected this possibility.

Rhys_GGG said this was no longer an issue. Read his last post.

"

There is no computational power required to generate random numbers. You can generate billions per second, it will not effect performance, even on a mobile phone.

That statement right there proves my entire point. You have no idea what you are talking about.

Okay, 40 million random numbers per second, fair enough? The PoE client will need to generate around 1000 per second. I think it can handle that. My point is, performance with this new proposal is not going to impact the game. Generating random numbers is extremely inexpensive.

Here's a white paper for you:

http://www.cs.ucsb.edu/~koc/ns/projects/12Reports/KarlLopker.pdf

And this is 40 million random numbers per second on a machine weaker than a cell phone. I used the term 'billions' because most of us have PCs that are better equipped than cell phones.