ScrotieMcB vs Desync Dev Manifesto (Massive Wall Map of Text)

I'm bad at fully communicating an idea, but you've done a far better job at underlining the causes behind why the manifesto on this made me angry when I read it, (Queuing the topic about how they simply don't want to take the steps required to resolve desynch).

Excellent post Scrotie, +1000 internets for you.

I would loan you my DeLorean so that you could go back in time and give this post to the devs while they were designing the netcode, but I kind of lost it in the Triassic (long story).

At this point it depends on how awesome the original code is; if the netcode is sufficiently abstracted from the simulation engine they really could do a complete rewrite before release. If not, I peg their chances at approximately zero.

"

HellGauss wrote:

Having a (small) experience as a programmer, i can ensure you that to change a thing in a software when you did not plan that thing at the beginning is massive pain, expecially if you want to change something in the core of the software.

Their netcode is dysfunctional/broken. This is known by all, most likely including the staff of GGG.

They can either:

1) Rewrite it NOW, and implement it as one giant patch when it's done, with the help of somebody who is an expert (they have no experts on this stuff at GGG - they cowboy'd it).

or

2) Continue to make the game more complex while relying on this shitty netcode, and it gets even more difficult to rewrite it.

They are choosing option 2) (otherwise known as the cheapskate option where you deliberately sacrifice quality

It really wouldn't be hard to implement the attack function while actually hovering on a monster as

"Character attacked monster A at location X,Y"
Location X,Y is reported by the client.
If the server sees that the client monster locaiton is different than the server monster location by more than a certain radius, force resync.

Resyncs the game every single time you hit something with targeting, but doesn't cause jittery entities because it only resyncs them if they're out of sync by a good amount, due to the leniency with the radius.

This doesn't really help ranged builds using LMP very much, but that's not too big of a deal. It would greatly benefit melee.

"

ScrotieMcB wrote:

TL;DR: To be honest, at this point I don't think what the PoE netcode needs is "changes." I think it needs to be thrown out completely and rebuilt from the ground up. It's clearly based on a number of logical assumptions, incomplete information, and probably a lot of inefficient communication (low information entropy). Perhaps you could even implement UDP instead of TCP for those continual position updates; it's not like resending old data matters in that case. Recently GGG put the time into an art datasize overhaul, and the results on performance were impressive. Netcode is in dire need of a similar treatment.

While you may have a sound theoretical basis for this recommendation, in practice, no seasoned software development manager would be persuaded. The reason is that yours is a high risk strategy that gambles all of GGG's netcode programming resources on an heroic attempt to "get it right" the second time around. The game industry track record of such approaches is dismal.

The PoE netcode that is in place has a unbeatable advantage: many months of debugging and optimization, along with Beta Test server traffic records that can be used to identify its weak spots. No hypothetical netcode rewrite can compete with that kind of track record and there's no shortcut that can substitute for months of real-time Beta testing.

However, I do think your analysis can be of great value in identifying exactly where the current netcode architecture could be significantly improved, not by rewrites or optimizations, but augmented with additional client-server real-time data updates.

"

ScrotieMcB wrote:

...GGG is trying to use the "fill in the gaps" method not only to fill the gaps, but as an actual replacement for network communication. The server is only seeing fit to give the client the parts of the picture which it considers relevant, which leads to things like the position of a particular monster (or even the player) being ignored for seconds at a time.

...why isn't the position data — I'm not talking monster frames or types of complicated things, I'm just talking basic x,y position coordinates on all players and monsters — updated with pretty much every single communication from server to client?

I think this is the missing link that needs to be filled in with actual game data rather than predictions. The single most important function of the visual display is to show you exactly where you and each of the mobs is located in real time. Unfortunately, it would be impractical to do this synchronously using the TCP-based netcode currently in place. But as you have pointed out in previous posts, this type of real-time positional data streaming could be readily implemented in a completely separate asynchronous stream of UDP packets. The huge development advantage of this approach is that it could be incorporated into the existing netcode architecture without requiring major rewrites or revisions to existing systems.

In conceptual terms, what an additional UDP system would provide is a continuous stream of real-time character and mob positional updates, sent one-way from the server to each client. The technical advantage of UDP communication is that it is completely asynchronous and runs automatically with minimal latency, requiring none of the overhead TCP uses to maintain 100% data integrity. The availability of this data stream would enable each client to update its visual display as frequently as possible with the character and mob positions sent by the server. That alone would minimize perceptual desync events with no changes required to existing server code.

The key feature of UDP that makes this strategy practical is that it places no significant communication burdens on either the server or clients. The server simply broadcasts the UDP updates into the void, without concern for when and how often the clients actually receive the packets. The client is likewise under no obligation to process any of the UDP updates. It is free to make use of the UDP stream to correct its local positional data any time it has the bandwidth to do so. The positional data is used solely to refine the client's internal game state to more closely track the server's. The UDP stream is in no way required for the proper operation of the TCP netcode on either client or server.

Compared to a complete rewrite of PoE netcode, implementing an auxiliary UDP server->client stream would entail minimal risk to GGG's development schedule and require minimal programming and testing resources. At this point in Beta development, I think it is the single most effective component that could be incorporated to improve PoE gameplay.

I think you could have made the same point in the OP without calling the GGG team out as liars. You can just say their statements are incorrect. Attack the message, not the messenger.

As for the main message of the OP; that the communication between the client and server is really bad, I agree wholeheartedly. There's no excuse for that.

Actually, that was a small lie*, since there is one excuse: GGG are making the game how they want it, not how you want it. If they want to build a game which has good client prediction, and want to work on improving the (currently pretty average) client prediction, then they're allowed to. They're not providing you a service, they're letting you pay their game as it is. If you don't like it, sucks to be you.

*(I'm allowed to call myself a liar!)

"

tikitaki wrote:

Look outside of your tiny country, and ship in real experts if you have to.

I don't think the issue is a lack of capable programmers in New Zealand.

"

dudiobugtron wrote:

"

tikitaki wrote:

Look outside of your tiny country, and ship in real experts if you have to.

I don't think the issue is a lack of capable programmers in New Zealand.

Programming is not just "programming"

There are a million different specialties of programming. Somebody good at one thing might not know much of anything about something else.

An expert in gaming netcode might have 10 years of experience, and it's an awfully specific thing to be an expert at. NZ does not have a huge game industry, so it's not a stretch to assume that there are no unemployed netcode specialists in NZ.

Blizzard no doubt has an entire TEAM that is focused specifically on netcode, and every single member of that team likely has prior experience.

Of course, Blizzard is a giant studio. But for GGG to not even have ONE person on staff with a deep understanding of these issues is just *facepalm*

It's cute/adorable that they are having their programmers learn how to do this stuff as they go, but if they keep treating PoE as a learning environment rather than a professional environment...I don't see much future for the game, because of the netcode ultimately sucks, the entire game ultimately sucks.

If it had singleplayer, you could at least say something like "oh it's OK, the netcode is shitty and laggy but I'll just play offline."

But we have no offline mode.