Technical solution to eliminate desync in single-player sessions

"

I would delay all my packets by two seconds. One second for human reaction time, one second to enter the portal.

Crappy internet connections happen. Can't blame me for having 2000ms ping. I'm probably leaving all my torrents on since lag doesn't impact me anymore.

In laggy situations like this, the server will perform the simulation in your behalf (based on the last received snapshot) to prevent cheating and re-sync you. If you have 2000ms of ping, you are going to have desync issues, period. =(

"

qwave wrote:

The nature of the proposed changes primarily involve calculations involving combat, pathing, and map generation. This type of code is not as volatile as you suggest if they've followed good design patterns, and should not introduce a 'mountain of issues'.

It definitely would introduce a mountain of issues. Changing calls to point and play nice with windows dlls are 1 of many examples

"

I'm basing it on my experiences as senior software architect. From the get-go, I have stated that I am not an expert on this particular topic, but I am offering whatever knowledge I can in order to help facilitate a solution. I think this is far more constructive than complaining that a problem exists.

I find this very constructive and the high level thought you are giving it is refreshing! More people should put forward their helpful ideas like this.

Your idea is ok in theory but from a development point of view, an absolute nightmare to implement correctly.

Code bases can be maintained perfectly and still be unable to easily move to client-side. I'm going to stop arguing with you though and wait(and hope) for a more technical update as to where they are with this issue because I think we need a bit more info to continue.

"

Your idea is ok in theory but from a development point of view, an absolute nightmare to implement correctly.

In most cases, it's not a nightmare to move some calculation code to the client. For example:

1. Database calls/dependencies. For example, if they need to perform a database lookup for a particular routine. This is uncommon for the types of changes im describing because mechanics like this would be cached in an in-memory repository.

2. Logging and error handling is typically done using aspect oriented programming or dependency injection. So you can usually move code without too much impact, because the client would have its own logging handlers.

3. Content generation. This part is a bit trickier, particularly for the map data and generation because it may be heavily coupled with server-side routines. For example, they may be generating content based on certain factors that they do not want the client to know.

"

Code bases can be maintained perfectly and still be unable to easily move to client-side.

You are right, I am not disagreeing with you. I am offering a solution to their desync problem, but their architecture may be too fragile/heavily coupled in order to implement it.

"

Baxta wrote:

[...]

Code bases can be maintained perfectly and still be unable to easily move to client-side. I'm going to stop arguing with you though and wait(and hope) for a more technical update as to where they are with this issue because I think we need a bit more info to continue.

I am positive about GGGs efforts but I honestly doubt that they will tell us something new.

I would shit bricks and buy some nice Christmas MTX if they prove me wrong thou. :D

"

qwave wrote:

"

I would delay all my packets by two seconds. One second for human reaction time, one second to enter the portal.

Crappy internet connections happen. Can't blame me for having 2000ms ping. I'm probably leaving all my torrents on since lag doesn't impact me anymore.

The server will perform the simulation in your behalf in laggy situations like this to prevent cheating and re-sync you.

Define laggy.

I'll find the bounds. I'll get just below them and start injecting packets if I detect I died in that timeframe.

If not portals then I'll spam movement skills to previously recorded player positions to get out ASAP before faking a disconnect or faking a portal. Sure, I may still die in some situations. But if I can avoid even one death then it's a win and you can't prevent that.

The idea described by OP is actually the state of the art for online games when the game complexity exceed a certain threshold (PoE does exceed this threshold).

Desync is caused by the large amount of data the client needs to represent and update the gamestatus. Furthermore the client needs this data in realtime, or as soon as possible.

With current implementation the server needs to give EACH monster position/actions, combat results, drops and effect of orbs, etc... It is simply too much. The client needs only to send commands, but it does not know the effect of its commands.

The proposed solution works well because it can works both on the amount of data and on the time this data is send.

The quantity of data sent by the server would be reduced to a 128bit rng seed each few seconds. Furthermore this data can be send a few second before it is needed: the server can say that at times t+3seconds the rngseed WILL be X, since this seed does not depend on actions. In the current system, it cannot say that a t+3 the monster will move at y, since this actions depend also on the player behaviour.

Effect of orbs of items and loot drop should still be handled serverside, to prevent some dangerous cheating. In this framework the client cannot cheat, because it is allowed only to send commands, as it is with current implementation.

How to handle multiplayer:
I think GGPO technique with this framework should work fine. It would allow immediate response of the client with a minimal impact on desync/resync, providing that the logic of PoE can be simulated several time faster than realtime (with current multicore CPU, i do not think think that PoE mechanics is so complicated). Some minor security issue must be handled to prevent malicious player to send fake informations to other players. If a new player enters an istance, either send a complete snapshot of the gamestatus, or the list of commands from the beginning of the instance (whichever requires less data).

GGG objection to this method.
Even if the clients cannot cheat, it needs a lot of info on how the game works. This could be exploited by using a bot which calculate and perform the 'best' possible action. This is true, and GGG fear also that a single mistake in the design could destroy a legue. However i think it is a risk that a good game developer should take. When astronauts goes in to rockets, they risk even more if something goes wrong.

Consider also that this kind of cheating would not impact on the economy, because loot and effects of orbs are still syncronous. Also consider that some cheating is available today: for example i could write a macro that drink a life potion whenever i go to low-life.

HellGauss: Great post! I am indeed describing a proven solution that many game developers are currently leveraging.

"

Even if the clients cannot cheat, it needs a lot of info on how the game works. This could be exploited by using a bot which calculate and perform the 'best' possible action.

By adding some cryptographic salt/hash to the random number generator, it can be made computationally infeasible for a bot to produce desirable outcomes. Moreover, I can wholeheartedly so that the state-of-the-art in the MMO botting industry is not even close to producing bots of this calibre. Botfarms run on extremely low-end hardware because it's far cheaper for them to produce 'quantity' over 'quality'. In other words, they can farm way faster with 10 dumb bots than they can with 1 smart bot. A smart bot requires extreme resources.

And yeah, as long as loot is ALWAYS handled by the server, there is no risk of it having an impact. However, if players did not have to worry about lag/desync, the amount of 'alive players' would impact the economy. ;-)

"

qwave wrote:

By adding some cryptographic salt/hash to the random number generator, it can be made computationally infeasible for a bot to produce desirable outcomes.

Of course, but this is not the issue i'm describing. Even if the bot-client cannot generate desired outcomes, it can still CHOOSE form a large amount of pre-computed outcomes. However i do not think that it can play better than a human.

"

If not portals then I'll spam movement skills to previously recorded player positions to get out ASAP before faking a disconnect or faking a portal. Sure, I may still die in some situations. But if I can avoid even one death then it's a win and you can't prevent that.

If you had extremely powerful software, and a lot of luck, you may be able to pull it off sometimes depending on the situation.

Deaths prevented due to desync/lag: 1,000,000
Deaths prevented due to leet hax & luck: 18

Enjoying the game without having to worry about desync: Priceless

A worthwhile trade imo. If a couple hackers manage to escape death due to sheer luck, I would prefer that over having to reroll my own dozen characters due to desync deaths.

"

Even if the bot-client cannot generate desired outcomes, it can still CHOOSE form a large amount of pre-computed outcomes. However i do not think that it can play better than a human.

Bots would have to compute each outcome and permutation, which im saying is too computationally expensive, especially with a cryptographic salt/hash. =)