POE WILL BE THE NEW VANGUARD IF THEY DONT CHANGE SHIT UP

Wow. Lots of extremely interesting conversation going on here. I'm knowledgeable enough but some of you guys have some strong experience in this field. It's been a fun read.

On topic, I personally cannot comment on how well the actual issue of desync has been handled. I've gotten (mostly) used to playing with it and understanding what I can do to minimize creating worse desync for myself. But having grown up with the many great ARPGs, it does sadden me that sometimes very simply actions can lead to problems and desync has even affected how I build my characters.

However, someone in the first few pages mentioned the fact that GGG has essentially ignored our feedback by designing areas and monster mechanics that greatly aggravate desync, and I totally agree. If you can't realistically get rid of or minimize desync, at least design areas, mechanics, and monsters that don't aggravate the current problem! I saw my buddy get one shotted by a Vaal smash that literally happened half a screen away from him. And he was behind Vaal by quite a bit. We both saw it that way, but it didn't happen that way. Shortly after, Vaal teleported half a screen on top of me. If a boss that slow can Desync so poorly, they really shouldn't make one shot mechanics "a thing."

Why does every Exile have to Shield Charge, Leap Slam, Whirling Blades, Cyclone, etc? Does GGG pay absolutely zero attention to the skills that cause the biggest problems? Or that multistrike Ground Slam Exile. Goddamn, every time I run into him the game basically just gives up trying to figure out what is happening.

With regards to areas, why do the Imperial Gardens and Hedge Maze have to be such a clusterfrack of terrain obstructions, slim staircases, and small doorways? The Library and Sceptre aren't much better. I don't desync almost at all in the open wilderness of the first two Acts. It takes some seriously hasted monkeys and me getting cornered to even have an issue. I understand that terrain makes for interesting gameplay, but that is only when the game is functioning correctly. It worked great in Titan Quest. Here, the magic of it is lost once monsters start disappearing and reappearing, and I get moved down a staircase that I tried to Lightning Warp up.

Overall, I'm both surprised at the huge amount of negative feedback, and at the same time, I'm not. Those of us with patience and a love for this game have long gotten over it. But if it is going to plague us, please... PLEASE don't design stuff with an absolute disregard for one of the game's biggest issues.

Thanks,

Dan

"

ScrotieMcB wrote:

In terms of making that choice as developers, this is what GGG has to say:

"

Chris wrote:

The server has to dictate whether things happen or not, but there's a 50-250ms delay before data gets to the server and back. There are three ways that games can solve this:

• Trust the client. This means people can cheat, but the results are instant. We will not do this.
• Wait until data arrives back from the server before doing anything. This is a very common strategy in RTS and MOBA games. If you click to move, the unit will only start moving once the server says so, which is 50-250ms later. If you are close to the server, you'll quickly get used to the lag and everything feels pretty good. If you're far away (New Zealand, for example), it feels like you're playing drunk. Every time you issue an order, nothing happens for quarter of a second. This does not work for Action RPGs.
• Start predicting the result of the action as though the server said yes, immediately. When the server later gets back to you with a result, factor it in. This is what Action RPGs including Path of Exile do. It means that when you click to move, or click to attack, it occurs instantly and feels great. The problem is what happens when the server decides that the action can't have occurred - that's when the game gets badly out of sync.

I've previously attacked the accuracy of saying "this does not work for Action RPGs," but with one rather minor edit — "this does not work as well" — then I'm inclined to agree, with no small amount of zeal. Responsiveness is a huge thing, especially if you intend to design your game with cliffhanger moments requiring mechanical skill to survive, such as Vaal's Slam and Dominus' Touch of God. (These are good things, by the way... assuming desync isn't plaguing your game.)

I've never agreed to that Chris quote. It's sad to see that they perfectly know the solution and don't want to use it only because there are people that have more than 250 ms. I don't understand the point in sacrificing every player with good latency for the sake of some players (probably in minority) that won't have a good gaming experience anyway because they will still suffer desync and even more than the others. The only winners are sad winners.

I wish they could implement an option where you set your latency and the game use the best way to handle client/server communication based on that, I don't even think it would be that hard. Seriously, I would even pay for fully authoritative play...

This is even more relevant when the game is supposed to last 10 years and when you consider that latency overall should decrease progressively everywhere as internet connections get better and better. I bet client-side predictions won't even exist in 10 years because latency will have become that much negligible that you won't need any lantency compensation anymore.

"

SL4Y3R wrote:

When you attack faster than the server can even respond, don't expect any improvements to desync as a whole to solve that problem.

Actually that's the bit that makes me wonder. If the server respond time is limited to a known speed, WHY the **** do we have skills that work 10x faster than that?

I mean I understand having a limit on server respond time, and not being able to improve it.
But the speed game runs at, or the speed the skills perform at.. these things are %100 in GGG's control and decision.

Same goes for all the clutter on the ground that makes pathing a disaster, narrow doorways and areas in general, labyrinth like areas with horrible corner edges, same for most obstacles with very small details and edges.

Desynch is not a technical problem in PoE, it is by design obviously.

The "This does not work for Action RPGs." is such a load of horseshit that it makes me want to vomit. Games like Dota 2 are a trillion times more complex and dynamic than this and they still manage to do extremely well with that networking model. How is it then than this game can't? I have 150-250 ms all the time and I'd much, much, MUCH rather have that model than the piece of crap we have now.

Sounds to me like they made a stupid mistake and now they're too stubborn to admit it. I'd be pissed had I invested money into this game, but it's their money that's dwindling so they can do whatever the fuck they want.

"

RogueMage wrote:

You're using "feedback" in layman's terms, i.e. any sort of response to an action that is conveyed back to the actor. That's a definition broad enough to include this online forum, as a form of user "feedback" to GGG.

Nonsense. When I refer to "feedback" in the netcode sense, I'm referring only to systems where the server response to player input is automated. (/oos barely counts; I'm essentially treating it as a type of player action, on the same level as skill use, which I acknowledge is a stretch.)

"

RogueMage wrote:

A stand-alone single-player game simulation like Diablo II is an open-loop dynamical system that responds to user input and internally generated events with actions that the player perceives. When a D2 client is networked to a remote server, it works like PoE does - the client conveys user input to the server and responds to external events generated by the server. The networked client still operates as an open-loop system - it proceeds independently with its simulation based on the inputs it receives. The server likewise proceeds with its own simulation based on the same inputs, and the two simulations turn out very similar, since they're both running on copies of the same game engine.

I do not consider myself an expert on Diablo 2 netcode, and due to a lack of Google-searchable resources I can't even get the basics down with a quick article. However, I know Diablo 2 did not have a fully open-loop system, for one simple reason: it had desync. Not as much as PoE, granted, but it actually factored rather heavily into:

• PvP, where using a bunch of Vigor Charges to bug out your opponent's client, then beat his helpless toon to death with a big stick, was a cheesy yet effective strategy.
• trading, where it was possible to desync the system long enough, even on the Ladder, to temporarily convince the system that a duped rune was real. However, eventual resych would cause the duplicated rune to vanish — an effect caused by server feedback.

Yet fully open-loop systems, by their very nature, never experience resynchs in the first place, thus when desync occurs it is utterly undetectable to the client. Since desync was noticeable in Diablo 2, I can easily conclude it wasn't fully open-loop.

What's going on here is you're seeing a false dichotomy. I understand fully the idea that systems which tend to neglect feedback tend to rely heavily on prediction to get it right the first time (you call these open-loop systems, even in cases where there is some feedback), and that systems which tend to neglect prediction tend to rely heavily on feedback to get it right eventually (you erroneously believe these must be continuous to be closed-loop; more on that later). However, these are not mutually exclusive techniques, and it's possible to have both strong prediction and strong feedback.

Note that desync is only possible in mixed systems. Pure open-loop is blissfully ignorant of any desync it may experience; pure closed-loop disregards everything which isn't feedback, so the feedback has nothing to be out of sync with.

However, we can see numerous mixed systems in which desync is not nearly the problem it is in PoE. This is because the prediction and the feedback tend naturally towards the same answers... although they still have some desync, because although you get very (very) similar answers, they are not exactly the same.

The trick in a mixed system, therefore, is getting feedback and prediction as close to equal robustness as possible. The base for how quickly a prediction (exponentially) diverges is based on the difference between prediction and feedback. Thus: in a mixed system, the way to improving the system is to pick whichever is performing worse — prediction or feedback — and improve the weaker one. In Path of Exile, that's actually prediction; you might resent having to send /oos as often as you do (and might even have it on macro), but you nevertheless acknowledge that it works, while PoE's predictive systems are nowhere near that level.

"

RogueMage wrote:

While the server does monitor the client's behavior, it's not a closed-loop feedback control system. The server has some means of determining when the client drifts too far out of sync, but it doesn't use that information to continuously regulate its own behavior. Instead, the server just imposes its own version of the simulation on the client at sporadic intervals. This is a forced-sync fallback mechanism rather than a feedback control system.

False. A discrete closed-loop system is still a closed-loop system; the fact feedback is no longer continuous does not mean it is no longer feedback. Here's a video of a nice discrete physical feedback system; it takes input until it reaches a particular quota, then it provides feedback. PoE's current system is a similar form of closed-loop; it waits until it reaches a particular quota of detected error, then it provides feedback.

So let me lightly edit the next quote slightly to reflect what you really mean.

"

RogueMage wrote:

A [continuous] closed-loop client-server system would work in a fundamentally different manner. The client would continue to proceed with its own local simulation, but in addition, it would receive a continuous stream of reference data reflecting the ongoing state of the server's simulation. The client would then compare its results with the server's to generate error correction inputs that it would then use to self-regulate its own behavior. In a well-designed closed-loop system, this error correction occurs continuously rather than sporadically, and enables the client to seamlessly track the server's simulation without abrupt discontinuities in gameplay.

What you're talking about here is essentially non-stop streaming of server data to the client. Which would work. However...

• The network hardware required to realize such a task is dauntingly expensive. You're essentially talking about having every single client /oos multiple times per second. Even with optimizations (such as switching to streaming-optimized UDP instead of discrete-optimized TCP), it's highly unlikely GGG's current infrastructure could come close to supporting it, requiring vast amounts of new high-quality hardware.
• Most importantly, such a streaming method is fundamentally incompatible with any form of client-based prediction whatsoever — it's full closed-loop. What's the point of having the client respond immediately to player commands, when 50-250ms later the exact same event is going to be repeated on the client, because everything is based off feedback? Use of this type of netcode immediately puts a game into the "wait on the server for everything" style.

For these reasons, this type of continuous closed-loop system is fundamentally a poor match for both GGG (point #1) and PoE (point #2).

"

RogueMage wrote:

You might suppose that unpredictable network latencies would cause a closed-loop system to malfunction

Actually no, I wouldn't. But I don't care, because it's the wrong system to use, for completely unrelated reasons.

"

zriL wrote:

I've never agreed to that Chris quote. It's sad to see that they perfectly know the solution and don't want to use it only because there are people that have more than 250 ms. I don't understand the point in sacrificing every player with good latency for the sake of some players (probably in minority) that won't have a good gaming experience anyway because they will still suffer desync and even more than the others.

I've never really agreed with it, either. However, over time, I've grown to agree with the decision to have the client be immediately responsive... while still thinking this particular passage does a mediocre job of explaining why it's the right choice. You don't enjoy seeing other people putting up strawmen of positions you actually hold.

One good reason to use the immediate-response system is something which Chris partially addresses: it allows the game to respond immediately to player input, which is essential for mechanics-based challenges where movement is key, such as Vaal's Slam and Dominus' Touch of God; when the system works, such immediate response does in fact feel great. When reaction goes sluggish, these types of challenges instead feel like cheesy one-shots. When executed well (not saying it is currently), the immediate-response model is the way to go with these types of gameplay elements.

Another good reason is economics. Good closed-loop systems require lots of network hardware, which GGG didn't have. Similarly: even if they did have the money to purchase all that extra hardware, they could save the money by skipping those purchases and put it instead into the development of more content.

"

ScrotieMcB wrote:

"

RogueMage wrote:

You're using "feedback" in layman's terms, i.e. any sort of response to an action that is conveyed back to the actor. That's a definition broad enough to include this online forum, as a form of user "feedback" to GGG.

Nonsense. When I refer to "feedback" in the netcode sense, I'm referring only to systems where the server response to player input is automated...

However, I know Diablo 2 did not have a fully open-loop system, for one simple reason: it had desync...

Pure open-loop is blissfully ignorant of any desync it may experience; pure closed-loop disregards everything which isn't feedback, so the feedback has nothing to be out of sync with...

A discrete closed-loop system is still a closed-loop system; the fact feedback is no longer continuous does not mean it is no longer feedback...

PoE's current system is a similar form of closed-loop; it waits until it reaches a particular quota of detected error, then it provides feedback...

What's the point of having the client respond immediately to player commands, when 50-250ms later the exact same event is going to be repeated on the client, because everything is based off feedback?

Etc, etc...

Alright, I'll leave you to your own personal definitions of terms to suit yourself. But if at some point you take an interest in learning about feedback control systems, I'll be happy to point you to some good introductory material.

"

RogueMage wrote:

Alright, I'll leave you to your own personal definitions of terms to suit yourself.

I did research on my posts during the writing process. Anyone is free to look up these definitions online; I think most everyone would agree my use of the words is closer to the truth.

"

ScrotieMcB wrote:

"

RogueMage wrote:

Alright, I'll leave you to your own personal definitions of terms to suit yourself.

I did research on my posts during the writing process. Anyone is free to look up these definitions online; I think most everyone would agree my use of the words is closer to the truth.

You seem to be mixing them up quite a bit to be honest. There's several instances where you use open-loop while you seem to mean closed-loop and vice-versa.

For example, you claim Diablo 2 did not have open-loop because it had desync. That's exactly the property one would expect from an open-loop system, which I take to mean you actually intended closed-loop.

"

Gobla wrote:

"

ScrotieMcB wrote:

"

RogueMage wrote:

Alright, I'll leave you to your own personal definitions of terms to suit yourself.

I did research on my posts during the writing process. Anyone is free to look up these definitions online; I think most everyone would agree my use of the words is closer to the truth.

You seem to be mixing them up quite a bit to be honest. There's several instances where you use open-loop while you seem to mean closed-loop and vice-versa.

For example, you claim Diablo 2 did not have open-loop because it had desync. That's exactly the property one would expect from an open-loop system, which I take to mean you actually intended closed-loop.

No, I spoke accurately. Every time you desync-teleport in PoE, that's proof that PoE isn't an open-loop system, because if it was an open-loop the desync would never correct itself, ever. The reason it corrects is because it receives some kind of feedback from the server. When desync never corrects itself, it isn't detectable; therefore, any game with detectable desync is not open-loop.

"

This does not work for Action RPGs

Maybe this is true for PoE. But the point is that the wait for 'server response' would means that the server should send 'continuosly' all the data required to represent the game status (pure closed loop), which is impossible because of bandwidth. We would have sync issue even if actions are delayed by latency.

All the discussion make here is summarized by the following questions:

How much information (bit/s) the server have to give to the client in order to keep the game playable?

How (and how much) can this information be reduced without a complete redesign of PoE core? And if the core can be rewritten, which is the best approach?

How much bandwidth GGG can afford?