Client-server Action Synchronisation
|
Something I dislike about all attempts to explain desync on this forum is that the conclusion is always that a real-time online multiplayer game has to choose between desync, unresponsive controls (i.e. the "synchronous action model") or being overrun by cheaters. This doesn't match with my experience. I have played plenty of other games (RTS, MOBA, other RPGs,... ) that didn't choose desync and didn't have problems with the other issues either. And it's not like none of them was able to support "hardcore game mechanics like body-blocking, stunning and missing".
Anyways, it is true that desync is manageable once you have an /oos macro and know when you have to use it. Therefore, it would be great if you didn't need a third party tool and if you had more freedom when to use it. The 10 seconds cooldown is enough most of time, but sometimes, when fighting in a crowded, narrow area for example, it would be nice if it could be used more often. |
|
|
Just 2 things:
People that say the game's unplayable because of desync should either fix their interwebz or learn to play because it really is playable ESPECIALLY when you're aware of this problem like you are PoE is not going to use the same mechanics as D3 but it's probably not because of the latency (unlike Chris' motivated, read my post on page 5). It's because they want to keep the current client-server system as it is either to prevent cheating as much as possible or because they don't have the resources (money/servers/time/developers) to change to the same client-server system as for example d3 uses. Last edited by Startkabels on Apr 21, 2014, 5:51:39 PM
|
|
|
They also could use tools like Punk Buster to prevent cheating. ;) Everything would be good enough as long as clients/servers can stay in sync. Or even better solution: do "server only" gameplay where the client only shows what goes on on the server, (World of Tanks model ), bullet (and cheater) proof for sure. Input from client is sent to server, server checks and if input is OK, then do action, and not before that. Result is sent back to client, voilà: zero desync.
Last edited by Fusion_Power on Apr 21, 2014, 6:01:08 PM
|
|
" This was akin to my recent thoughts on the game. It feels like there's more "crap in the way" than ever before. Last edited by Hatchett222 on Apr 21, 2014, 6:11:01 PM
|
|
|
removed
Last edited by Startkabels on Apr 21, 2014, 6:23:00 PM
|
|
" Voila, yes... You know the best solutions is not always the best solution in a technical way. Like a mentioned 1 post above yours: The best solutions often also involves things like money and resources.... Last edited by Startkabels on Apr 21, 2014, 6:24:16 PM
|
|
" Chris was also addressing this specific architecture and commented on it: " I totally agree with him, as I had it happen when playing a RTS online (it was Starcraft I think) with a ping >150ms. (Usually though, luckily enough, I can play with ~30 to 50ms delay, which is fine). I absolutely hated that feeling of nothing responding immediately and would probably quit the game after some minutes. (It can also be seen in PoE at times: In the evenings the European server seems to be somewhat crowded and responds slower - might also be my ISP that causes more lag at those times. And when I then try to rearrange my stash or do other things which involve manipulating items, it becomes pretty aggravating: Click - wait - done. Click - wait - done...) Crit happens. Last edited by Inarion1986 on Apr 21, 2014, 7:10:52 PM
|
|
|
well desych has gotten way worse over the last year as they add more and more sprites and lighting effects..
Any map that contains walls, and doors are the absolute worse. I can stand still not attacking and warp in to a next room and get killed by 5 mobs blasting my face. When in the few mins before warping there, i was fine so i never pressed 1-2-3 to heal. why would i,I was perfectly fine, and hadn't taken any dmg.. the val areas seems to be really bad don't matter if you are melee or ranged holding shift or not it will warp you to where the mobs are. Thats where the server says you should be. any ways its the only complaint i have about this game so its not a huge deal.Its annoying.its sometimes very upsetting and forces me to take breaks and not play for a few weeks. Spending hrs getting some things accomplished and then all of a sudden you lose all of your hard work do to synch death. my two cents.. |
|
" How many MMOs have you quit because they were full of cheaters? I can name a lot. Even god damn Valve is fighting with cheaters 24/7 because of trusting the client a little, and even with those intrusive ways of looking into your DNS cache they still never purged all of them. In all other cases the game is too slow for Desync to happen, or is carefully downgraded around it (See D3). In the end, in a theoretical case for faster games, the best way to do it is the way an RTS or a MOBA does it, which is also the SIMPLEST way to make a client/server connection (I will give some credit to GGG for going the hard way), but that would mean: They will be obligated to buy more servers in other parts of the world, money. (This is also a good move even with this model) They will have to make a better/different server structure to allow cross-server interaction. It will be very noticeable, even for ~50 ping players, even so that blizzard decided to not go for that model with D3. If they buy more servers and upgrade the desync detection/client prediction it will be fine IMO. | |
|
What is driving so many of us up the wall is the near constant equivocation over "desync". Now I fully expect this from regular forum posting, but this is coming straing from GGG.
Chris starts off talking about the asynchronous actions of the client and server. Which because of the distance the two will not be exactly the same. This is of course something that will exist in some form on every online client. This must exist because of the client/server nature and calls this desync. Then he goes off to talk about how this manifests in this particular game and again calls it desync. And we end up with the incorrect statement which seems to be the repeated mantra: Because desync [client/server nature] cannot be eliminated, we cannot get rid of desync [his particular manifestation]. Because asynchronicity must exist in some form between the client and server is not a valid excuse for all possible asynchronicity between the two. Or more simply, it most certainly could be better. Now with the current zero client trust model (which GGG isn't abandoning and I'm not proposing they do), this means any asynchronization is the client's fault, by definition. So we are left with a situation of resyncing which causes jerkiness in the client or such frequent resyncs to eliminate the jerkiness that instead stress the server connection. I mean those must be the only possible situations right? Chris mentions serves that make allowances to speed/collision that could open the door for speedhack/etc. Reverse the thinking here. Have the client make those allowances. I guess I question why the client should necessarily calculate the exact same mechanics as the server, when the client is effectively only trying to mirror the server. In a client trust model the server will accept situations that actually couldn't happen, well in this case that's what the client needs to do, but the client version still rigidly calculates exactly which in turn makes any desync worse. Let's go back to speedhacking. I'm reminded of one of the first times I watched someone else in a game speedhack. It was quite obvious that they were moving far too fast, but the motion was all fluid and not at all jerky (I'm aware it can depend upon the game in question and hack in question as to whether or not this is the case); if I did not know for a fact movement that fast was impossible, I wouldn't have found anything out of the ordinary. I've talked around without getting straight to the point, there is no reason things like this cannot be used, completely client side with no change to server calculations, to resync as opposed to the only option being the jumping around of /oos. Have the more frequent resyncs (not to the degree that will cause server stress), have the server report the same information, have the client interpret it as fluid movement rather than a jump and this fluid movement can be malleable with speed/collision. With fluid resyncs GGG would be able to have a lot more freedom to trigger a 'soft' resync under whatever conditions without worrying about the 'tradeoff' of small more frequent resyncs. Last edited by RevDr on Apr 21, 2014, 7:41:03 PM
|
