The reason for adding many changes together in a patch instead of hotfixing it all, is to make it much easier to test the changes.
Like spending 3 weeks to test a hundred changes, instead of spending 3/100 weeks testing one thing.
Blizzard surely could throw more changes in each patch though. That is just a decision not to change the game as fast as they could.
Funny thing is, a lot of players actually get annoyed when a game changes too much, "too fast", even if the changes are for the better. Humans are weird like that I guess. Blizzard has seen that over and over when they have changed things in WoW.
Actually Blizzard's employees answer to Morhaime, Pearce and Adham, maybe Pardo and Metzen. All programmers, not suits. They don't even answer to Activision or shareholders. It's part of the deal they signed.
They don't answer to Activision, but they sure as fuck answer to Vivendi.
Actually, they don't, they had complete freedom and full control with Davidson & Associates back in the days and always managed to keep that moving forward. Every deal they agreed on kept their complete control, even the business decisions. Vivendi cannot fire one soul or force them to keep the RMAH in D3. They might have agreeed to keep WoW subscription based, or to put monetization in all future games, sure, that may be part of the deal Morhaime and his friends have signed to cash in a couple of tens of millions, but nobody at Blizzard answers to anyone else outside Blizzard.
Of course Vivendi could force Blizzard to do just about anything.
Most likely Vivendi wouldnt force Blizzard in such a way though, as they would greatly risk that Morhaime and friends simply said fuck you and left. Infinity Ward-style. But they could.
It matters because you implied that testing changes altogether was somehow easier, and that only makes sense if they changes are related. Let say, changing a skill rune without taking into considerations the items and effects available.
Actually, they don't, they had complete freedom and full control with Davidson & Associates back in the days and always managed to keep that moving forward. Every deal they agreed on kept their complete control, even the business decisions. Vivendi cannot fire one soul or force them to keep the RMAH in D3. They might have agreeed to keep WoW subscription based, or to put monetization in all future games, sure, that may be part of the deal Morhaime and his friends have signed to cash in a couple of tens of millions, but nobody at Blizzard answers to anyone else outside Blizzard.
You're arguing a tangential point.
Given that Vivendi is a conglomerate it's likely that they don't meddle too much in ANY of their subsidaries so long as they're making them lots of money. So... as long as Blizzard is making lots of money it's safe to say Vivendi is probably busy worrying about other things. But that's still an obligation Blizzard has to answer to. Vivendi is a MAJOR investor in Blizzard and there's simply no way to get around that no matter how much dancing you do.
I'm not saying Vivendi is calling up Blizzard and saying "put a RMAH in this game" or "don't put an AH in that game." That level of meddling is almost entirely unlikely. But that doesn't mean Blizzard doesn't have some kind of responsibility (financial) to Vivendi and that Blizzard isn't well aware of that responsibility. They do have a financial responsibility to Vivendy and they are patently aware of it. There's just no way around that.
It matters because you implied that testing changes altogether was somehow easier, and that only makes sense if they changes are related. Let say, changing a skill rune without taking into considerations the items and effects available.
The fact that they publically test things makes them related. It's a lot easier to batch up changes for the PTR.
D3 is not a game you "finish" therefore people would PREFER to play the live game than the PTR. It stands to reason that their pool of people who will DL the PTR and do any significant amount of testing is limited. Putting up a new PTR on a weekly basis for small features is one way to dillute that pool even more. Very few people are going to download the PTR just to test out ID All or Craft All. But if you lump those in with Monster Density, a bunch of skill changes, and some multiplayer changes, suddenly people will download it to try out a bunch of new features.
The smaller the pool of players the less-effective the PTR is, so Blizzard naturally wants to do things that will encourage more people to invest some time in playing it to report bugs or even give feedback on where the changes fall short. The more people the less chance that random bugs associated with code changes actually make it live. I think I said it in another thread, but what if implementing ID All, for some reason, introduced a bug where Azmodan became un-killable.
Their internal testing is very much unlikely to pick up on that because they're probably NOT going to go kill Azmodan. But a PTR will almost certainly pick up on that because, if you get 100,000 people on the PTR, there's a decent chance that one of them eventually goes to kill Azmodan and says "WTF M8 HE DON'T DIE!" and then they fix it before it goes live.
It's easier for internal testing to make sure each individual feature works but it's more efficient and effective for the PTR to have a lot of changes lumped into one patch. If they had a PTR every week most people would just stop hopping on to test things out. But if they only have a PTR once every 3 months... well... just look at how many people actually use the PTR right now. It makes perfect sense. If they weren't bundling lots of features (big and small) into one patch the effectiveness of the PTR would be drastically reduced and we'd see many more bugs finding their way live and then they'd have to spend more time with hotfixes and such and it just spirals out of control.
It matters because you implied that testing changes altogether was somehow easier, and that only makes sense if they changes are related. Let say, changing a skill rune without taking into considerations the items and effects available.
No, it doesn't matter if they are related. Often, things can also affect each other even though they shouldn't be related.
Having three weeks to test 2 unrelated things is better* than having two times 1½ week to test two things separately.
Up to some point where you have too many changes tested at once anyway, which can certainly happen too (the reason why in betas for example, nthe stuff the developer wants tested, is usually added in phases).
*Better for Blizzard that is, it's somewhat more arguable if it is better for us.
Very few people are going to download the PTR just to test out ID All or Craft All. But if you lump those in with Monster Density, a bunch of skill changes, and some multiplayer changes, suddenly people will download it to try out a bunch of new features.
A similar system is implemented in the game Heroes of Newerth, some ppl has the privilege to test things before the patch hits, there is a secondary server always running that allows selected players to see what's going to be deployed before it's too late.
A similar system could be implemented here, you introduce minor changes every week, and players are somehow beta-invited to test these changes and provide feedback.
So, instead of having a "huge" PTR every 3 months, you have running all the time, with a limit of concurrent users, with all of the latests patches and features deployed there.
The smaller the pool of players the less-effective the PTR is, so Blizzard naturally wants to do things that will encourage more people to invest some time in playing it to report bugs or even give feedback on where the changes fall short. The more people the less chance that random bugs associated with code changes actually make it live. I think I said it in another thread, but what if implementing ID All, for some reason, introduced a bug where Azmodan became un-killable.
Their internal testing is very much unlikely to pick up on that because they're probably NOT going to go kill Azmodan. But a PTR will almost certainly pick up on that because, if you get 100,000 people on the PTR, there's a decent chance that one of them eventually goes to kill Azmodan and says "WTF M8 HE DON'T DIE!" and then they fix it before it goes live.
You are right in that it's impossible to test everyting, but I would place bets on Blizzard having a guy do what we call over here a "golden path" playthrough on every build. That's where they just rabbit through the game not doing any side stuff to make sure that the game is still completeable.
You are referring to a smoke test.. And the REAL industry term is HAPPY PATH.
Anyways... a good QA team will do risk based testing, partial regression and full added funtionality testing. Blizz obviously does automated regression for UI elements, and manual testing on anything random.
It's not a trolling title, I can't understand how these minors (yes, minors) changes are taking so damn long.
Are you (or do you know) a professional programmer? If yes, do you (does he) know the Diablo 3 coding inside out to be able to understand how much work it takes to "tweak" those minor changes? Are you (or do you know) a professional game developer in a huge company with high quality standards? If yes, how many meetings does it take to make decisions on skill balance changes? And how many people have to be working on that? What's the ideal development time for these changes?
How many people do you think are working on patch 1.0.8? Everyone from the D3 developer team? How many are working on an expansion already (and trying to solve some of the big "problems" that people have with the game as well as coming up with new, interesting content)? How many are instead working on the itemization patch, or legendaries?
Not a trolling reply - legit questions.
Yes, I'm actually a software engineer, and if they did their work properly, they should have a nicely done map/mob editor showing every single piece of data they could ever need to make their balances now and in 10 years from now.
My guess is, they rushed the game in a way that not only the game was flawed, but the codebase too, and now they need to refactor a lot and build tools that don't even exist, like a map & mob editor.
This is one of the most ignorant statements I've heard about software development. I'd love to follow you around your job and when someone asks you for an update that is perceived to be "easy" and you say it's not that easy I'm going to tell you that you suck at your job.
Oh, good sir, explain me why is my opinion about the subject ignorant, enlight me with all your knowledge about AAA games.
If you really need for me to sit down and explain why saying they should code for aspects of the game now and ten years from now is absolutely ignorant then there is zero hope for you and going into details isn't going to accomplish much.
*actually, can a guess be wrong?
My guess is you aren't actually a software developer and you're just trolling on the forums for attention. Am I wrong?
You are referring to a smoke test.. And the REAL industry term is HAPPY PATH.
Anyways... a good QA team will do risk based testing, partial regression and full added funtionality testing. Blizz obviously does automated regression for UI elements, and manual testing on anything random.
Hmm for us a smoke test is touching everything but not deep whereas a golden (or happy if thats what you want) path is making sure that someone could complete the game but not necissarily do everything.
It's not a trolling title, I can't understand how these minors (yes, minors) changes are taking so damn long.
Are you (or do you know) a professional programmer? If yes, do you (does he) know the Diablo 3 coding inside out to be able to understand how much work it takes to "tweak" those minor changes? Are you (or do you know) a professional game developer in a huge company with high quality standards? If yes, how many meetings does it take to make decisions on skill balance changes? And how many people have to be working on that? What's the ideal development time for these changes?
How many people do you think are working on patch 1.0.8? Everyone from the D3 developer team? How many are working on an expansion already (and trying to solve some of the big "problems" that people have with the game as well as coming up with new, interesting content)? How many are instead working on the itemization patch, or legendaries?
Not a trolling reply - legit questions.
Yes, I'm actually a software engineer, and if they did their work properly, they should have a nicely done map/mob editor showing every single piece of data they could ever need to make their balances now and in 10 years from now.
My guess is, they rushed the game in a way that not only the game was flawed, but the codebase too, and now they need to refactor a lot and build tools that don't even exist, like a map & mob editor.
This is one of the most ignorant statements I've heard about software development. I'd love to follow you around your job and when someone asks you for an update that is perceived to be "easy" and you say it's not that easy I'm going to tell you that you suck at your job.
Oh, good sir, explain me why is my opinion about the subject ignorant, enlight me with all your knowledge about AAA games.
If you really need for me to sit down and explain why saying they should code for aspects of the game now and ten years from now is absolutely ignorant then there is zero hope for you and going into details isn't going to accomplish much.
*actually, can a guess be wrong?
My guess is you aren't actually a software developer and you're just trolling on the forums for attention. Am I wrong?
Deflect more, it makes you look like what you are.
Deflect more, it makes you look like what you are.
It's not defection at all. Anyone with any modicum of sense can read between the lines and understand what I am saying. Truthfully your posts seems more like hallow attempts at flame baiting rather than substantive talking points about the topic.
The posts I have seen so far reek more of someone making their way through college as a software developer and gone through an internship or two but hasn't fully been introduced to the development life cycle first hand to experience all the inefficiencies involved in the process. The only thing I see is someone spouting off college level ideals about Utopian coding situations where all your code sits perfectly in frameworks, perfectly adhering to standards, no zero spaghetti code, perfectly optimized and no inefficiencies.
There are a million reasons as to why I can think of as to why it is perfectly fine that the patch would be taking this long, but I can't sit back and think of any reason to say why a patch should be done in X amount of time without being able to look under the hood at many variables.
Saying someone should be developing every piece of code now that they would need for the next ten years is beyond ignorant. There is no human on the planet that would be able to sit back and predict where a project is going to go due to bosses changing their minds on the direction of projects, clients changing their minds with what they want every time they see the project.
What saddens me is that this thread seems to have a lot of people assuming there is one "golden" or true way to code and it is the only way. Even worse that people think testing means just making sure the game plays and is beatable. There's so much more, a tester's job is to break stuff, not just do the "standard" stuff. You go out, you try something unorthodox in order to get it to break. If they just played the game normally they could miss many bugs.
Let's also look at why PTRs exist and why there is so much testing. What happens if you have a pool of 100 testers and the game breaks for just one of them? By some of the posts I've seen here, many of you would say that's fine. Okay, now let's take that number up to live and assume 1 million are playing now. That is a multiplaction of x10,000. That means that now 10,000 people can't play because something was broken. It's a small percentage, sure, but when you apply a real number to it, you can see why they wouldn't want to let that happen.
Sometimes bugs don't occur untill after several attempts or sometimes they occur once and never again. It's the nature of the beast for them to be cautious, especially when ANY minor change to a program this huge could somehow break something else. And make no mistake, this is no small change. Monster spawn locations have to be added and then you have to make sure they work like they're supposed to especially with the randomization system. This isn't like some Tabletop RPG when you can just say "oh I'll throw in another orc here".
There's so many assumptions going on here and bickering that I almost didn't even want to say anything, but so many people who have never even tried programming make too many assumptions and I feel like the misinformation has to stop. Even more troubling is a self proclaimed programmer coming in and saying it's no big deal. I don't even fathom that one, maybe you're lucky and you happen to have a really good team that has software that's exceptionally portable and modular, but don't assume everything that you do in your code is easily carried over to a game engine. We don't know how it's programmed, how easy or hard it is.
I'm more inclined to believe the gentleman who came in and talked about meetings on top of meetings.. coding changes and revisions taking forever due to QA and testing and even more revisions and meetings, etc onto oblivion. Why do I believe that? Because buracracy. Blizzard isn't an agile team. They do their best to make sure all their changes work and even that isn't always enough. They're always talking about what they want to do and how they tackle problems. Just look at all the ideas they throw out that never make it. They've probably thrown out more ideas than many of us could think of.
Make no mistake, this by no means should indicate that I believe Blizzard has all the right answers. They've proven that to be false many times. But I really hate to see people call their development team lazy because they feel patches aren't comming out fast enough. Considering how much they have to go through to get a patch approved for release, we've actually seen a lot of changes and updates over the course of the last year.
^ thanks for saving me some time writing that, KK.
The answer to the thread title is "no". There you have it. Simple as that.
After dozens of comments by others explaining in detail why things are the way they are, and mostly provocative replies to these I think we all had enough. Indeed doesn't really look like a discussion (at least not for a couple pages), and has strong characteristics of textbook trolling.
Closed
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
The reason for adding many changes together in a patch instead of hotfixing it all, is to make it much easier to test the changes.
Like spending 3 weeks to test a hundred changes, instead of spending 3/100 weeks testing one thing.
Blizzard surely could throw more changes in each patch though. That is just a decision not to change the game as fast as they could.
Funny thing is, a lot of players actually get annoyed when a game changes too much, "too fast", even if the changes are for the better. Humans are weird like that I guess. Blizzard has seen that over and over when they have changed things in WoW.
Actually, they don't, they had complete freedom and full control with Davidson & Associates back in the days and always managed to keep that moving forward. Every deal they agreed on kept their complete control, even the business decisions. Vivendi cannot fire one soul or force them to keep the RMAH in D3. They might have agreeed to keep WoW subscription based, or to put monetization in all future games, sure, that may be part of the deal Morhaime and his friends have signed to cash in a couple of tens of millions, but nobody at Blizzard answers to anyone else outside Blizzard.
Most likely Vivendi wouldnt force Blizzard in such a way though, as they would greatly risk that Morhaime and friends simply said fuck you and left. Infinity Ward-style. But they could.
It is not? Not sure why it matters.
You're arguing a tangential point.
Given that Vivendi is a conglomerate it's likely that they don't meddle too much in ANY of their subsidaries so long as they're making them lots of money. So... as long as Blizzard is making lots of money it's safe to say Vivendi is probably busy worrying about other things. But that's still an obligation Blizzard has to answer to. Vivendi is a MAJOR investor in Blizzard and there's simply no way to get around that no matter how much dancing you do.
I'm not saying Vivendi is calling up Blizzard and saying "put a RMAH in this game" or "don't put an AH in that game." That level of meddling is almost entirely unlikely. But that doesn't mean Blizzard doesn't have some kind of responsibility (financial) to Vivendi and that Blizzard isn't well aware of that responsibility. They do have a financial responsibility to Vivendy and they are patently aware of it. There's just no way around that.
The fact that they publically test things makes them related. It's a lot easier to batch up changes for the PTR.
D3 is not a game you "finish" therefore people would PREFER to play the live game than the PTR. It stands to reason that their pool of people who will DL the PTR and do any significant amount of testing is limited. Putting up a new PTR on a weekly basis for small features is one way to dillute that pool even more. Very few people are going to download the PTR just to test out ID All or Craft All. But if you lump those in with Monster Density, a bunch of skill changes, and some multiplayer changes, suddenly people will download it to try out a bunch of new features.
The smaller the pool of players the less-effective the PTR is, so Blizzard naturally wants to do things that will encourage more people to invest some time in playing it to report bugs or even give feedback on where the changes fall short. The more people the less chance that random bugs associated with code changes actually make it live. I think I said it in another thread, but what if implementing ID All, for some reason, introduced a bug where Azmodan became un-killable.
Their internal testing is very much unlikely to pick up on that because they're probably NOT going to go kill Azmodan. But a PTR will almost certainly pick up on that because, if you get 100,000 people on the PTR, there's a decent chance that one of them eventually goes to kill Azmodan and says "WTF M8 HE DON'T DIE!" and then they fix it before it goes live.
It's easier for internal testing to make sure each individual feature works but it's more efficient and effective for the PTR to have a lot of changes lumped into one patch. If they had a PTR every week most people would just stop hopping on to test things out. But if they only have a PTR once every 3 months... well... just look at how many people actually use the PTR right now. It makes perfect sense. If they weren't bundling lots of features (big and small) into one patch the effectiveness of the PTR would be drastically reduced and we'd see many more bugs finding their way live and then they'd have to spend more time with hotfixes and such and it just spirals out of control.
Having three weeks to test 2 unrelated things is better* than having two times 1½ week to test two things separately.
Up to some point where you have too many changes tested at once anyway, which can certainly happen too (the reason why in betas for example, nthe stuff the developer wants tested, is usually added in phases).
*Better for Blizzard that is, it's somewhat more arguable if it is better for us.
Yeah, very good point.
A similar system could be implemented here, you introduce minor changes every week, and players are somehow beta-invited to test these changes and provide feedback.
So, instead of having a "huge" PTR every 3 months, you have running all the time, with a limit of concurrent users, with all of the latests patches and features deployed there.
Anyways... a good QA team will do risk based testing, partial regression and full added funtionality testing. Blizz obviously does automated regression for UI elements, and manual testing on anything random.
If you really need for me to sit down and explain why saying they should code for aspects of the game now and ten years from now is absolutely ignorant then there is zero hope for you and going into details isn't going to accomplish much.
My guess is you aren't actually a software developer and you're just trolling on the forums for attention. Am I wrong?
Deflect more, it makes you look like what you are.
At least I got a quote for my signature out of this stupid thread.
It's not defection at all. Anyone with any modicum of sense can read between the lines and understand what I am saying. Truthfully your posts seems more like hallow attempts at flame baiting rather than substantive talking points about the topic.
The posts I have seen so far reek more of someone making their way through college as a software developer and gone through an internship or two but hasn't fully been introduced to the development life cycle first hand to experience all the inefficiencies involved in the process. The only thing I see is someone spouting off college level ideals about Utopian coding situations where all your code sits perfectly in frameworks, perfectly adhering to standards, no zero spaghetti code, perfectly optimized and no inefficiencies.
There are a million reasons as to why I can think of as to why it is perfectly fine that the patch would be taking this long, but I can't sit back and think of any reason to say why a patch should be done in X amount of time without being able to look under the hood at many variables.
Saying someone should be developing every piece of code now that they would need for the next ten years is beyond ignorant. There is no human on the planet that would be able to sit back and predict where a project is going to go due to bosses changing their minds on the direction of projects, clients changing their minds with what they want every time they see the project.
Let's also look at why PTRs exist and why there is so much testing. What happens if you have a pool of 100 testers and the game breaks for just one of them? By some of the posts I've seen here, many of you would say that's fine. Okay, now let's take that number up to live and assume 1 million are playing now. That is a multiplaction of x10,000. That means that now 10,000 people can't play because something was broken. It's a small percentage, sure, but when you apply a real number to it, you can see why they wouldn't want to let that happen.
Sometimes bugs don't occur untill after several attempts or sometimes they occur once and never again. It's the nature of the beast for them to be cautious, especially when ANY minor change to a program this huge could somehow break something else. And make no mistake, this is no small change. Monster spawn locations have to be added and then you have to make sure they work like they're supposed to especially with the randomization system. This isn't like some Tabletop RPG when you can just say "oh I'll throw in another orc here".
There's so many assumptions going on here and bickering that I almost didn't even want to say anything, but so many people who have never even tried programming make too many assumptions and I feel like the misinformation has to stop. Even more troubling is a self proclaimed programmer coming in and saying it's no big deal. I don't even fathom that one, maybe you're lucky and you happen to have a really good team that has software that's exceptionally portable and modular, but don't assume everything that you do in your code is easily carried over to a game engine. We don't know how it's programmed, how easy or hard it is.
I'm more inclined to believe the gentleman who came in and talked about meetings on top of meetings.. coding changes and revisions taking forever due to QA and testing and even more revisions and meetings, etc onto oblivion. Why do I believe that? Because buracracy. Blizzard isn't an agile team. They do their best to make sure all their changes work and even that isn't always enough. They're always talking about what they want to do and how they tackle problems. Just look at all the ideas they throw out that never make it. They've probably thrown out more ideas than many of us could think of.
Make no mistake, this by no means should indicate that I believe Blizzard has all the right answers. They've proven that to be false many times. But I really hate to see people call their development team lazy because they feel patches aren't comming out fast enough. Considering how much they have to go through to get a patch approved for release, we've actually seen a lot of changes and updates over the course of the last year.
Okay, rant over.. carry on.
The answer to the thread title is "no". There you have it. Simple as that.
After dozens of comments by others explaining in detail why things are the way they are, and mostly provocative replies to these I think we all had enough. Indeed doesn't really look like a discussion (at least not for a couple pages), and has strong characteristics of textbook trolling.
Closed