As a former game developer, I am appalled

"

Bakkasan wrote:

The only way to make them fix it is to stop paying for wings, flaming skulls, special portals, and bunnies.

The apologist and fanboys will kick and scream and blame the player, their method of moving(I mean really, you can walk in an open map in a straight line and desync but its your fault), and of course your top of the line rig isn't up to the challenge.


And no, I don't think it's an easy fix.

Ya cut off their revenue stream so they can improve the game.

L O G I C B O Y S

"

Ya cut off their revenue stream so they can improve the game.

L O G I C B O Y S

Ya keep paying for poor performance.

L O G I C B O Y S

"

raics wrote:

"

Snorkle_uk wrote:

In order to avoid dying to desync you stop making bad characters with bad defenses that cant survive taking a few hits. Then you learn how to shift click to hold in place. Is it really that hard? No.

You described the problem perfectly. Game forcing you to make a build X, use skills Y, and play it following the pattern Z.

Well, 'forcing' might sound a bit harsh, how about 'nudging'?

forcing you to not make shit builds ya, making a build that WILL die a lot anyway die a little more often. Thats the price we pay for being able to play a game online with a central server where exactly? Asia? The kind of server that if, as a european, I logged on to in order to play quake 3 deathmatch I would have a 350-450 ping and the game would be a slide show of unplayable lag. Instead I play a game that feels as instantly responsive as a single player game on my hard disk and I sometimes notice desync, big deal. Yes, I cant play a character who is completely glass and expect my skill as a player to save me from death every time.

You know what? I cant do that in Diablo 3 either because the combat mechanics are so shit that you can be hit from half a screen away, the game has taken away your ability to use skill to kite mobs because if they let that exist you would notice the desync, and thats a game where the server I am playing on is in europe. Either way you are fucked if you make a character with shit defenses, there is no solution to this that lets people live with a bad character unless they take the game completely offline. You either play a game with desync, play a game that hides desync by taking away the ability to have skill and make a difference anyway, or you play a game that is synced and you have a 350 ping then die from lag instead of desync.

How many builds are viable in this game? More than exist in any other arpg. You paint a completely false picture with what you say. Oh poor us we are being forced to play these few builds that work in this game when we all want to be freedom loving individual butterflies omg the tyranny and oppression.... no sry that doesnt accurately represent the situation, "learn to play /thread" accurately represents the situation, with a dash of "get real".

"

Snorkle_uk wrote:

How many builds are viable in this game? More than exist in any other arpg. You paint a completely false picture with what you say. Oh poor us we are being forced to play these few builds that work in this game when we all want to be freedom loving individual butterflies omg the tyranny and oppression.... no sry that doesnt accurately represent the situation, "learn to play /thread" accurately represents the situation, with a dash of "get real".

Look at it this way, if I fire up a game and go "Hmmm, what should I make next... I know! how about... a dominating blow build? Kind of... a summoner/melee hybrid?". But then rethink it "Nah, I tried using that shit it desyncs like hell for some reason even with multistrike and a lot of minions with special skills mutilate my fps, I suppose I'll go for a normal summoner instead..."

Now tell me, what kind of a picture does that paint? If the game can't handle its own content what's the damn point? If you don't know how to make a decent online game, make it offline, you're just wasting potential otherwise.

"

Snorkle_uk wrote:

I cant do that in Diablo 3 either because the combat mechanics are so shit that you can be hit from half a screen away, the game has taken away your ability to use skill to kite mobs because if they let that exist you would notice the desync, and thats a game where the server I am playing on is in europe.

Sorry Snorkle, maybe you play some other D3 version, but in mine, my main defense is manually dodging attacks. The only unavoidable and non-telegraphed attack is Jailer, and it really sucks if you play in like 33+ grifts.

"

Snorkle_uk wrote:

"

raics wrote:

"

Snorkle_uk wrote:

In order to avoid dying to desync you stop making bad characters with bad defenses that cant survive taking a few hits. Then you learn how to shift click to hold in place. Is it really that hard? No.

You described the problem perfectly. Game forcing you to make a build X, use skills Y, and play it following the pattern Z.

Well, 'forcing' might sound a bit harsh, how about 'nudging'?

forcing you to not make shit builds ya, making a build that WILL die a lot anyway die a little more often. Thats the price we pay for being able to play a game online with a central server where exactly? Asia? The kind of server that if, as a european, I logged on to in order to play quake 3 deathmatch I would have a 350-450 ping and the game would be a slide show of unplayable lag. Instead I play a game that feels as instantly responsive as a single player game on my hard disk and I sometimes notice desync, big deal. Yes, I cant play a character who is completely glass and expect my skill as a player to save me from death every time.

You know what? I cant do that in Diablo 3 either because the combat mechanics are so shit that you can be hit from half a screen away, the game has taken away your ability to use skill to kite mobs because if they let that exist you would notice the desync, and thats a game where the server I am playing on is in europe. Either way you are fucked if you make a character with shit defenses, there is no solution to this that lets people live with a bad character unless they take the game completely offline. You either play a game with desync, play a game that hides desync by taking away the ability to have skill and make a difference anyway, or you play a game that is synced and you have a 350 ping then die from lag instead of desync.

How many builds are viable in this game? More than exist in any other arpg. You paint a completely false picture with what you say. Oh poor us we are being forced to play these few builds that work in this game when we all want to be freedom loving individual butterflies omg the tyranny and oppression.... no sry that doesnt accurately represent the situation, "learn to play /thread" accurately represents the situation, with a dash of "get real".

GGG themselves said:
PoE will be a HARDCORE game.
Hardcore game, in GGG's opinion, is the game, where character's positioning DOES matter, and that means manually dodging attacks, kiting enemies, etc.
Now tell me, can PoE be a HARDCORE game with its design and desyncs you got?
Diablo 3 is 10 times more HARDCORE game than PoE, with GGG's own definition.

"

grepman wrote:

desync is a cause of design problem, not the implementation.

Desync, in the order of hundreds of milliseconds is a design problem.

Desync, in the order seen in PoE is an implementation problem.

Some desync is unavoidable unless you replace it with input lag. The amount of desync seen here is most definitely not.

"

grepman wrote:

first of all, anything is a matter of investment. resources arent infinite. poe 2.0 will be easier to make and especially deliver on return of investment, than spending a ton of resources rewriting the system. obviously GGG doesnt have the resources of a dev that develops a FPS

I don't think it will require a ton of resources, but it will be substantial for a small company as GGG. In order to get them to spend time and money, feedback threads on desync have their place. In turn, I for one would be more than willing to pay (or buy MTX that I would not buy otherwise) if I saw a substantial effort on their side.

"

grepman wrote:

second of all, what video are you talking about ? regarding strongboxes, I believe there is two aspects to it- framerate drop when spawning (poor optimization) and desync itself

This one, posted earlier: http://vimeo.com/86104923

Because this is what I am talking about when I talk about desync - your character being in a different room and the server not having any way to tell unless X actions fail, which is a flawed system.

As for strongboxes, the FPS drop is one thing, but probably much harder to fix. The desync, on the other hand, is something I believe to be caused by a flawed net logic.

"

grepman wrote:

third of all, ok lets hear your proposed solution for desync issues. one that doesnt involve a more frequent force sync (ie /oos) as to stay within the confines of the predictive system

Fair enough.

Let's start with something more general so we're on the same page:

# We don't want to allow the client to decide what is going on, all logic remains on the server
# We don't want to change clipping, e.g. passing through mobs or smaller obstacles.
# We don't want to rewrite the entire game engine from scratch.
# We could have the server resync every 500ms. While that would work, the traffic cost would kill GGG.

What we're looking for is a way to identify desync when it happens, with as little traffic cost as possible.

That being said, I will come to no surprise that there isn't the ONE fix to desync, but rather it will require a number of small changes. I'll use the video above to give one example of a technique that is obviously not being used but might already help a lot.

Behold the power of my paint skills.



1.) This is a screen shot taken from the video. I've placed a very crudely drawn control mesh of the scene. Essentially, a control mesh is a grid of equally (ahem) sized squares that is put over the entire map. Both server and client know this grid (agreed on as the map instance is entered).

2.) An active player will trigger actions quite regularly. These actions are transfered to the server in terms of packets. Each packet has an ID describing the content, usually based on a Huffman coding. It is easy enough to spend one bit that signals 'Hey server, I'm adding some extra content for you with this one'.

3.) Say we want this extra sync content to be sent roughly every 500ms, and say we want to spend one byte in traffic. That is 2 bytes per second added traffic, so even for 100k concurrent players this is very manageable.

4.) Our extra byte comprises of two 4 bit numbers (0-15), one for the yellow and one for the magenta indices. The squares in our grid are coded likewise, that is 0,1,2..14,15,0,1,2... Every 500ms, the client uses the extra byte to say 'I believe I'm in square X/Y'. The server receives this package and compares it to his own mesh.

5.) In the screenshot, the players assumes to be in 7/6 (light blue circle). The server thinks the player is at 4/6 (dark blue circle). This is where the server triggers a resync, because it knows the lag between client and server doesn't account for a 3 square distance. Or maybe the server decides to wait for the next update - if that is off by 3 squares again it is time to resync. Or maybe the server actually looks at the map and determines whether there is a wall between the nearest 4/6 and 7/6 squares - that would be a priority resync. Whatever logic you choose, the server is aware that something is wrong.

6.) Now extend the idea to bosses as well. Spent another 2 bytes per second if you know that there is a difficult boss on the map.

7.) Extend the idea to movement skills. Hey, I just leapslammed, I think I'm at 15/0.

Now this will not fix desync altogether. But it will prevent situations as seen in the video. It will also limit the distance you can desync to the distance you can travel in 500ms.

This is hardly an engine rewrite. It is a very simple mechanism that obviously it not implemented in the current version, or is not working correctly.

ok let me first say Im impressed by the post. most people will not go that far to argue their point in as many details. I'm 100% serious without trolling or anything else of that sort, very nice.

so let me comment on this.

first, from theory, its actually not that important to make the payload of the resync packet very small. just headers for tcp and ip will put at you at 40 bytes minimum without any payload...so it really doesnt matter that your data is packed and serialized to near byte. 10-15 bytes will be fine as well :)

second, I think a very similar system is what GGG uses with few caveats. first, they probably do not base the basis of a resync decision on pure distance, but rather by surrounding objects including players, monsters, environment objects, as well as events (stun comes to mind)

but here comes the biggest issue. every time client sends action to server, I nearly guarantee it already sends a delta of their movement. you do not need extra resync packets, really.

so really, its basically the decision of when to resync and how often to resync. we agreed that we wont force resync it very often via pure client request (1 in 10 seconds as it is right now via oos)

also, you might need to remember that besides the actor(s) there are monsters and other objects that move. that is huge

so in my speculation heres the sample of client requests sent to server and a simple, plain desync

actor is at coordinate X,Y
move with delta = deltax, deltay *animations starts*
* you see a rhoa pop up on the screen, you attack it*
requestattack at z,w (translates to requeststop at z, w-p; requestuseskill on target at z,w iff target exists;
*attack animation plays*

seems simple enough ? but now remember this is just a stream of sends to socket

here what might go on server side

received from client: actor is at coordinate X,Y
*wait*
*wait*
received from client: actor is moving to X+deltax, Y+deltay by path e (empty)
*wait*
received from client:actor is at X+smalldeltax, Y
*wait*
actor is at X+smalldeltaX, Y
entity 'rhoa51313' at z,w ends sleep mode because enemy in radius
entity 'rhoa51313' charges at X+smalldeltax, Y
entity 'rhoa5131'
entity 'rhoa51313' collides and hits actor for bazillion damage, STUN
sent to client: FORCE RESYNC, actor is at X+smalldeltax, Y with bazillion less life
received from client: requestattack at z,w.
check coordinates z,w: empty
attack fails

so in your fix implementation, you'd need do check distance between any and every entity that is potentially moving- monsters, party players, rogue exiles and force resync. that is not even a polynomial time problem.

right now resyncs are /oos user request resync, some events like stun and probably some actions that result in a failure like you said. I think the fix required is likely to be much, much harder than what you proposed. but again, your post is one of the best Ive read in terms of supporting your point.

"

vezuial wrote:

4.) Our extra byte comprises of two 4 bit numbers (0-15), one for the yellow and one for the magenta indices. The squares in our grid are coded likewise, that is 0,1,2..14,15,0,1,2... Every 500ms, the client uses the extra byte to say 'I believe I'm in square X/Y'. The server receives this package and compares it to his own mesh.

How do the client and server agree on where 0,0 is? You just drew them on the client's screen, if there is a sync problem the server has no idea where that is.

Anyway, the comparison doesn't do as much good as you might think even if that problem is solved. Latency-constrained bubble collision is only going to detect sync problems when players are running in a straight line. Otherwise they won't leave the bubble (the bubble cannot be eliminated as that represents the latency delay). I don't know about you, but most of my sync problems are when there's lots of things around and I'm making small movements, not when I'm running in the open without changing directions.

Supposing you solve even that issue, collision detection and pathfinding are some of the most computationally intensive workloads in a typical game's logic. As a result, there are a lot of shortcuts taken so that data structures which make human sense like cartesian coordinates are substituted with data structures that can be operated on more quickly like a kd tree. The information that it takes to solve all the above issues is unlikely to be both readily available and easily applied for the kind of calculation that would reliably detect sync errors. If it were, it would have been used already for that purpose.

But even if that's solved you've still only shifted the load from one constrained resource (bandwidth) to another (server CPU time). I have no way of knowing the relative cost of the two from GGG's perspective, but if something so simple would actually work I don't think GGG would sit on it out of incompetence or apathy.