OnesOwnGrief wrote: What are you playing on? Android has yet to receive the update.
OnesOwnGrief wrote: Yeah, the BP thing still happens at exactly 12 TU AP as far as I know. It was never fixed.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.