Client-server Action Synchronisation
" I'm surprised this part is mentioned. I might be wrong but I thought it was obvious what made these so desyncy. Cyclone: You don't desync due to enemy collision since you go through enemies. However you constantly bump into terrain, small objects or get stuck on a wall. This causes desync very easily. It being a movement skill means you'll often desync at doorways or trying to maneuver around a small object. Whirling blades: This is the fastest movement skill in the game. You will often turn sharp corners using this. If your character is even off by 2 cms then you will desync. Your character will often bump into walls/doorways when you turn those sharp corners and constantly get displaced making the desync more severe. The other common offender is getting stunned midcast. You will complete the whirling blades on your client while on the server you're stunned and still beside the enemy. The whirl is fast enough that you can travel several screens before you're forcibly resycned. Brutus hook: This seems to be a simple case of the hook "stunning" you and pulling you while the client shows you running away causing some major desnyc(you'd be in front of brutus on server while at a distance on your client). Correct me if I'm wrong about these. I'm just basing them on my experience with all these skills. To me cyclone is the worst offender since getting stuck against a small obstacle is so easy. Last edited by kasub on Apr 21, 2014, 3:10:39 AM
| |
" Although it's completely understandable (and agreeable) that rewriting most of the game would render this task daunting, and that in itself can be a reason not to pursue it, I don't think the "player in obscure country" argument has solid ground -- and I say this as (probably) one of those players. I'd be willing to bet that, for every single player you stand to gain from "obscure countries" you lose five from "core countries" due to the prevalence of desync and the state of its mitigation. Have you made a cool build using The Coming Calamity? Let me know!
| |
Maybe make doorways wider?
Sorry for my bad English.
|
|
" What are you talking about? Did you even read the post? They cannot simply solve desync by throwing money at it, that's now how it works. Desync has nothing to do with the quality/quantity of their servers. IGN: Jihokinetic
| |
" I think this is a minor point anyway, as playing an ARPG and having every input delayed until the server responds would be miserable, even if you have a good ping. IGN: Jihokinetic
| |
" and remove cliping elements from floors and DO NOT introduce VERY FAST monsters into a game that cant handle them that Snake from Docks Corrupted area - the one that spawns 10s of mini-snakes. all moving at insane speeds desync is a fact of poe, but poe is designed for a sunny day scenario - very fast mobs, very narrow doors, very cluttered tilesets. in a predictive system pathing is everything and current CONTENT design makes sure that desync occurs if you are unwilling/unable to fix desync reason - start from your yard and tone down mob speed and clean up the floor-clutter | |
" I actually encountered a pretty fun example of this the other day. I was doing a fleet map(35% movement) and encountered one of those running warehouse enemies that had a haste aura. I saw the rare enemy run at my character 4 times in a row when in fact they were still in the other room but kept desyncing against the doorway. This is of course an extreme situation since it's a fast enemy with double movement mods but it's very common for the enemies themselves to desync heavily without player involvement. I find that far more jarring than minor player desync. Not knowing if an enemy is truly there gets frustrating for some builds. Enemy pathing probably needs improvement. Last edited by kasub on Apr 21, 2014, 3:21:19 AM
| |
" i have 10+ years of SW architect experience and i quite well understand what is going on here. most of what youve just read in this manifesto are elusive excuses the mere existence of /oos should tell you that the CAN fix (alleviate) it, by simply sending full state (/oos) much more frequently. but this COSTS MONEY! so they do not. tehre is a reason why /oos is limited to once per ~10 seconds. to not overload servers and not eat up bandwidth. both cost money and a lot of it. this ofc does not solve false premise that thin-client implementation cannot give fluid experience (world of tanks - again - would like to say HI!). i also havent ever heard 'd3 is clunky'. d3 is very fluid even when playing on america servers from europe (160ms ping minimum for me). it feels different, but it is 100% responsive and 'rubberbanding' happens once a day or less. | |
"I can see you listened to my feedback on the rewording of this from the prior version. :) I'm also glad the opening post attempts to tackle the concept of resyncing too often. Finally understanding the concept was a bit of a "a ha!" moment for me, so I'm glad that others might be spared my unfortunately long period of ignorance prior to that realization. (edit: something sidtherat is apparently still struggling with.) I have two questions. 1. Have you considered putting more monster decision-making (AI) on the clients directly, instead of relying so heavily on the servers? By "decision-making" I mean the monster's decision to move to a particular location or to use a specific skill, not the effects of that skill (to include damage). It seems to me that the immediacy argument for current-player movement and skill animations applies equally well to the movement and skill animations of AI-controlled entities. 2. Have you considered going with the most likely outcome rather than the most favorable one? For example, let's say that, on the client, a player is hit with Brutus' Ground Slam. Based off the user's current evasion entropy (which isn't random) and what we know of the damage range of the Ground Slam, a stun might be more likely than a non-stun, even if the user has some mitigation (perhaps Heart of the Oak); let's say the chance of stun is 60%. So wouldn't it make more sense to assume the attack stuns the player on the client, assuming data from the server is somehow unavailable? If one has to guess, isn't the 60% chance better than the 40%? When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted. Last edited by ScrotieMcB on Apr 21, 2014, 3:25:13 AM
|
|
" Beyond cost that is a horrible horrible solution. That would make the game incredibly clunk and unfun to play. The current situation is bad but that's way worse. |