Technical solution to eliminate desync in single-player sessions

waste of time you know?

"

qwave wrote:

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.

Can you stop pulling numbers out of your rear behind?

Double post

"

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:

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.

Regardless of the open-loop delta period, the solution you propose is equivalent to having the server run a time-shifted game simulation of its own in order to generate a reference to compare to the client's results. Along with Rhys, I am highly skeptical that such a scheme could be engineered to produce a system that was both reliable and unhackable. Rhys' game development credentials are self-evident. My own judgment is based on a 30-year career in commercial real-time audio and video game programming, and in this particular case, on experiences developing the online game synchronization system for Acolade's "Ballz" fighter simulation on the Sega Genesis.

I'd be most interested to hear of your own relevant experiences in this field of the game development industry.

"

Regardless of the open-loop delta period, the solution you propose is equivalent to having the server run a time-shifted game simulation of its own in order to generate a reference to compare to the client's results. Along with Rhys, I am highly skeptical that such a scheme could be engineered to produce a system that was both reliable and unhackable.

What part are you skeptical about? The server is already doing this. My proposal does not change that fact. Currently, the server keeps an in-memory simulation which it updates as it receives input from the player. With my system, it also keeps an in-memory simulation which is updates as it receives input from the player.

I believe that Rhys was skeptical because he didn't realize the server was updating from the delta of the last snapshot. I think that's a pretty large misunderstanding.

"

I'd be most interested to hear of your own relevant experiences in this field of the game development industry.

Even if I told you, why would you have reason to believe me? I could type any profession I wanted. I've provided answers to each and every query on this forum. I have answered extremely technical programming questions and even provided source code on several occasions. I am a senior software architect and operate my own company in the cloud computing / online gaming industry. But even if I was a plumber, I believe ive exhibited that I know what im talking about.

"

qwave wrote:

"

Regardless of the open-loop delta period, the solution you propose is equivalent to having the server run a time-shifted game simulation of its own in order to generate a reference to compare to the client's results. Along with Rhys, I am highly skeptical that such a scheme could be engineered to produce a system that was both reliable and unhackable.

What part are you skeptical about? The server is already doing this. My proposal does not change that fact. Currently, the server keeps an in-memory simulation which it updates as it receives input from the player. With my system, it also keeps an in-memory simulation which it updates as it receives input from the player.

Your proposal would eliminate the crucial part of the system that keeps it both reliable and unhackable: client resychronization updates imposed by the server. Without that mechanism, the remaining options are to either trust the client, or abort any client game session whose results diverge from the server's.

Let me explain qwave's game to everyone who hasn't caught on yet:

Whenever anyone tries to push him about how his system wouldn't be secure, he keeps on coming up with more and more checks which the server could use to validate the client's actions and ensure it isn't cheating.

Whenever anyone tries to push him about how his system would cause desync between the client and the server, he keeps on coming up with more and more ways in which the client could handle everything on its own, independent of the server.

Essentially, qwave is so committed to his stupid idea that, rather than pinning it down and defining it rigidly, he is trying to occupy several mutually exclusive positions at once, hoping that we treat his idea in the same way as Schrodinger's cat, unsure if it's alive or dead, and instead take it on faith that his solution will do what he promises it will do.

But in reality, there's no way for him to provide the same amount of security, without also providing the same amount of network communication — and thus, unless the means of communication itself is improved, the same amount of desync. And if the means of communication itself was improved... there would be no need for his suggestion, as desync would already be fixed. His point could not be more moot; there's no point in arguing with him further.

"

Your proposal would eliminate the crucial part of the system that keeps it both reliable and unhackable: client resychronization updates imposed by the server. Without that mechanism, the remaining options are to either trust the client, or abort any client game session whose results diverge from the server's.

Resync would occur in two situations:

- The client sends values that are not within the lenient range of the deterministic seed. This will generally only happen when the client is hacking.

- The client does not send a state hash within a lenient amount of time. This will happen if the client has huge latency / lag.

If I recall, didn't D2 have that failsafe of disconnecting players that the server did not agree with?

"

Whenever anyone tries to push him about how his system wouldn't be secure, he keeps on coming up with more and more checks which the server could use to validate the client's actions and ensure it isn't cheating.

The server only needs to perform the same checks that it currently does. I have never changed this.