Why do bugs persist after being fixed?

GuntherBlobel

So, I updated to R59, but I just witnessed two bugs from R58 in a one-time-only goodbye round.

My first round of Shield Simulator had base power damage from all enemies. Then, Black Panther made 6 yellow tiles instead of 3 when 12 TU AP were available.

I tried to replicate both, but both were acting as they should by the next round. Why does this happen?

Edit: oops, I said I was on R60 when I should have said R59.

OnesOwnGrief

What are you playing on? Android has yet to receive the update.

GuntherBlobel

OnesOwnGrief wrote:

What are you playing on? Android has yet to receive the update.

Sorry, I wrote the wrong version. I'm on R59 like everyone else (iOS).

OnesOwnGrief

Yeah, the BP thing still happens at exactly 12 TU AP as far as I know. It was never fixed.

GuntherBlobel

OnesOwnGrief wrote:

Yeah, the BP thing still happens at exactly 12 TU AP as far as I know. It was never fixed.

It was never fixed? Weird. It's not very reproducible then. I've only had it happen once.

FaerieMyst

Ooo, oooo, I can answer this.

My husband is a software developer and, because he loves me, has created custom software for my company. So I found this bug . . . nothing fatal, just annoying. I tell him and he tells me he fixed it. He tests it with his copy of the program and data base and it works like it is supposed to. So next day I use that function and the bug is still there. We go back and forth. Finally this past weekend, I sit with him and he went step by step how he tested it. Sure enough, it works. Here's the thing, when I do that, I do one little thing different. So now he tests it with that change, There's the bug. It's really fixed now but there was much swearing on both sides in the meantime.

I don't know the actual issue in these cases but I know that my developer genuinely wants me to have the best software he can deliver - but sometimes **** happens.

Unknown

Your first battle in Shield SIM had base damage because you had already generated those nodes pre-bug fix. So all your starting nodes will have base damage if you opened up Shield SIM before the bug fix patch but did not actually play any of them.

GuntherBlobel

gobstopper wrote:

Your first battle in Shield SIM had base damage because you had already generated those nodes pre-bug fix. So all your starting nodes will have base damage if you opened up Shield SIM before the bug fix patch but did not actually play any of them.

Ah! That's the answer. As for BP's 6 strike tiles, there may be some very particular condition that I did once that I can't figure out how to replicate.

Taganov

I just got daredevil kicked to the face after knocking him out. He'd been down at least 2 additional cascades when it happened. I didn't know his traps could activate after death. Don't they dispel when he hits the floor, not when the cascade ends?

esoxnepa

Sometimes software bugs are very hard to duplicate, and far more serious.

http://en.wikipedia.org/wiki/Therac-25

The accidents occurred when the high-power electron beam was activated instead of the intended low power beam, and without the beam spreader plate rotated into place. Previous models had hardware interlocks in place to prevent this, but Therac-25 had removed them, depending instead on software interlocks for safety. The software interlock could fail due to a race condition. The defect was as follows: a one-byte counter in a testing routine frequently overflowed; if an operator provided manual input to the machine at the precise moment that this counter overflowed, the interlock would fail.

over_clocked

Taganov wrote:

I just got daredevil kicked to the face after knocking him out. He'd been down at least 2 additional cascades when it happened. I didn't know his traps could activate after death. Don't they dispel when he hits the floor, not when the cascade ends?

If Daredevil was killed in one long string of cascades, his traps were not disarmed immedaitely and it's intended. If he died, sides made turns and traps still survived, then that's a bug.

Unknown

FaerieMyst wrote:

My husband is a software developer and, because he loves me, has created custom software for my company. So I found this bug . . . nothing fatal, just annoying. I tell him and he tells me he fixed it. He tests it with his copy of the program and data base and it works like it is supposed to. So next day I use that function and the bug is still there. We go back and forth. Finally this past weekend, I sit with him and he went step by step how he tested it. Sure enough, it works. Here's the thing, when I do that, I do one little thing different. So now he tests it with that change, There's the bug. It's really fixed now but there was much swearing on both sides in the meantime.

I don't know the actual issue in these cases but I know that my developer genuinely wants me to have the best software he can deliver - but sometimes tinykitty happens.

There is however a difference between homebrew custom software and a commercial release. When your testing is limited to one person working on his own time, it's understandable that certain little things may slip through the cracks. When you presumably have a testing department being paid to make sure these things don't make it into the version released to the customers it's far less understandable and excusable to have these kinds of bugs. The problem is they've shown over and over that they either aren't very good at testing or they just don't really give a damn. Look at how TUs were rolled out, and that was hardly an isolated incident.

GothicKratos

Thugpatrol wrote:

FaerieMyst wrote:

My husband is a software developer and, because he loves me, has created custom software for my company. So I found this bug . . . nothing fatal, just annoying. I tell him and he tells me he fixed it. He tests it with his copy of the program and data base and it works like it is supposed to. So next day I use that function and the bug is still there. We go back and forth. Finally this past weekend, I sit with him and he went step by step how he tested it. Sure enough, it works. Here's the thing, when I do that, I do one little thing different. So now he tests it with that change, There's the bug. It's really fixed now but there was much swearing on both sides in the meantime.

I don't know the actual issue in these cases but I know that my developer genuinely wants me to have the best software he can deliver - but sometimes tinykitty happens.

There is however a difference between homebrew custom software and a commercial release. When your testing is limited to one person working on his own time, it's understandable that certain little things may slip through the cracks. When you presumably have a testing department being paid to make sure these things don't make it into the version released to the customers it's far less understandable and excusable to have these kinds of bugs. The problem is they've shown over and over that they either aren't very good at testing or they just don't really give a damn. Look at how TUs were rolled out, and that was hardly an isolated incident.

That's a pretty big assumption for a small studio.

Unknown

GothicKratos wrote:

Thugpatrol wrote:

There is however a difference between homebrew custom software and a commercial release. When your testing is limited to one person working on his own time, it's understandable that certain little things may slip through the cracks. When you presumably have a testing department being paid to make sure these things don't make it into the version released to the customers it's far less understandable and excusable to have these kinds of bugs. The problem is they've shown over and over that they either aren't very good at testing or they just don't really give a damn. Look at how TUs were rolled out, and that was hardly an isolated incident.

That's a pretty big assumption for a small studio.

Which part is too big an assumption? That they have a testing department? Including the lead, they have 10 people listed as "Quality Assurance" in the credits. Regardless, being a small studio isn't a built in excuse. Part of doing business is managing resources. Whatever testing process they have is woefully insufficient. Either they're understaffed, underqualified, or not given the time and resources necessary to do their job properly. They have demonstrated a fairly severe deficit in this area on more than one occasion, and they don't get a pass because of the chosen size of their labor force.

GothicKratos

Thugpatrol wrote:

GothicKratos wrote:

Thugpatrol wrote:

There is however a difference between homebrew custom software and a commercial release. When your testing is limited to one person working on his own time, it's understandable that certain little things may slip through the cracks. When you presumably have a testing department being paid to make sure these things don't make it into the version released to the customers it's far less understandable and excusable to have these kinds of bugs. The problem is they've shown over and over that they either aren't very good at testing or they just don't really give a damn. Look at how TUs were rolled out, and that was hardly an isolated incident.

That's a pretty big assumption for a small studio.

Which part is too big an assumption? That they have a testing department? Including the lead, they have 10 people listed as "Quality Assurance" in the credits. Regardless, being a small studio isn't a built in excuse. Part of doing business is managing resources. Whatever testing process they have is woefully insufficient. Either they're understaffed, underqualified, or not given the time and resources necessary to do their job properly. They have demonstrated a fairly severe deficit in this area on more than one occasion, and they don't get a pass because of the chosen size of their labor force.

All of the above? Assuming, even if they have ten "Quality Assurance", that all of them are working on Marvel Puzzle Quest is a bit naive. Studios typically divide their team up for different projects. Perhaps they aren't properly staffed for the project, but is that reason to give them flack? Not in my opinion, if anything we should be thankful they just didn't go belly up when things got over their heads. We should be thankfully they're working their **** off, even if it's not perfect. Even further so if it's a manner of not having access to the proper materials do "properly" do their job. It's easy to assume they're just lazy pricks, but I have a funny feeling that's not the case.

As a sidenote, I am curious as to where you saw a full listing of their staff. I went looking for something of that nature a few weeks ago and didn't find anything significant.

Unknown

GothicKratos wrote:

Thugpatrol wrote:

Which part is too big an assumption? That they have a testing department? Including the lead, they have 10 people listed as "Quality Assurance" in the credits. Regardless, being a small studio isn't a built in excuse. Part of doing business is managing resources. Whatever testing process they have is woefully insufficient. Either they're understaffed, underqualified, or not given the time and resources necessary to do their job properly. They have demonstrated a fairly severe deficit in this area on more than one occasion, and they don't get a pass because of the chosen size of their labor force.

All of the above? Assuming, even if they have ten "Quality Assurance", that all of them are working on Marvel Puzzle Quest is a bit naive. Studios typically divide their team up for different projects. Perhaps they aren't properly staffed for the project, but is that reason to give them flack? Not in my opinion, if anything we should be thankful they just didn't go belly up when things got over their heads. We should be thankfully they're working their **** off, even if it's not perfect. Even further so if it's a manner of not having access to the proper materials do "properly" do their job. It's easy to assume they're just lazy pricks, but I have a funny feeling that's not the case.

How they're staffed and how that staff is allocated is none of my concern except in how it impacts the product they release. I never accused them of being lazy, rather that either they're doing a poor job of testing or they don't care, possibly both. In what universe does it matter how a business providing a product and a service is staffed if the result is bad? If you get an under-cooked meal at a restaurant that makes you sick is it immediately okay because they only have one chef and gosh darn it he's just trying really hard.

I don't know what goes on in their offices. I only know what's presented as an end result, and lately that result has been rife with glitches and poorly implemented features. You want to be thankful for that, go ahead. I'll continue to be critical of them for it until it improves. This isn't personal. I don't hate them or curse their names. I like their game, but there are quite a few things I would like to see improved, and from what they've shown their testing is far from ideal.

GothicKratos wrote:

As a sidenote, I am curious as to where you saw a full listing of their staff. I went looking for something of that nature a few weeks ago and didn't find anything significant.

There's a button on the splash screen for "Credits", at least on the Steam version.

GothicKratos

Thugpatrol wrote:

GothicKratos wrote:

Thugpatrol wrote:

Which part is too big an assumption? That they have a testing department? Including the lead, they have 10 people listed as "Quality Assurance" in the credits. Regardless, being a small studio isn't a built in excuse. Part of doing business is managing resources. Whatever testing process they have is woefully insufficient. Either they're understaffed, underqualified, or not given the time and resources necessary to do their job properly. They have demonstrated a fairly severe deficit in this area on more than one occasion, and they don't get a pass because of the chosen size of their labor force.

All of the above? Assuming, even if they have ten "Quality Assurance", that all of them are working on Marvel Puzzle Quest is a bit naive. Studios typically divide their team up for different projects. Perhaps they aren't properly staffed for the project, but is that reason to give them flack? Not in my opinion, if anything we should be thankful they just didn't go belly up when things got over their heads. We should be thankfully they're working their **** off, even if it's not perfect. Even further so if it's a manner of not having access to the proper materials do "properly" do their job. It's easy to assume they're just lazy pricks, but I have a funny feeling that's not the case.

How they're staffed and how that staff is allocated is none of my concern except in how it impacts the product they release. I never accused them of being lazy, rather that either they're doing a poor job of testing or they don't care, possibly both. In what universe does it matter how a business providing a product and a service is staffed if the result is bad? If you get an under-cooked meal at a restaurant that makes you sick is it immediately okay because they only have one chef and gosh darn it he's just trying really hard.

But you can give those breaks to "homebrew" software? Sorry if I don't consider a 30-some-odd person studio "commercial" enough to be hypercritcal. Sure, it's no 5-man team, but it's certainly not Naughty Dog or Wolf Team/Namco Tales Studio - let alone Ubisoft or Square.

Unknown

Just because a problem may be obvious doesn't mean the fix is obvious. Even very big games have well-known bugs that are not fixed for a long time. Now if we're talking about why balance issues take so long to fix even when it's rather blatant, I've noticed this tends to be a matter of philosophy, or better known as 'L2P'. That is, I see plenty of games where you can kill someone by pushing one button but when you bring it up to a dev they'd think that just means you suck at the game. I remember playing HOMM4's campaigns on the 'impossible' setting and 3 out of 5 are effectively unbeatable, and one of them you literally start the game and die on first turn without any chance of survival, but I'm pretty sure I was told I need to get better at the game to beat a campaign where you die as soon as you start the game.

Unknown

Phantron wrote:

Just because a problem may be obvious doesn't mean the fix is obvious. Even very big games have well-known bugs that are not fixed for a long time. Now if we're talking about why balance issues take so long to fix even when it's rather blatant, I've noticed this tends to be a matter of philosophy, or better known as 'L2P'. That is, I see plenty of games where you can kill someone by pushing one button but when you bring it up to a dev they'd think that just means you suck at the game. I remember playing HOMM4's campaigns on the 'impossible' setting and 3 out of 5 are effectively unbeatable, and one of them you literally start the game and die on first turn without any chance of survival, but I'm pretty sure I was told I need to get better at the game to beat a campaign where you die as soon as you start the game.

But the question is......did you get better?

Unknown

Paintsville wrote:

Phantron wrote:

Just because a problem may be obvious doesn't mean the fix is obvious. Even very big games have well-known bugs that are not fixed for a long time. Now if we're talking about why balance issues take so long to fix even when it's rather blatant, I've noticed this tends to be a matter of philosophy, or better known as 'L2P'. That is, I see plenty of games where you can kill someone by pushing one button but when you bring it up to a dev they'd think that just means you suck at the game. I remember playing HOMM4's campaigns on the 'impossible' setting and 3 out of 5 are effectively unbeatable, and one of them you literally start the game and die on first turn without any chance of survival, but I'm pretty sure I was told I need to get better at the game to beat a campaign where you die as soon as you start the game.

But the question is......did you get better?

I eventually learned to put in some cheat codes!

Unknown

GothicKratos wrote:

But you can give those breaks to "homebrew" software? Sorry if I don't consider a 30-some-odd person studio "commercial" enough to be hypercritcal. Sure, it's no 5-man team, but it's certainly not Naughty Dog or Wolf Team/Namco Tales Studio - let alone Ubisoft or Square.

Yes, I'm prepared to make a distinction between custom software created by a lone designer for his wife in his spare time, which was the original example I responded to, and a small professional studio producing commercial releases for paying customers. If you want to give them a pass because they're not an industry giant and you believe them to be trying super hard, go right ahead. I'm unlikely to do the same. They're big enough to not release updates that set enemies' abilities to base value without someone noticing, for example. That these kinds of blatant errors repeatedly slip through to release is an indication that something is very wrong with their testing process, and it's not a good look when you're trying to get people to give you money.