What is Desync? (A thorough explanation)
Eh, you don't need to decrypt the communication, you just hijack the game process and change the variables containing the amount of damage dealt before encryption is even done... Only good way to combat those kinds of hacks is by running something like Blizzard's Warden, and that's invasive and still not foolproof.
Anyway, I don't see the big deal about just syncing with the server more often. Sure, it takes some bandwidth, but not a huge amount compared to what's already being sent. Updating the position of the monsters nearest you( usually no more than like 10 upwards of 20-25 in some cases) maybe two-three times a second shouldn't take many additional bytes of data. If we go with 4 byte variables, with two for each monster( X,Y), that makes 8bytes per monster. Even if we were talking a hundred monsters we'd still just be looking at 800 bytes of additional data with each transmission. Increase it for overhead and packet loss and whatnot and we're at maybe 2KB, say three times a second. So 6KB/s more per player, assuming 100 monsters to update( i.e. unlikely). Let's say 2000-3000 players playing at one time, that's an extra 12,000-18,000 KB/s which means a 100Mbit line or so. And that's probably a worst-case scenario. Still wouldn't be entirely rid of desync, but you'd have come a very long way. |
|
" I love how you make it sound that leveling isnt possible and yet have a level 83 char? Lol? The game is not meant to let you go much higher YET, so start an alt and wait for chapter 4? |
|
" You and the others like you (eg TheAnuhart)... If you care to explain your point (which I'm sure you don't but thought I'd try) - You've said here: "...a game that is pointless to play at the end." What 'end' are you talking about? The one that is coming in approximately 6 months when the game is actually finished to Act 4, new skills and uniques (that enable diverse builds) are included, and balance and desync has been addressed? THAT end?? Have you travelled forward in time to be able to see that the game is pointless at the end? You've been able to see that desync was never addressed satisfactorily and the content did not keep up with the progression or provide entertaining end game with properly balanced map drops, etc.? Please tell me what you mean. Please ;_;. Because the mentality of you people is so seriously next level WTF that I'm sure I must be missing something. IGN: ScrubcoreRulezBitch Alt: HardcorePwnsScrubcore Last edited by mkmaddage#1774 on Apr 4, 2013, 8:24:37 AM
|
|
I did skip a few pages, but I actually read most of the thread. The two things I took away are:
1. People take "you can never fix desync completely" to mean "IT'S HOPELESS! RUN FOR THE HILLS!!11!" This also applies to the statement "every game has desync." People read that, and, not paying much attention to the context, assume the OP is saying "desync issues are just as extreme in every game." The reality is, as the OP explained, desync is covered up in those games better from the way they work, which gets me to #2 2. The biggest difference between PoE and D3 (and other ARPG's w/o desync) is mob/player collision. I never played D3 so correct me if I'm wrong, but is it true that mobs don't have collision w/one another? If so that would explain most of the discrepancy, and would also explain what the OP meant by "POE allows more more tactical positioning." I'm sure there are choke-points in D3 maps, but if mobs can pass through each other they can only do so much. When there's collision, you can sit in a corner or behind a wall and be assured that only a few mobs will actually get within melee range. The easiest solution would likely be to remove collision, but I'd find that as terrible as dealing with desync every now and then. IGN: Jihokinetic
|
|
" This would only work if the server is set to believe everything the client tells, if there are probability checks, even to an amount as in checking if not only the damage done is doable by the weapon equipped but also if the amount of critical hits over the past x amount of time fits the critrate you have, it could be countered with very little effort serversided. Basically it´s a question about who has to deal with annoyance. It´s way more effort to make such a system as foolproof as possible server-sided, so the programmers would have to deal with annoyance. But you also can go the easy way, let the server calculate everything and the client be nothing but a graphical frontend, well, then your users will be annoyed by desyncs. |
|
They could use a combination. Make it follow normal collision pathing, until a unit tries to go through another and cannot find a way through, then it'll go through the unit.
IGN: Golem_Antsy, Harvest
|
|
" Yeah, I suppose you could work against parts of it using something like that. Would have to be pretty well-made though, so players don't suddenly get banned for being lucky and critting five times in a row. You'll still run into other problems however; map exploits are already here since the map is client-side, but with this approach monsters would also be client-side( all of them, not just those close to the player) and you'd be able to move their position around at will with a hack. You could implement probability checks for that...But what if the AI is hijacked and set not to respond to the player? A map full of inactive enemies would be rather easy... So you'd need a check against that too. I'm just saying, it could end up being far more work than it's worth. Tons of things that could be exploited if it were all client side. At any rate, I think the point here is that desync is *far* worse than it actually has to be. Yes, desync is unavoidable with the current setup, but I'm firmly of the belief that, short of packet loss and very high latency( i.e. 200++), you should be able to counter just about all the actual symptoms of desync in terms of being noticeable to the player. Right now you can have crazy desync with a stable 70 latency and no spikes, which is just unacceptable. And stuff like the rolling stone golems... Ugh. So I think they're either being way too stingy with the bandwidth/servers, or there are one or more large'ish problems with the client prediction simulation. RE:D3, it's been a while since I played it, but I'm pretty certain it had collision detection on monsters( though not on players)...Maybe it's just that they made the collision boxes really small? |
|
" D3 had terrible terrible issues with desync and rubberbanding and hardcore characters dying to stupid situations for a very long time. Like stupid amounts of rubberbanding where you had to give up control of your character for several seconds in order to escape your current rubberbanded prison. Mechanics like descecration and other ground effects, especially speed reducing effects for both mobs and players caused serious sync problems. (and D3 was a AAA fully released game) Hey...is this thing on? Last edited by LostForm#2813 on Apr 4, 2013, 10:47:41 AM
|
|
" I, for one, am extremely grateful that all you experts on desync who've made your own flawless AAA game engine are here to tell GGG what they're doing wrong. I think it's great that every game engine - especially proprietary ones - are exactly the same so what works in a whole bunch of others will work in every game ever made. I just wish GGG would wake up and listen to you all! IGN: ScrubcoreRulezBitch
Alt: HardcorePwnsScrubcore |
|
To the OP:
While generally a very good write up on the basics of client server technologies I just have to nitpick on a slight misusage of terminology. I find it meaningful since you are trying to educate people and using wrong terminology is less than optimal for that :) " Every single game needs to deal with latency. The very first example you explain of 'dealing with desync' is the example where the game does not need to deal with desync since it eliminates desync by being in an always synchronized state. Hence no desynchronization. It is instead dealing with latency. Here's the relevant snippet where you explain the system that has no desync: " Sorry I snipped the paragraph, it's pretty much spot on and nothing wrong there. General examples of these synchronized games are most RTS and DOTA-like games (which basically are on RTS engines anyway). They are always synchronized and the players deal with input lag, not desynchronization. And finally once again my apologies for being a nitpicker, can't help myself. Apart from that slight misusage of terminology I found your article being pretty much spot on on how the basics should be described :) tl;dr; latency problem - technical problem caused by the time it takes for messages to move between server and client - plagues all networked games, even ones played in a LAN desync problem - problem caused by clients going out of synch with server or each other - plagues games with inadequate network code design and/or implementation |
|