06/14/2013 02:37 AMFixing the server recognition time is the solution. Even if auto pause was implemented the server stills needs to know the client is DCd.
Posted by CyLaNt
Implementing the auto-pause system that StarCraft 2 uses would actually help in this case. But let me back up a bit so that this all makes sense.Per Bashiok, the in-game latency meter is an actual system.
The latency indicator in-game is not a simple ping like most games, and is actually a full process of the game sending an action to the service, the service processing it, and returning it to the client.
The above is important because this can be interpreted as meaning this is an actual API that is built into Battle.net 2.0; where it is up to each dev team (SC2, WOW, D3) to implement in their client. The StarCraft 2 team has done just that where the game will auto pause once a certain threshold of latency occurs (I'm not sure if WOW has anything like this since I don't play it). I do play SC2 casually though and have experienced the auto pause a few times. If you are in a multiplayer game, the other party will also receive a popup stating that they are waiting for player XXXX. If after a certain period of time (I believe a minute) has passed, the other players can basically decide to have the lagging player removed. If you are playing a campaign or against the AI in a custom map/arcade game, you'll similarly get this dialog box while the game is paused. It's effective and works well.
For D3, that system would work extremely well for single player. Implementing this in co-op play would be an issue though due to the game pace of Diablo.
As far as using this underlying system for disconnects, that again is something that is theoretically much easier to implement in single player. Since the latency meter is an actual system process that knows when higher latency is occurring and auto pauses the game, that system would also have a better measurement of when an actual disconnect has occurred. If server and client are no longer in communication with each other( as in a disconnect situation), it would show up in this system as very high latency. Thus it would auto-pause and be subjected to the same 30 minute AFK disconnect timer; where the server will unpause the game to begin the 10 second countdown timer. This would help to alleviate the current setup where your character is sitting unpaused in-game and it takes the server up to a minute before it even recognizes that a disconnect has occurred before it begins the 10 second countdown. Characters are normally slain during that period before the server actually registers the disconnect.
This can't be abused because the D3 dev team already took care of the ability to pause and then force a disconnect (where after 30 minutes, the server will unpause that session and start the 10 second countdown to remove the player). If you attempt to login again before that 30 minute idle disconnect period has passed, the same thing will occur; the server will unpause your previous game session on the server and start the countdown timer. How quickly you can re-log back in again will be based on what happens during those 10 seconds (if your character survives, the authentication process will look like it is hung for around 6-7 seconds).
tl;dr - This is why I believe the latency meter and underlying process/system mentioned by Bashiok could be used to implement a similar SC2 style autopause on high latency system in Diablo III (at least in single player mode) which could not be abused because they already have the pause/forced disconnect angle covered. For situations where an actual disconnect occurs, the above system will notice the high latency and auto-pause; the character will therefore only be subjected to the 10 second countdown timer since that session will remain autopaused until either the idle timer expires or you attempt to login again.
Yes, I've read about what Travis Day wrote about not enjoying the possibility of losing his character to a disconnect and Wyatt Cheng basically stating he isn't sure how all of this stuff works server side, and how it is complicated to determine if a disconnect is really server side, result of AT&T's carrier routing systems hiccuping, failover failure (it happens), etc. Seriously, there is no need for them to make that determination in the auto-pause on high latency scenario. Rhetorically speaking, what they need to do is get with the Battle.net folks and/or talk to the SC2 dev team to find out how they are implementing their auto pause on high latency system (I know they have higher priority things on their plate which is why I said rhetorically). 2 decades of IT networking has taught me that yes, the application development folks don't always understand the physical/logical (where it is even more voodoo'ish) network side of things.