Diablo® III

One question for ur dev team

01/20/2013 09:40 PMPosted by CyberGoat
You've been posting driven since last year about how Blizzard is shoving D3 down your throat and how the game is flawed and on and on and on... and yet here you are: posting on a forum dedicated to a game you seem to hate! And you also continue to play! Hm. Interesting. I think you are the true troll here. You lurk and post how you hate the game, how it's flawed, and yet continue to play. I think you should take your own advice:


I've been posting not because I hate the game but because I hate the horrendous direction the series has taken. I love the Diablo series and I find it sickening that trolls like you care more about pissing people off and distracting us from improvements that *do* *need* to be implemented in the game. I think you confuse the words *have to* with *need to* or *should*...

Blizzard does *need to* listen more than they used to in the past if they wish to continue to have customers in the future and not just the present. They claim they have been, but with all the signs pointing to the contrary, it makes it difficult to see that they actually are (which they are, not very well in my opinion, but they are listening). This simply means they need to do a better job of it and make it more clear that they are indeed doing a better job and do care.

Blizzard does not *have to* care about their fans or the quality of their product, but they *should* as it is in the best interests to do so. I am certain that many members of the team care, but this doesn't mean that the business as a whole cares about anything other than profits.

I get sick of reading posts from people like you who pretty much treat this like a big joke. And you see Blizzard as this dog-eat-dog business in a dog-eat-dog world and Blizzard doesn't care and doesn't have to care etc etc, they don't *need* to care according to you. They're done more than enough according to your inferences.

If that's true, why are they in the entertainment/software industry? Why aren't they dealing in arms, oil or pharmaceuticals, or anything more profitable? That's the problem when, in an effort to stay successful and stay alive, a business cares so much about profit that they forget why they went into business in the first place. I assure you, while they do wish to make money, and deserve to, it isn't the only reason they went into this field. There are so many other things that they could be doing with their lives. They want to be a part of making games just like I wish to play them (heck, even I would love to test or help design small parts of games).

For example: As a teen and young adult, I played Diablo/Diablo 2 and expansion for many years off and on, sometimes casually, at other times almost religiously. It was a significant chunk of the later half of my youth. Not everyone falls into this boat, but I'm certain a lot of people do.

I'm not a hater like you weakly portray me as, I'm a lover of the game. But, someone can love something without liking its current behavior. I love the concept of a Diablo game in general...I like the dark, gothic-like atmosphere with the allusions to warfare between angels and demons and humanity stuck in the middle.

What I dislike is how Diablo 3 took steps backwards in many ways. I waited several years for Blizzard to say either (a) we're not going to develop Diablo 3, move on - or - (b) We're going to develop it and it is going to be the best Diablo ever and it's going to be super fun. But several years went by and neither case occurred.

The true hater is the person who jumps on a comment made by someone without any valid criticism or superior ideas of his/her own just to get a laugh or two from fellow trolls on the boards.

While I would move on in life and live just fine if Diablo never existed, within the realm of my gaming life, it is very important to me, and after waiting several years to play this game, I'm very disappointed in the product I paid for and after waiting so long and paying so much for it, I find it insensitive of people like you to suggest that I should leave the game entirely simply because I'm disappointed in how it turned out. That is my choice, and I might leave the game as many others have. I asked you to simply leave the thread because you were not contributing to it.

I sense that you know all of this (as made evident with your comment on my elite kills) and you simply delight in mocking me for loving the game so much. You, on the other hand, just like the drama your mockery causes. Are you trying to improve the game by attacking me? At least someone else came on and explained his/her perspective as a programmer. This perspective disagreed with mine but I like it because it added useful information to this discussion. You, on the other hand, just wish to cause pointless drama to get laughs. You really don't belong in the forums if that's all your going to do. Again, I don't waste time reading every single post that other posters make, so I'll just hope that you're more positively contributing in a different thread. You really should leave this thread though if you just are here for laughs and don't wish to add a genuinely helpful perspective.
Reply Quote
I've been a programmer for 10+ years, and this sounds like something a junior programmer would say (or a guy who hasn't work with a project more than a few 100k lines of code.. D3 is several million lines). Let me point out a few things that you, and other junior programmers out there may not have considered in your statement:
- The blue post points out that bugs need to be reviewed, fixed and QA'd. The developer performing the fix often spends the least amount of time on it of these 3 parts.
- Reviewing is to identify bogus bugs, prioritize importance, and determine the best dev to fix the bug. Can the cheap salaried dev do it?
- QA will extensively play test the fix to make sure it is both fixed, and nothing else is harmed by the fix. In some cases, they discover bugs that the public isn't even aware of, using tools to simulate large samples of play-time.
- Finally, for the dev working on any enterprise level software, it is imperative that any changes do not cause further problems. So to fix a bug, you need to do the following, even before it is passed onto QA.
A) update source to get the most recent code on your dev PC
B) replicate the bug, often needing to create certain items or an environment where you can see it happen. This may involve making requests for more details if the basic description of the bug is not reproducable
C) identify the problem area of the code. Often this is hard to find in millions and millions of lines of text throughout 1000's of files
D) contemplate what ramifications a fix could cause. For example, if a wizard is not supposed to be in permanent-archon form after teleporting, but teleporting does a memory copy for other reasons related to teleporting, then what happens if that memory block method is no longer used? Will your change break all teleport abilities?
E) Consider alternative approaches to a fix if step D brings up too many issues
F) Consider compromises. In some cases a bug CAN be fixed, but at the cost of laggy performance, or some other negative side effect. Maybe teleporting introduces a 0.25 second cooldown before ANY spell can be cast? That might be the cheaper safer way to fix it, but you might have to buff the spell some other way to make up for it.
G) Fix the bug. This takes less than 20 minutes for any decent dev, and usually comprises less than 5% of the time spent by the dev alone.
H) Verify you have fixed the bug following the steps from B), make sure nothing bad is happening. If there is, back to step D.
I) Boundary test things that you suspect could be affected by the change. Namely, does Archon work fine by itself? Does Teleport work fine by iteself? Do builds with neither spells work fine by themselves?
J) Review and contemplate if the fix will increase CPU, memory or network resource usage, adjust if possible. This is where the university degree is needed. Envision what's happening in memory and the CPU without being fooled by what you are seeing on screen.
K) Update your source code again to include the stuff parellelly developed by your co-workers while you were working on the bug. Pray they didn't change any code that affects your changes. If they did, back to step H.
L) Check-in your changes to the code repository.
M) Prepare QA release notes with details on test conditions. If you are concerned about certain scenarios, explain them to QA.
N) Provide notes that the public may see as a high level description, sometimes it can just be listed as 'fixed' with the original bug descrtiption
O) Wait for the software to be compiled by the build machine
P) Wait for the install to be made that allows it to be deployed to QA
Q) Cross your fingers and hope it gets through QA!


Lammy, I'm trusting that you are who you say you are when I say this but even though your post clearly disagrees with mine, I think it was probably one of the best posts on this thread. You just went down the list much more clearly stating what Vaeflare didn't state very well in my opinion. I thank you for posting one of the more useful posts in this thread.

I play devil's advocate. I try to get people to see the truth, even if I'm partially wrong. I still think Blizzard can do better. I could be wrong. I guess that's the "fanboy" part of me remembering how Blizzard used to be once upon a time.

Again, thanks for your detailed reply to the original poster.

~Philoi
Reply Quote
I like how OP ask's them why it takes so long to fix KNOWN bugs, and the Mod or Dev or whatever the hell he/she is responds by saying, "Design takes time, Coding takes time, art takes time, QA takes time"

Like... Really?!?! Were talking known bugs... on the PTR. Known ones. Things that you know about. Things that do not require QA, design, or art. All it requires is that the dev's fix it.

I've even coded a LOT of !@#$ and can tell you coding something completely new is time consuming. But, fixing a code line takes literally 10-20 minutes to find the broken line(s) and 10 seconds to fix...

The hell is this blue person smoking?
Edited by Swarley#1543 on 1/21/2013 12:28 AM PST
Reply Quote
01/21/2013 12:27 AMPosted by ActionBastrd
I've even coded a LOT of !@#$ and can tell you coding something completely new is time consuming. But, fixing a code line takes literally 10-20 minutes to find the broken line(s) and 10 seconds to fix...


Look, I'm with you in that 8 years was PLENTY of time to get it right. But please don't post silly claims like this. Have you actually coded blocks for a huge project like this? That's NOT how it works. Yeah, if you have a tic tac toe program you coded yourself, you can fix a bug and recompile it in a matter of minutes, but that is simply NOT HOW IT WORKS on this scale. Tracing a bug through endless class calls can take weeks on this level. Once the bad lines are found, they must be replaced. You don't simply write some new lines in; it must be committed through a version control system. It must then be reviewed by other developers to ensure no new bugs are being introduced and that the fix should work properly. Then it must be recompiled, and if the entire code base needs to be recompiled, that can take several hours. Then it must be tested internally. Finally, it can be bundled with other bug fixes and committed to the public test server after having a version attached. And if nothing goes wrong, after all of that, it may finally make it's way into the live version of the game.

And all of that is a massive oversimplification of the actual development process. It's so much more complicated than what I just stated.

You obviously have not coded for a project like this. Please don't make silly claims like "it takes 20 minutes" because you simply have no idea how the process works. Other than that, I'm on your side. Being a programmer myself, I felt like I needed to correct you. For all of Blizzard's problems, please do not blame the programmers. They have a tough enough job as it is.
Edited by Slappy#1530 on 1/21/2013 1:56 AM PST
Reply Quote


While there may indeed be a list of known issues and bugs that run alongside some patches, for every one you are aware of, there can be dozens or hundreds being worked on behind-the-scenes that you likely never be aware of. We do things just as quickly as we can, but even then, it’s a process that takes time.


so there could be dozens ?

if the answer is yes, then you haven't told us what the bugs was, shame on you. knowing that there are millions of bugs issue

if the answer is no, then why take so long ?

as you can see you got caught in your own traps, which ever way you look or answer the question it don't look good for you.

what an easy debate this was...

not to mention the fact that there could be dozens already tells me everything i needed to know.

would you buy a car that an owner goes, there could be dozens things that is wrong with the car.

i don't think you would buy it. i can go on and on just one of the many example...
Edited by THE5RINGS#1154 on 1/21/2013 2:17 AM PST
Reply Quote
One statement I’ve seen over and over on these forums and elsewhere are proposals for “easy” fixes and overarching assumptions about how long implementation for a variety of changes “should” take.

The reality is, game development is a hugely iterative and time-consuming process, with many people involved along the way. Design takes time, Coding takes time, art takes time, QA takes time: you name it. There are also multiple steps in the pipeline for each and every proposed change and bug fix, no matter how minor, and what issues are being worked on in what order and by who can and do change as new matters arise. Sometimes extra testing is also needed for bugs that come back broken and need to be retested, because we didn't want them to go live with a bad fix.

While there may indeed be a list of known issues and bugs that run alongside some patches, for every one you are aware of, there can be dozens or hundreds being worked on behind-the-scenes that you likely never be aware of. We do things just as quickly as we can, but even then, it’s a process that takes time.


You are wrong. There is one glaringly obvious fix that can be implemented damn near instantaneously. Now hear me out.....
1) Change the name of the game. Call it "Teddy-Bears and Rainbows Dungeon Crawler that is Definitely Not Diablo 3".

2)You get J.W. back in here as a CM, so he can tell use his "you don't know whats fun" powers and you have him tell us that Blizzard never released Diablo 3.

3)More profits for you when you come up with something worth carrying the franchise title.

Done. All is forgiven and i will await happily for Diablo 3 to come out "Soon".
And a tip to help you get started.

Don't have a act 2 minor boss that no one gives a $#!t about kill off a major franchise character. (much less in a zoomed in crap graphic cut-scene, come on you are Blizzard you know this crap gets done in a CGI video, not cool)
Reply Quote


While I would move on in life and live just fine if Diablo never existed, within the realm of my gaming life, it is very important to me, and after waiting several years to play this game, I'm very disappointed in the product I paid for and after waiting so long and paying so much for it, I find it insensitive of people like you to suggest that I should leave the game entirely simply because I'm disappointed in how it turned out. That is my choice, and I might leave the game as many others have. I asked you to simply leave the thread because you were not contributing to it.


You should get over it and move on. D3 will never be like D2

Skill trees will never come back
AH is here to stay
Itemization is more or less going to stay the same.
Drop rates are going to stay the same
No named games
Always online

Am I forgetting anything? people who keep complaining about these things are just dense.
Edited by Monsta#1979 on 1/21/2013 2:55 AM PST
Reply Quote
One statement I’ve seen over and over on these forums and elsewhere are proposals for “easy” fixes and overarching assumptions about how long implementation for a variety of changes “should” take.

The reality is, game development is a hugely iterative and time-consuming process, with many people involved along the way. Design takes time, Coding takes time, art takes time, QA takes time: you name it. There are also multiple steps in the pipeline for each and every proposed change and bug fix, no matter how minor, and what issues are being worked on in what order and by who can and do change as new matters arise. Sometimes extra testing is also needed for bugs that come back broken and need to be retested, because we didn't want them to go live with a bad fix.

While there may indeed be a list of known issues and bugs that run alongside some patches, for every one you are aware of, there can be dozens or hundreds being worked on behind-the-scenes that you likely never be aware of. We do things just as quickly as we can, but even then, it’s a process that takes time.


Are you trying to say it takes weeks or months to double the value of a number .... (50% weap dmg bumped up to 100% weap dmg) I honestly beleive the monk buffs took 30minutes to adjust those damage values.
Reply Quote
if you dont understand (or know) software developing, and you are just a windows user, please DO NOT POST your BS and ask for "quick fixes"!

there is no "quick fix" if you want Blizzard to behave like EA when it comes to support keep talking BS like those!

and for all of you complaining about the years in developing, it had nothing to do with the actual coding and patching and balancing!

the game took for ever due to project design issues, and decissions that where going all the time from one direction to an other!

Blizzard Developers (not project managers) should not be excuse them self for doing their job in the time needed!

@Vaeflare just ignore the lamers please.
@lamers go back to your console games and tetris and leave us alone.
Edited by Manrev#2748 on 1/21/2013 3:51 AM PST
Reply Quote
/ too busy, designing merchandise.
just see here, fantastic designed blizz socks :p

"Diablo III 3 Mistress Of Pain Socks Jinx Blizzard Officially Licensed"

http://www.ebay.com/itm/Diablo-III-3-Mistress-Of-Pain-Socks-Gamer-Jinx-Blizzard-Officially-Licensed-/130833185938?pt=LH_DefaultDomain_0&hash=item1e7643fc92

:D
Edited by SLeMM#2897 on 1/21/2013 6:44 AM PST
Reply Quote
One statement I’ve seen over and over on these forums and elsewhere are proposals for “easy” fixes and overarching assumptions about how long implementation for a variety of changes “should” take.

The reality is, game development is a hugely iterative and time-consuming process, with many people involved along the way. Design takes time, Coding takes time, art takes time, QA takes time: you name it. There are also multiple steps in the pipeline for each and every proposed change and bug fix, no matter how minor, and what issues are being worked on in what order and by who can and do change as new matters arise. Sometimes extra testing is also needed for bugs that come back broken and need to be retested, because we didn't want them to go live with a bad fix.

While there may indeed be a list of known issues and bugs that run alongside some patches, for every one you are aware of, there can be dozens or hundreds being worked on behind-the-scenes that you likely never be aware of. We do things just as quickly as we can, but even then, it’s a process that takes time.

!@#$ and release the duels already.
Reply Quote
Hey Vae, you're forgetting that in the develeopment life cycle, every time you fix a bug, you risk creating another one or more.
That being the case, lots of testing and revising of code - of course it takes time.

So called easy fixes are never that easy. Trust me i know I do web programming for a living.

(here comes the flame!)
Reply Quote
01/18/2013 07:34 PMPosted by Víðarr
The reality is, game development is a hugely iterative and time-consuming process, with many people involved along the way. Design takes time, Coding takes time, art takes time, QA takes time: you name it. There are also multiple steps in the pipeline for each and every proposed change and bug fix, no matter how minor, and what issues are being worked on in what order and by who can and do change as new matters arise. Sometimes extra testing is also needed for bugs that come back broken and need to be retested, because we didn't want them to go live with a bad fix.


While I agree that this is true, it is also directly proportional to the fluidity of the team at Blizzard, which includes the development team, management, testers and corporate direction. All of these components make up the overall team responsible for D3. On my main hand, I have nothing but respect for the developers and artists (both visual and sound) there. On my off hand, I feel the direction has been... well... less than desirable. The extended time to patch bugs and implement new content indicate a serious resource constraint in one or more components of the D3 team at Blizzard.

01/18/2013 07:06 PMPosted by Plutarch
I lol'ing at all these armchair developers here.


I am a "real" software developer. This is my first post in this thread, so I'm not bashing you or anything, just saying...
Reply Quote
01/18/2013 06:09 PMPosted by Vaeflare
One statement I’ve seen over and over on these forums and elsewhere are proposals for “easy” fixes and overarching assumptions about how long implementation for a variety of changes “should” take.


One of the main problems with people who don't do this for a living is that they simply don't know anything about the mechanics of developing software in a large enterprise. Whatever methodology you follow (the words "iterative" and the comparable regularity of releases is certainly a hint,) you simply have to go through tons more red tape than you would in a start-up indie developer.

Another major misunderstanding is that a fix is simple because the symptom is obvious. People out there just don't know that the price of fixing a defect late can be literally thousands of times higher than fixing it early. Google it, there is a lot written on the subject (Steve McConnell's blog is a good start.)

Just as an example of the two points above, I managed a customer escalation last week that ended up being fixed with one line of code. That change took approximately five minutes for the developer to check out the code, make the change, and check it in. Then a few more minutes times three for the code to pass peer review. That's a total of about 30 minutes. Then about an hour for QA to set up an environment to replicate the customer's, two more hours for manual QA and four more hours for performance regression testing. Per branch... so make that times three, or 21 hours. In the meanwhile, there was a total of three hours of conference calls of eight people on average, so that's 24 more hours. Now the fix has to go to production, on 16 nodes in order, a procedure that takes at least 30 minutes per node and involves at least two people... that's 16 more hours. And that, of course, needs to schedule in a service window, which would be available two weeks from now. Overall, the toll is just over 60 staff hours, and three calendar weeks, for a one-line fix. You do the math.

Some will say we should have caught the issue during development, and I completely agree. That particular code is covered in unit tests, automation tests, and manual testing. Yet it failed. It's one line out of more than 10 million that failed on one node out of 16 once in over a year. The odds are to catch that during development are... you do the math.

So yes, software development is a complex and error-prone process, and preventing those errors is time-consuming, yet never 100% efficient. Most people do not understand that, or at least do not realize the numbers involved. Moreover, it's when it doesn't work when one notices it. How many comments have there been on things like the inventory key actually opening the inventory? How many would there be if it didn't?

My advice, Vaeflare, is to be more open about it. I work in an IT company bigger than Blizzard, Activision or even Vivendi. I kick-started a project for a customer whose IT budget alone exceeds Activision's net income. Yet we meet with them twice a week, and give them a live demo and a build every two weeks. This move alone has helped defuse a C-level escalation down to a partner-level relationship (in that area anyway, we're already strategic partners.) Transparency goes a long way. Regardless of what progress you make, keeping your customers up to date and directly involved can only be a positive move. I have never, ever in my professional experience had that backfire against me or my employer, and I've had to deal with the biggest fish in the sea.

And no, PTR doesn't cut it, though it is a step in the right direction. Weekly updates, dev blogs, publicly visible bug tracking (for user-reported issues at least,) a public idea board... these things will make the difference. I know you guys are making progress because I have the experience to gauge what you deliver and how often vs. the number of folks I've had to kill in the Development Hell dungeon. Your average customer would see too little too rarely, and as you are very well aware, perception is reality more often than not...
Reply Quote
01/18/2013 06:13 PMPosted by Xort
The reality is, game development is a hugely iterative and time-consuming process, with many people involved along the way. Design takes time, Coding takes time, art takes time, QA takes time: you name it.


So the many years of development before release wasn't enough...?


Don't know how to learn and pick from D2 is okay... But all these years of development time and 7 months of trial and error still can't fix a broken game. Somethings clearly wrong there...
Reply Quote
01/21/2013 08:28 AMPosted by eFiniTi


So the many years of development before release wasn't enough...?


Don't know how to learn and pick from D2 is okay... But all these years of development time and 7 months of trial and error still can't fix a broken game. Somethings clearly wrong there...


Yup.

I'm pretty sure most of the developers went to some kind of school to learn how to produce games. It's their job for fuqs sake. If you can't fix things in a timely manner, you get sacked. Jay Wilson is a prime example.

Get the ball rolling or get off the damn project. Don't sit here and tell me how "hard" your job is blue.
Reply Quote
I am simply curious, why does your dev team need so much time to build up fixes for the PTR server? I was looking at list of known issues and they seem easy to fix, 1-2 days of work. Why do we have to wait like 3 months for a live update? Why can't they do theyr job in a productive and fast way? Are they like drinking coffe all day and coding when they feel in the mood? Other companies can offer updates weekly while Blizzard ninjas its way through months..Diablo 3 has real big problems that I and the rest of the community wait to be fixed, many like myself included don't play the game like we played Diablo 2 and it's ok, we understood Diablo 3 needs time but can't wait years to recieve the diablo experience I was looking for. I sure hope the new director will take real action and maybe put the team to work. All the updates so far were very good but I have the feeling they took less to build up and you guys just buy time for the expansion release. As for Jay Wilson, nice job with the combat system off hat for that, the rest I can't admit I love just because I am not into MMO and don't enjoy the simple auto made stuff. Diablo is all about freedom of the gameplay while you Jay delivered us restrictions. Anyway I aplaud your decision to offer the game to a better mind made for this type of game, I wish you good luck to your feature project (hope it's a MMO so you can make some players happy)

P.S. I think Diablo 3 was an experiment for the new game you are working on


I've been a programmer for 10+ years, and this sounds like something a junior programmer would say (or a guy who hasn't work with a project more than a few 100k lines of code.. D3 is several million lines). Let me point out a few things that you, and other junior programmers out there may not have considered in your statement:
- The blue post points out that bugs need to be reviewed, fixed and QA'd. The developer performing the fix often spends the least amount of time on it of these 3 parts.
- Reviewing is to identify bogus bugs, prioritize importance, and determine the best dev to fix the bug. Can the cheap salaried dev do it?
- QA will extensively play test the fix to make sure it is both fixed, and nothing else is harmed by the fix. In some cases, they discover bugs that the public isn't even aware of, using tools to simulate large samples of play-time.
- Finally, for the dev working on any enterprise level software, it is imperative that any changes do not cause further problems. So to fix a bug, you need to do the following, even before it is passed onto QA.
A) update source to get the most recent code on your dev PC
B) replicate the bug, often needing to create certain items or an environment where you can see it happen. This may involve making requests for more details if the basic description of the bug is not reproducable
C) identify the problem area of the code. Often this is hard to find in millions and millions of lines of text throughout 1000's of files
D) contemplate what ramifications a fix could cause. For example, if a wizard is not supposed to be in permanent-archon form after teleporting, but teleporting does a memory copy for other reasons related to teleporting, then what happens if that memory block method is no longer used? Will your change break all teleport abilities?
E) Consider alternative approaches to a fix if step D brings up too many issues
F) Consider compromises. In some cases a bug CAN be fixed, but at the cost of laggy performance, or some other negative side effect. Maybe teleporting introduces a 0.25 second cooldown before ANY spell can be cast? That might be the cheaper safer way to fix it, but you might have to buff the spell some other way to make up for it.
G) Fix the bug. This takes less than 20 minutes for any decent dev, and usually comprises less than 5% of the time spent by the dev alone.
H) Verify you have fixed the bug following the steps from B), make sure nothing bad is happening. If there is, back to step D.
I) Boundary test things that you suspect could be affected by the change. Namely, does Archon work fine by itself? Does Teleport work fine by iteself? Do builds with neither spells work fine by themselves?
J) Review and contemplate if the fix will increase CPU, memory or network resource usage, adjust if possible. This is where the university degree is needed. Envision what's happening in memory and the CPU without being fooled by what you are seeing on screen.
K) Update your source code again to include the stuff parellelly developed by your co-workers while you were working on the bug. Pray they didn't change any code that affects your changes. If they did, back to step H.
L) Check-in your changes to the code repository.
M) Prepare QA release notes with details on test conditions. If you are concerned about certain scenarios, explain them to QA.
N) Provide notes that the public may see as a high level description, sometimes it can just be listed as 'fixed' with the original bug descrtiption
O) Wait for the software to be compiled by the build machine
P) Wait for the install to be made that allows it to be deployed to QA
Q) Cross your fingers and hope it gets through QA!


Sr. Enterprise Architect here and I don't disagree with your analysis.

However, the problem is they released an incomplete and broken game (imagine if you did this to a client at your company who waited 7 years for the product). So the gaming community is looking for the next addition to the game to kill their boredom, but blizzard is playing catch up on their queue of problems that should have been completed on game day release.

I wouldn't blame the programmers or design team though; if I had to guess, it was company mismanagement that plagued the result of this game. Who knows.
Reply Quote

Please report any Code of Conduct violations, including:

Threats of violence. We take these seriously and will alert the proper authorities.

Posts containing personal information about other players. This includes physical addresses, e-mail addresses, phone numbers, and inappropriate photos and/or videos.

Harassing or discriminatory language. This will not be tolerated.

Forums Code of Conduct

Report Post # written by

Reason
Explain (256 characters max)
Submit Cancel

Reported!

[Close]