October 20th note: originally posted this over on the hardcore forums, I ended up deleting the multi-part posting (the entire topic was already 10 pages deep) due to the lack of views/constructive dialog. Two specific individuals that I placed on ignore were basically just being non-constructive and without a wider participation by the actual community, I figured with this sadly apathetic response, that it was no longer worth the time and effort to bother forcing the issue (plus I no longer really care given the system 2.0 patch changes that sort of takes the edge out of avoiding the permanent death angle).
Since I couldn’t delete the thread outright, the only way I hoped to get it locked (as living proof of just how apathetic the response was) was to delete the main postings such that any future bumps would be seen by the moderator as being irrelevant. To the few who did provide useful feedback and asked great questions, you know who you are.
Original post as follows:
Note: this is unfortunately going to be VERY LONG since I wanted to try and cover a lot of ground regarding the whole disconnect mechanism in Diablo III, and be as articulate as possible. If you don’t like to read walls of text, stop right now and go read something else.
Yes, I know there are many other topics about this such that this is “Yet Another Damn Post About Disconnects”. But I didn’t want to pollute those other threads with what I’m about to post.
This isn’t my first time giving my 2 cents about the whole issue either. I changed my BattleTag to get rid of a spam issue over on Asia so all my past posts are no longer associated with my current post history (yet another poorly implemented function with their forum code) as well as losing a portion of my in-game friends list (even more awesome coding Blizz but thats another issue). The following were some past posts…
I was planning on writing the following eye bleeder back in August over on General but there was that thing called the RoS announcement which took place. GD has always been a zoo and went further downhill after the AH removal was announced… thus I changed my mind about posting something like this there since I don’t want to get trolled a thousand times over by those who won’t get past even these first few paragraphs without asking for a tl;dr (can’t do that with a topic like this).
To make it easier to read, I’ve broken up each section into separate postings (since I can’t put it all into a single one anyway).
General Overview:
Blizzard Entertainment made a conscious decision to make Diablo III online only. By nature, this means that any game session can potentially be interrupted due to a wide variety of factors. Some of these factors are totally within the control of the player (these include making sure their equipment is in working order when it comes to computer hardware, software, network settings at a bare minimum).
There are also issues that are completely outside the control of either the player and Blizzard. The distributed nature of the Internet naturally means there are multiple points of potential failure which can interrupt connectivity between the game client and the game server. This packet loss is measured in the form of network latency. Some examples: localized power outage, localized (ISP) network outage, unannounced ISP maintenance, wide area network issues (re-routed packets due to some backbone related issue).
Similarly, there are also those inopportune times when something goes haywire with our equipment on the premises; cable/DSL modem problems, computer hardware crashes, game client freezing up, cat/dog chewing through your ethernet cable, etc.
Each one of these singularly or in various combinations can cause an interruption of network connectivity between the game client and the game server. Thus logically, the network exception handling and error recovery that exists on the gaming server should be able to gracefully handle this loss of network connectivity.
The reality with Diablo III is that this handling is nearly non-existent. By this, I am not talking about the 10 second countdown timer. That mechanism is for a completely different function. What currently happens in any of the above scenarios is that you lose complete control of your character; it remains motionless in-game at the mercy to whatever is surrounding or converging on you until the server has determined that it has indeed, lost connectivity to your client. Only once that determination has been made, does the 10 second countdown timer begin to remove the character from the game.
In most cases (depending on gearing, skill set used, monster power), the character will be slain well before it gets to the 10 second countdown timer. Basically, the lack of a robust network exception handler server side is a critical defect/flaw in this online only game. All too often, the focus is on the actual disconnect and not about the flawed server side implementation in terms of the amount of time that it takes for it to recognize that an actual disconnect situation has occurred.
For a game that is online only, it is the developers responsibility to implement measures that elegantly handles such situations. The handling and error recovery of network related exceptions is not a new thing. Most modern games have ways that deal with it in some fashion. Two of Blizzard’s other IP’s, WoW and StarCraft 2 both deal with latency and disconnects far more elegantly than Diablo III. What is wrong with this picture?
Furthermore, one of Blizzard Entertainment’s objectives is ensuring that all players can fully enjoy their gameplay experience (much of this is alluded to in their in-game policies):
Since hardcore mode is offered as a specific feature of the game, these same policies should extend to this demographic of the player base (even if it is a small one). We already have a permanent death policy which as of 1.0.7, includes a no rollback clause; I have no issues with either of these. And while the easiest rebuttal to all of this is “play softcore”, that misses the point completely when it comes to the gameplay experience in hardcore mode.
Disconnects are actually rare:
I personally worked in the data networking arena for 2 decades (Cisco routers, layer 3 switching, operations which included trouble resolution and NOC monitoring); I can say that the Internet is mostly resilient when it comes to re-routing packets. Why? Because for the most part, the backbone is architected with high availability in mind. Providers we peered with proactively monitored and constantly provided both automated and priority calls when it came to network issues (evenvery short outages) or when they needed to re-route our backbone traffic. At the highest tiers, this is standard operating procedure which adds to the overall resiliency of the overall Internet backbone.
When talking about backup/redundant links though, not all are low latency and/or take routes that require more hops (these alternative routes go through different peering arrangements to avoid another local/regional/geographical point of failure). They are meant to keep packets flowing though so that eventually, the data can get to its destination.
Basically, packet loss is unavoidable but pure Internet outages are also rare to the point where it can cause the complete loss of packet exchange between the D3 client and the D3 servers. The issues with these types of outages are normally at the edges (closer to the ISP and/or source) or due to some of the other nasty stuff that happens on the net which can affect traffic (like botnets and/or DDoS attacks).
True, not everyone playing hardcore experiences disconnects. And honestly, they are usually rare. For myself, they were almost non-existent (just 3 since May 2012). I don’t play on wireless, my main ethernet switch is a Cisco Catalyst, and I have all my systems and networking equipment on pure sine wave UPS’s. That particular aspect isn’t for gaming (it just benefits from the setup); it’s because I run my own servers for my contract work.
The first was a complete server side issue since everyone got booted from the game (as well as from many other instances terminating), the second was a disconnect my now dead P22 had managed to survive, the third was an ISP caused disconnect which my witch doctor over on Asia managed to survive. In between though, I’ve lost several lower level characters due to some pretty bad lag spikes and have had to play through them on my level 60’s (avoiding death several times). I even posted these experiences here in the past:
The following is the disconnect that I had managed to survive before:
The point of bringing these past postings up is that none of this is new to me. I’ve been aware since I clicked the “Accept” button on the Permanent Death disclosure that I could get eventually get taken out that way and had been to that point, lucky. Then in August, that luck finally ran out; I finally encountered a disconnect that took out a Paragon level character (my wizard over on Asia). Six days later, I lost the above wizard the same way (also happened while I was playing archon mode as opposed to playing my usual inefficient kiting build).
Since the client cannot take a death screenshot when a disconnect occurs (server can’t communicate that actual event back as the connection has already been torn down), the only way to find out what actually killed you is to archive the character. My Asia wizard was slain by an arcane sentry (haven’t archived my US one yet though). However, when using my archon beam just prior to noticing something was wrong, I hadn’t been around any elite mobs (or at least what the client was showing me at that point). Refer back to the forced latency video where mobs that weren’t there suddenly appeared.
This again highlights the defective design; the latency meter itself is flawed because that humorously is a lagging indicator (by the time the bars change, your already at least a half-second or so into the anomaly). There are certain thresholds where things like monsters won’t display on the client until it has received that information from the server. The rest should be self-explanatory when it comes to finding your character suddenly in some situation that you didn’t even see.
To this day, I don’t know what the root cause of those disconnects were (I do know they weren’t ISP or equipment related though since in those two d/c’s, I remained connected to the Battle.net chat server).
How high latency and disconnects are currently handled:
During periods of high latency, the transmission time between client and server increases; there is a certain threshold though where the game becomes unplayable (more on that in the following test video) due to the amount of time it takes for the commands to reach the server, and to then send the action back to the client. This leads to desynchronization between the client and server not only in terms of attacks but also in movement and positioning. When it comes to playing hardcore on Inferno difficulty, the results can be deadly due to the loss of granular character control.
When a disconnect occurs though, this leaves your character idle/vulnerable in game at the mercy of whatever monsters are in your vicinity until the server actually registers that it is no longer in communication with the client (a process that has been tested by myself and many others with times lasting up to a full minute), at which point, it will finally begin the familiar 10 second countdown timer to remove the character from the game. Normally though (especially in Inferno difficulty), your character is slained well before it even reaches that 10 second timer.
A common misconception is that this 10 second countdown timer is the disconnect timer. It isn’t. This 10 second timer was added to prevent a quick game exit (when not inside of a town) as a means to cheat a surefire death situation.
There is currently a 30 minute idle timeout such that if you AFK and/or place a single player game into a paused state, after half-an-hour, the server will automatically disconnect the player from the server. If the character is not in town at the time, the server unpauses the game session after 30 minutes, the 10 second timer begins, and the character is removed from the game once that 10 seconds expires. This is also why when you try and exit the game from outside of town, it has this 10 second timer (and also why casting a town portal isn’t immediate). It’s not easy to quickly exit the game to avoid certain scenarios.
If a secondary login is attempted (like say the player completely disconnected from Battle.net and has to log back in again or has another computer already at the login screen to force an “immediate” boot), the current rules apply: if the player is in town, their current game instance is immediately terminated. If however the player is not in town, the server will unpause the game, the 10 second timer begins, and the character is removed from the game once that expires, before the secondary login is allowed through. This therefore eliminates the ability to pull the network cord or to force quit out the game to avoid a quick way to cheat death.
Video Examples of High Latency:
The following video was made to illustrate the effects of high latency (ignore how my character is geared and the skill setup – it’s for the purpose behind this test).
I’m artificially induced latency (the first two minutes is basically just me trying to get the meter to around 2600ms). It’s easy to see the affects at this high level of latency though once I start casting spells and moving around. Everything that I do is delayed by almost 4 seconds. What initially looks like a clear area actually isn’t once I rubberband back to my actual location once that information has been transmitted from the server to the client.
In the next clip, it shows just how highly desynced the character becomes in terms of positioning, how long it takes for the actual monsters to be displayed, how long it takes to transition into a new zone.
However, I’m also inducing even more latency (up to 3700ms) as I’m trying to force a disconnect due to high latency. I’m doing all kinds of nasty stuff including a simulated attack on the ingress port of my router as well as opening up a huge number of tcp connections on this computer (in addition to bandwidth throttling on both upstream/downstream channels). In simple english, this is not the normal kind of latency one will usually ever see for any extended period of time unless is it a situation closer to ones point of presence (local hardware problem, infrastructure issue at the ISP, local routing issue).
When I tried this over on Asia (where my normal latency is around 260-320ms), I managed to get the in-game meter as high as 9000ms. But I couldn’t force a disconnect to occur even at that level. The point was to show how resilient the game client is to disconnects from excessive network latency. Note that I’ve found the playable limit of the game is around 450ms but requires that you consciously begin queuing any attack and movement sequences at least 1-2 seconds in advance (that’s about the only way I could effectively play through Inferno over on Asia).
This is completely different from the high amount of game actions overloading the command input to the game server where it eventually forces a disconnect. You see this with certain class builds (which also causes client/server desyncs), performing too many AH search queries in a short period of time, quickly searching for public games (in the latter two cases, one will normally see a “input limit reached” message since you aren’t actually running a game instance on the game server).
As shown in the above videos though, there is currently no server side handling with even high latency as you can still continue playing even though as that latency increases, certain commands and actions can actually be lost (each 50ms increase in latency results in a higher loss of granular control with attacks, movement, actual position). And we all know how actual disconnects are already not handled where your character will come to a stand still and have to handle any aggroed monster on its own.
Which leads to an interesting question. Because I’ve never been able to cause a disconnect to happen because of excessive sustained latency, what is the root cause of game server disconnects (not caused by gaming actions) when most everything else remained unaffected (like remaining connected to Battle.net for example).
If anyone who has gotten this far still thinks this isn’t a flawed design in an online only game, you can stop reading now as nothing else I write will make any difference in changing your mind.
Hypocritical Design Philosophies:
The Diablo III developers are always mindful about this desire for diversity in terms of builds and playstyles (which is why they perform these occasional balance changes to class skills as a means to promote the use of other skills and therefore, a broader array of playstyles). Yet, the underlying flawed handling of network anomalies server side, does end up affecting the mindset of many hardcore players when it comes to dancing around the whole lag/disconnect issue.
If you’ve ever felt like not playing your main hardcore character after server maintenance due to the potential for instability, explain exactly what is wrong with that picture?
Not everyone wants to run co-op all the time. Yet, it is one of the most often brought up suggestions as a means to increasing survivability from lag or disconnects. While playing in co-op does help increase the chances of survivability, it’s an illusion of safety and is like disconnects, one where the outcome eventually won’t be a positive one the longer one plays. It’s not a solution to the root cause issue.
A portion of the hardcore player base have pigeonholed themselves into building characters to be more EHP focused (again, my point is this D3 development team pumps out PR fluff about diversity but then offers up other things in this game which go against that philosophy).
The changes coming with Paragon 2.0 are meant to help take some of the sting out of hardcore deaths but this seriously is not a solution to the real underlying root cause issue. When I die in hardcore, I want to die because I made an idiotic mistake or a completely erroneous decision. I want to always go out swinging though. Getting killed because of lag, a computer or game client crash, and anything else that ultimately ends up registering as a disconnect is a pretty lame and anticlimatic way to go out. Sure, I will no longer lose the associated experience with the new system but that misses the point entirely. And this is the key fundamental problem I have with the design philosophy with the D3 development team.
All too often, it is OPUD (over promise, under deliver). Rather than address core underlying issues, bandaid fixes are applied leading to more problems. Monster Power was promising but not executed well (led to maximizing DPS to handle excessive monster HP – revealing how broken LS is – exposing even more underlying design flaws in the core systems of this game).
Paragon 1.0 was a bandaid fix (illusion of progression) with not much thought put into it (thus exp gains stopped at 100 which is the exact same mistake pre-Paragon where no exp was logged behind the scenes once one hit level cap at 60). This of course leads to the current situation with their trying to design a transition from character to account based Paragon as well as how to handle that transition when it comes to hardcore characters. This lack of forward looking vision (when it comes to something as simple as continuing to log experience gains behind the scenes) shows up in other parts of the games design. That includes the subject matter of this post.
Even the developers acknowledge it’s an issue:
Wyatt Cheng:
I wish the game could be more disconnect friendly. I don’t have a lot to say, I’m not a super expert on disconnects; but as long as we’re talking about hardcore, some people are asking about that. We’ve talked about it. If it was a perfect world, you wouldn’t lose your character with disconnects. The truth is that, what we don’t want is to be in a situation where if you think you’re going to die, the right answer is to pull your network cable out of the wall. Which means that we would need to differentiate between a staged disconnect versus a server issue on our end. The issue with server issues on our end — the server’s not supposed to crash. Our server engineers are really amazing people. But obviously crashes do happen. If the server is crashing, it can’t save your character, because it’s crashing! It’s a funny suggestion sometimes when I see it, but that’s the reality. And yeah, you know what? It’s rough and it scares me when I play hardcore, too.
The above shows that he is correct about not being a super expert on disconnects because he is confusing the issue of game server crashes with the issue of network related issues which leads to the current situation where a character ends up mostly defenseless in game as it waits for the server to acknowledge there is an issue with its connection with the client.
Server crashes are what they are when it comes to saving the state of a character when the hardware and/or software is going down. Those are likely not the cause of most disconnect related deaths though.
Here is what Travis Day said about hardcore:
I don’t do a lot of hardcore, because I’m a giant sissy and I’ve always said I’d get really angry if I got disconnected from the internet. But I definitely was leveling a hardcore Witch Doctor at one point. Because I was like, well if I’m gotta play hardcore I’ll hide like a little girl, and throw spiders at things I can’t see, with lots of pets.
While it’s a humorous tongue-in-cheek sort of response, these kind of responses by key members of the D3 development team does not inspire much confidence that these guys really do understand the current flaw in how network related exceptions aren’t properly handled and how it currently detracts from their objective of making their games a safe and fun gaming experience for everyone (don’t care if the hardcore demographic represents just a tiny fraction of the player base either; this is their game which included that game mode and should therefore have a measure of quality throughout).
Note that while I’m highly critical of the D3 developers, that should not be construed as meaning I’m critical of the D3 community management team. They are hand tied because PR-fu becomes a delicate issue when it comes to directly addressing topics like this. Lylirra did respond once to a posting by Norc regarding the issue:
That at least initiated the starter feedback but as it stands, if the community is just going to decide that Blizzard shouldn’t do anything, then don’t expect it to go up anywhere in the priority queue (and we all know they have a full plate when it comes to fixing the deficiencies in this game).
Potential Solutions:
Their colleagues over in StarCraft 2 have done a much better overall job on their game client including an autopause on high latency implementation. Is it perfect? No it isn’t. But they seem to at least have a much better understanding the before-mentioned issues can have on the game play when it comes to their highly competitive player base not being put at a disadvantage due to latency (where one player will suddenly now have the upper hand when someone else is encountering high latency).
Backing up just a bit, community manager Bashiok (now with the WoW team) wrote the following about Diablo III’s in-game latency meter:
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.
This makes absolute sense as to how the SC2 and WoW teams built in an autopause on high latency system into their respective games. The system is able to gauge network latency between server and client, then do something with it. In Diablo III though, that system shows your latency but doesn’t do anything meaningful (where it counts) with it. How does that make any sense? If it’s main task is to change the number of bars and colors (along with the numbers), then give me a break.
A disconnect situation (by any one of the above-mentioned causes) will show up as 100% packet loss and therefore, extremely high latency. As a result, the game instance would autopause and follow the current pausing restrictions (mentioned above) that are currently in place which would prevent the usual quick escape from death situations.
At face value, the biggest obvious issue in D3 is managing such a system in co-op play. However, I don’t think those who don’t/rarely play SC2 really understand how the autopause system works in that game. So I made the following video using the exact same artificially induced latency.
The key thing to note here is the latency that I’m inducing is abnormally high and sustained (in otherwords, not normally what most people would see unless they were having severe hardware issues with their network equipment, some type of local ISP problem, the Internet backbone or the various region hosting provider networks experiencing a severe meltdown).
You can see the occasional stutter stops and a quickly appearing/disappearing dialog box. I had to increase the latency even higher to get the dialog box to stay open for at least one full second. Thus while the stutter stop looks seriously annoying, that’s because the latency was equivalent to around 4000+ms constantly. At lower levels of latency (but ones that are still annoying enough in D3 where your granular character control is going south with each 50ms of latency), you rarely ever see the autopause dialog box pop up (and the stutter stop isn’t as annoying). And normally, what most experience are very short latency spikes (so this example is an extreme that many will rarely encounter).
In a multiplayer game, the other players can vote kick me out before the 60 seconds expires (if I keep autopausing for 1 minute, I’ll be automatically kicked since I’m no longer conducive to the game play).
Obviously, such a system would work quite well in a single player D3 game. What about in a co-op game? This is where the implementation issue resides mainly due to the high paced action in a D3 game. Even just a tiny amount of autopause stutter might be annoying when it comes to the multiplayer experience (again, the above video clip is at an exceptionally high latency level so you’ll have to imagine reducing it by a factor of 4 which in D3 terms, would still be a red meter at 1000ms). And most of us know how 500+ms feels when it comes to character control issues. Take this down even further to where they are occasional spikes, and does the system seem to be more workable in co-op as well?
In the past, one sugggestion I’ve made is to offer this system only in single player. However, I belief that it can still be implemented in co-op if a small command buffer is provided which can at least smooth out very short pauses (talking around 500ms latency spikes where something like a .25 second buffer is provided such that for the most part, the co-op game session will still play mostly smoothly). At anything above that, the above system kicks in full. The benefit to this approach is that the autopause will act as an in your face alert to all party members that one or more party members is experiencing an issue.
Exploitability Issues?:
This won’t be exploitable from a cheating death point of view in either single player or co-op because the same 10 second countdown timer rules that were mentioned above would still apply to this autopause system. For example, say that I’m in a co-op game and the latency is high enough that all party members are now staring at this dialog box. Suppose I personally choose to remove myself from the party (rather than wait to be vote kicked); when I do that, the game instance is unpaused for everyone and it will take 10 seconds from that point for my character to be removed from the game. The other party members can attempt to try and protect me at that point (or not).
Yes, I already see there is a potential for griefing in very rare circumstances if this happens in a public game (like what happened with vote kicking before) if one happens to lag out in a game that happens to be populated by folks that enjoy partaking in that activity. The question at this point though becomes does the tradeoff of having such a system in place outweigh those rare situations?
Final Thoughts:
I realize this isn’t the only solution to one of the biggest pet peeves for many who decide to play hardcore mode. I realize this also isn’t the best solution either. The purpose of this wall of text was to articulate my point as to why I feel the current error handling of network related anomalies (caused by various issues mentioned at the beginning) isn’t robust, nor graceful. IMHO, it’s actually low grade quality to the point of being a huge design flaw/defect in Diablo III when compared to StarCraft 2, WoW, and many other online games which at least attempt to address it in some manner.
And yes, I also understand the honest versus dishonest player aspect. It’s sort of like offline mode in D2. Using a hero editor is fun in the beginning but after the novelty of it wears off, it’s actually fun to play the game legitimately. Most instances, that meant playing on the actual Battle.net realms (not full proof since some players used exploits to crash the realm servers themselves in order to perform more nepharious actions). The same goes for Diablo III console. Anyone who finds any value in continually wanting to play the game will eventually play it without using hacks/exploits. Having your character decked out in god mode becomes boring after awhile to the point where there is no sense in playing.
Likewise, most players game play do not affect anyone elses in Diablo III. If I wanted a competitive environment and one that really required lots of skill/micro decision making, I’d just play something like SC2 only. D3 for me however is purely about having fun, punching demons in the face, and hopefully getting good loot (what the game currently is lacking in this aspect). Having tried out the whole self-found thing over on Asia before my main there d/c’d, made me realize how difficult the content can be when only relying on the RNG relegated crap that does drop for you. But in many regards, that entire journey was far more fulfilling as I pushed to the next MP level in terms of putting what upgrades I got to use, while taking on the challenge. Thus dying from a disconnect made that whole experience end on a purely anti-climatic note.
The System 2.0 changes to vanilla and RoS won’t really change the competitive dynamics that much with Diablo III. “End game for everyone” pretty much tells the story when it comes to the overall design philosophy behind the current keepers of the franchise. D3 will therefore never be the sort of competitive sort of game that parts of the player base are trying to make it to be when it comes to this whole “we need these anti-exploitation measures in place”. Still, I’m not advocating for the removal of the current mechanisms since I’m a firm advocate of addressing and fixing the root cause issues. In this particular case, it’s an online only game and it should therefore, handle itself accordingly as layed out in the above wall of text.
—
Followup(s):
http://us.battle.net/d3/en/forum/topic/10195249787?page=2#25
I would very much like to read a response from a Blizzard Network Engineer to the OP’s observations, suggestions, and overall theme; that is, a rebuttal – backed by data and evidence-based practices – if one can be managed; or an admission that the OP’s argument contains merit; or even an admission – if the desire is to “save face” – that Blizzard is aware of the sub-par design and implementation of its D3 networking and is working towards a balanced solution.
Something like this isn’t going to happen because it’s a slippery slope unless said NE wants to shoot themselves in the foot. They have a working networking/social platform that current Blizzard games are built on top of; Battle.net 2.0. Anyone who plays either WoW or SC2 can see what stuff is possible in those areas. So it wouldn’t be politically (corporate speaking) kosher for one of their Battle.net engineers to basically confirm that yes, the D3 team did a shoddy job in this area.
It comes down to each development team being responsible to code their clients to take advantage of the API’s offered on that platform. The thing that Bashiok mentioned about the in-game latency meter relates to this. The WoW and StarCraft 2 teams utilized that same backend system to provide some handling when it comes to latency and disconnects. The D3 team gave us a nice meter that changes the number of bars and colors.
—
I’ve seen some of your posts before Pr1m3v1l on the matter. I’ve actually read most of the recent ones but just kept silent since I had already typed up most of what I ended up posting here. While it does seem pointless, it isn’t. They do see it. That is why I linked Wyatt’s exact quote as you did in your postings. To be fair, those guys are game designers and it isn’t surprising they aren’t going to be very versed with the networking related aspects of the platform; however, there is something called communication and reaching out to those within the organization who do understand that aspect of the stack.
As mentioned, the community managers are hand tied since all they can do is communicate these issues to the developers. It’s part of their core responsibilities. It’s up to the developers at that point to prioritize and do something about it even if that means just getting the proper engineers into the same room in order to begin some type of dialog (this is often times, easier said than done). If nothing happens there, the CM’s will hear nothing back, and therefore, cannot tell the player community anything.
Having worked in the IT field though, I’ve seen enough internal walled off gardens and pure lack of communication within the same organization to know better that there are these same sort of issues in a place like Blizzard as well. And if you’ve ever heard any of the stories regarding some of the huge egos that exist in the development community (not just Blizzard specific but tech as a whole), the higher level developers sometimes look down on those system and networking engineers who handle the less glamourous aspects (and there are more than enough confirmed insider info that there are a lot of these dev types at Blizzard on all of their teams). Likewise, there are quite a number of system and network engineers who are as equally obnoxious and don’t play well with others.
Furthermore, during the fansite summit that many of the Diablo related sites had the opportunity to attend earlier this year, Lylirra made a comment to one of them, that any work/features that entails Battle.net engineers, requires approximately 2-3 months of lead time (and much of the priority of that is relegated to WoW due to the subscription aspect, then comes SC2 due to e-sports, and D3 brings up the rear). I’ll reserve comment regarding some of the stuff I’ve heard about Battle.net 2.0 itself (let’s just say, it isn’t flattering).
I’ve also had enough personal experience to see what bandaid type fixes do over the course of time (things just get worse where not fixing the problems at their foundations, causes more issues and problems in the future; end result is it costs more in terms of engineering time which leads to higher expenses all around to fix what should have been fixed to begin with).
And it is my belief that the only way to get things fixed properly (and this goes for things outside of something like a game such as this) is that the issues have to be communicated as articulately with as much details as possible. That’s about all that can be done. No, it doesn’t anger me one bit though that they aren’t doing anything. It’s nothing new but as the saying goes, what comes around, goes around.
And as far as this whole thing seeming to fall on deaf ears within this community, I actually find it absolutely humorous (especially the guy who wanted a synopsis when I saw his other topic asking whether or not it was worthwhile to make suggestions on how to address the D/C issue after his character got wiped by a D/C).
This just tells you that folks are plain lazy and don’t want to take the time to understand the details and issues that are involved. But that is what happens when people generally want all the details in a Twitter like 140 characters…. The other fact is that the subject matter is beyond most folks technical understanding; there is nothing wrong with that which is why my entire text ended up being that long to begin with (and there isn’t any other way to make a difficult subject matter, any simpler). That’s the other irony, lot of dissent about D/C’s, when often times, not all the facts are presented…. and when someone does…. silence. I don’t know but I find that funny! xD
What I don’t appreciate though are folks like that other guy who basically makes it seem like a solution is difficult to implement when he himself, offers no details or constructive feedback (look through his post history in topics like this; basically says the same useless crap) as to why that is the case. People like that, I do just generally ignore/tune out since they offer nothing of value in terms of productive/constructive dialog (I just place folks like that on ignore anyway so I know not to ever have to deal with them in the future).
As the saying goes, Rome wasn’t built in a day.
P.S. thanks for your support as well as your own attempts at getting this addressed!
—
Why does the client not interact and reestablish connection? Twice this has happened where Internet works, but game doesn’t acknowledge it. Both times it took> 1 minute for the game to kick me out despite absolute proof of working connection within 10 seconds. Any thoughts?
This is why I made those two videos intentionally increasing the latency so that I could try to force a disconnect between the Battle.net, game server, and client. Because those tests show that this connection is actually fairly resilient in terms of its persistence, this gives me a better idea that certain network disconnects are being initiated Battle.net side (by this, I mean at a lower level than the gaming server; that sits on top of Battle.net 2.0). And its known the D3 game servers don’t handle network anomalies like this at all.
In that case, if the network disconnect was the established connection between the game server and Battle.net, your game session is still alive (but with your character now waiting in-game for the game server to register the disconnect before attempting to remove the character from the game). Since that persistent connection is now torn down, your game client cannot re-establish that connection. Hope this makes sense.
—
Why would you assume, knowing what you do about the nature of networking, that they have not implemented a fix yet? What are the benefits of doing it the way they presently are?
All I can say is look at the development of this particular game in general from 2008 until release. By this, I mean the design iterations they went through including scrapping the systems they spent time on to start all over from scratch again.
They basically spent more time re-designing the game over and over again (at times, making certain core systems worse in the process), which left less time for other things. This is why Inferno difficulty shipped the way it did because it wasn’t tuned and balanced properly from their original baseline scalings (this includes drop rates and the RNG affected itemization of ilvl 60+ loot). They had to remove features as well because they were running up against time constraints (even though the mantra is to ship when it is ready).
Making that in-game latency meter system more useful was likely not even something on the radar (plus at a basic level, the team has to be cognizant of the requirement for handling such anomalies) because they ended up rushing the core design to get the game out. Thus to answer your last question, there is no benefit to not making use of the underlying network platform/feature sets. The reality is they probably did not have enough time and for the past 1+ years, have been working to “fix” the core game systems (as best as possible since all that can be done are bandaid fixes at this juncture) while also having the majority working on the first expansion.
