Technical solution to eliminate desync in single-player sessions

"

So now you don't have desync, you have computational lag introduced into the game. Congratulations.

This new system would not introduce any computational lag into the game. You read my reply wrong, I was talking about if you were using a bot to try to play the game.

"

And it would take several MINUTES to transfer state snapshots especially if you have a backlog due to a large amount of user actions taken, i.e. Multistrike, Summoners, Totem Sporkers, ETC.

There would be no backlog, the snapshot would be streamed during play. Many of these actions can be implied by the server, and do not need to be directly included in the backlog. For example, the exact velocity of a spark can be simulated based on the seed, the path does not need to be included in the snapshot.

"

qwave wrote:

"

From a dev point of view I can already tell that the development time of this proposal would take at least 6 months with about 10 devs.

Maintenance and keeping up with managing client side issues, hacking and general other extended support would be a waste of resources.

That time and money could be better spent finding a more elegant server-side solution.

If the client/server is the same language and they practiced modern software paradigms, it may not take them as long to implement. I do not think it would take 6 months to make these changes, but it may take up to 3 months. They already need to deal with these 'issues' you describe in their current system. They still have to validate for hacks currently.

There is not a more elegant server-side solution, otherwise they would have implemented it from the get-go. There are only so many solutions to this sort of problem in computer science/physics.

I'll restate my assertion that most programmers write awful code. Most of that code isn't documented (edit: as well as it should be), either.

And the most readable and malleable code isn't written in languages that work well for games. All aboard the hate-on-C-train, next stop emacs vs. vi-ville.

They definitely cannot completely "solve" desync, but some of the egregious cases are beyond even the theoretical examples they have mentioned. (10s+ desyncs that are solved by /oos only shouldn't really be happening.)

Related: what's the deal with the passive tree page? There's a single variable on it whose definition, that is fit onto a single line, is large enough to crash emacs.

"

I'll restate my assertion that most programmers write awful code. Most of that code isn't documented, either.

And the most readable and malleable code isn't written in languages that work well for games. All aboard the hate-on-C-train, next stop emacs vs. vi-ville.

It's more than likely that their game client and server are coded in the same language (probably C++) in order to facilitate code sharing. If this is the case, then there is a possibility that they can easily move the necessary code to achieve this proposal.

Even still, if it takes them a few months, I think it's a win.

Its not like they are stopping cheaters anyways. I mean, do people not use Google?

All their decision does is hurt your average gamer, with desync. Anything to minimize desync is a good thing to me.

So again, as usual, your normal gamer is suffering and getting screwed by these security systems, while the people who cheat just keep on cheating.

"

Related: what's the deal with the passive tree page? There's a single variable on it whose definition, that is fit onto a single line, is large enough to crash emacs.

That's a serialized JSON (Javascript Object Notation) string which the tree uses to populate itself. It looks like they've tried to reduce the size of the structure using a JSON compression algorithm, but they would probably benefit the most by streaming the data with AJAX or by using a better compression algorithm for the string constants. It is the culprit for the primary performance problem with the POE tree at the moment.

"

qwave wrote:

"

I'll restate my assertion that most programmers write awful code. Most of that code isn't documented, either.

And the most readable and malleable code isn't written in languages that work well for games. All aboard the hate-on-C-train, next stop emacs vs. vi-ville.

It's more than likely that their game client and server are coded in the same language (probably C++) in order to facilitate code sharing. If this is the case, then there is a possibility that they can easily move the necessary code to achieve this proposal.

Even still, if it takes them a few months, I think it's a win.

If I could steal a few months of their time, I'd want a native Linux client so I don't have to boot Windows to do trades. Seriously, why does Windows have to boot so slow?

(Or have them finish the out-of-game trading system. But that's less fun.)

"

If I could steal a few months of their time...

I edited my main post to clarify some of the other benefits from this proposal. The months spent decoupling the code from the server to fix desync would create a lot of new features for Path of Exile, including:

- A full combat log, which many have asked for! This is because the client would be responsible for generating snapshots.

- A replay system, which I also believe would be absolutely amazing. The snapshots themselves are more or less 'replays' that contain the snapshot data, allowing the game client to 'play them back' at a later time.

- Reduced bandwidth and costs. This is because the server would not need to continually process state data and send it back to the client. It would only need to evaluate the state once. Reducing server costs potentially means they could use funds for other things (such as expanding their team)

- Happier players and more revenue! The desync and lag has caused a lot of complaints from the community, especially on hardcore. I believe that by reducing the number of desync deaths, the playerbase will expand.

"

qwave wrote:

"

Related: what's the deal with the passive tree page? There's a single variable on it whose definition, that is fit onto a single line, is large enough to crash emacs.

That's a serialized JSON string which the tree uses to populate itself. It looks like they've tried to reduce the size of the structure using a JSON compression algorithm, but they would probably benefit the most by streaming the data with AJAX or by using a better compression algorithm for the string constants. It is the culprit for the primary performance problem with the POE tree at the moment.

Yep. I was (briefly) trying to write an offline skill calculator in Haskell and got pissed off trying to handle/parse that JSON object.

I'll get back to it later, but just seeing that when I wgetted the source made me shed a tear.

"

qwave wrote:

"

From a dev point of view I can already tell that the development time of this proposal would take at least 6 months with about 10 devs.

Maintenance and keeping up with managing client side issues, hacking and general other extended support would be a waste of resources.

That time and money could be better spent finding a more elegant server-side solution.

If the client/server is the same language and they practiced modern software paradigms, it may not take them as long to implement. I do not think it would take 6 months to make these changes, but it may take up to 3 months. They already need to deal with these 'issues' you describe in their current system. They still have to validate for hacks currently.

There is not a more elegant server-side solution, otherwise they would have implemented it from the get-go. There are only so many solutions to this sort of problem in computer science/physics.

There is no way something like this would take 3 months. The amount of testing involved would be at least 3 months. They would have to get an entire new team to support this functionality. Keep in mind that devs get on average 3k a month. Each.

I understand the desync frustration (I died to it this morning) but your solution is simply nowhere near cost effective.

There is definitely a more elegant server side solution. Whatever it is requires time to implement and test. People often forget the amount of time needed for testing. Just because something is developed does not mean it's ready to go!

Maybe GGG could provide some transparency here and give some updates as to how they are going with the desync issue (they are DEFINITELY working on it).