105 réponses à ce sujet

[Link Ashland 614]

I was once got killed 4 times in a row with the Reaper on Rannoch: Just before the last last signal (the slow-m one) the laser didn't fire. Who knows why.

Yet I don't want anyone fired.

[redbaron76]

OP Get over your self. They probably have missed a few bugs. So what if you play over, you do not have to rave and rant like five year old. Play the game or stop playing. Game testers are only human and will always miss a few bugs so give them a break and grow up.

[Tishiro88]

Acid Mars wrote...

So I'm trying to work my way through insanity.

guess what?

half way through one of the later levels I get stopped at an elevator, because I guess one of the geth got pushed off of the catwalk.

I can't kill him.. and I can't open the elevator.

so now I must start at the beginning of the level, which pissed me off to no end.

FIRE YOUR GAME TESTERS!!!

IF THEY MISSED THIS...GOD KNOWS WHAT ELSE THEY MISSED!!!!!

You think that is bad try havering the game freeze when you right before the beam on earth on Iinsanity. 

[crypticcat 2o2p]

Lemme see here:
Getting stuck talking to Edi or Joker.
Having to reload the game to turn in the fed-ex quests.
Having to reload the game to be able to use doors. (Funny thing that in critical areas doors are suddenly automatic... Hmmmmm)
Monsters getting stuck become unkillable. Morinth Shields is a good example.
But F5 is my friend... clear a section, hit F5. The problem I have with that is that I'm not using F5 because I just did awesome or hard, I use F5 because ME3 can at any moment stop doing what it is supposed to do, characters not vocalizing their entire lines not included.
I believe that a quick save is to safeguard your progress IN the game, not to safeguard your progress FROM the game. For a studio like Bioware, it is just not good enough. They are not some unknown indie with a fluke-title sleeper hit, they are a high-profile triple A studio.
More is expected.

[Selene Moonsong]

Raizo wrote...

My favourite bug is the first time you talk to Liara on the Normandy. I can't speak for everyone but my Shepard always turns his head 90 degrees to the right and it stays that way for the full duration of the whole entire conversation ( I think he/she is watching Glyph fly around the room and his/her head gets stuck in that position ). What's even funnier is that during that same conversation Liara turns her head 9T0 degrees to the left it stays that way during the whole conversation. This happens to me on the both the PS3 and 360 versions of the game. Now as far as bugs go this is very minor since it does not break the game in any way and yet it annoys me every time I see it since I can't imagine how anyone could have missed this since I have played through that scene on at least 4 different occasions and it happens every time without fail, surely I'm not the only one to experience this. How did the bug testers miss this or do they not give a damn.

This happens if you ask about Glyph. If you don't ask about glyph, the worst you get is the simple issue with Shepard turning to look towards glyph.

This is an issue with the VI having the focus instead of releasing the focus of attention back to Shep/Liara during their conversation. So, if you choose it as the first part of the conversation, they will otherwise attempt to look at Glyph instead of each other. This should be a relatively easy fix, which I hope BioWare will fix, but only because it is mildly annoying, rather than a game breaker. If you played the  ME 2 Shadow Broker DC, your really don't nee to even start that part of the conversation, or at least should save it until the last question so that it isn't as annoying.

[Battlepope190]

Selene Moonsong wrote...

Raizo wrote...

My favourite bug is the first time you talk to Liara on the Normandy. I can't speak for everyone but my Shepard always turns his head 90 degrees to the right and it stays that way for the full duration of the whole entire conversation ( I think he/she is watching Glyph fly around the room and his/her head gets stuck in that position ). What's even funnier is that during that same conversation Liara turns her head 9T0 degrees to the left it stays that way during the whole conversation. This happens to me on the both the PS3 and 360 versions of the game. Now as far as bugs go this is very minor since it does not break the game in any way and yet it annoys me every time I see it since I can't imagine how anyone could have missed this since I have played through that scene on at least 4 different occasions and it happens every time without fail, surely I'm not the only one to experience this. How did the bug testers miss this or do they not give a damn.

This happens if you ask about Glyph. If you don't ask about glyph, the worst you get is the simple issue with Shepard turning to look towards glyph.

This is an issue with the VI having the focus instead of releasing the focus of attention back to Shep/Liara during their conversation. So, if you choose it as the first part of the conversation, they will otherwise attempt to look at Glyph instead of each other. This should be a relatively easy fix, which I hope BioWare will fix, but only because it is mildly annoying, rather than a game breaker. If you played the  ME 2 Shadow Broker DC, your really don't nee to even start that part of the conversation, or at least should save it until the last question so that it isn't as annoying.

How about you guys fix it instead of us having to skip it? Is that possible?

There are other times, like during the Udina section on the Citadel where the camera isn't even looking at anyone, just staring off in the background...

Modifié par Battlepope190, 11 août 2012 - 11:24 .

[Ninja Stan]

-Skorpious- wrote...

Thank you replying Sylvf, but I have a question to ask if you don't mind - how did you guys not notice that importing face codes did not function properly? 
That is a pretty huge glitch to miss/ignore. 

ALL BUGS ARE NOT CREATED EQUAL.

Bugs that make it to release are not necessarily always missed by QA. Between in-house QA, publisher QA, and certification, there are few bugs that catch developers completely by surprise and only a small fraction of these are truly game-breakers with no workaround. But why do you still see bugs in the final release?

Videogames are made of hundreds of thousands of lines of code, compressed files, binary representations of art and animation, all wrapped around a game engine that, like the laws of physics, determines how things are supposed to react to input. This game engine is itself composed of tens of thousands of lines of code that a group of human beings created. All of this is subject to human error at one point or other. This is the reality of real life: stuff breaks, no matter how well-designed, well-built, or well-error-checked it may be.

Okay, now that the main thrust of this argument is done, let's get into the specifics. Human error accounts for how errors get into the code, but QA is supposed to find them all and report them so they can get fixed, right? Yes, that is the primary job of QA as most people know the term. But what some people may not know is that there are several steps between QA and final build, and as the deadline for release looms, these steps become increasingly important to the task list of developers.

1. QA: Yes, QA can miss things, believe it or not. They are human and subject to error. Even if QA is more or less perfect and report issues constantly over the course of the entire project, the error-checking ability of a couple hundred QA trying to check three platforms is still dwarfed by the number of players the game has. And once the game is more or less done, those QA move to different tasks. Meanwhile, the game gets released to players who play the game over and over again, allowing them more opportunity to find things QA may never have seen. Yes, some developers try to get QA on a project early to catch bugs before they're solidified in the code, but still, the numbers can work against them.

2. Stability: Because games are so complex these days, they are like a giant house of cards and some parts can be amazingly fragile. The complex interaction between multiple systems can sometimes require some rather impressive jury-rigging in order to make things work. in NWN, for example, there are some function calls that return FALSE that simply have to exist for the game to keep working. For some reason. Some systems have to be hacked together with the digital equivalent of duct tape, papier-mache, and prayer. Unsurprisingly, bugs can crop up among and around these systems. In a perfect world, all bugs and issues should be fixed, but videogames are a business that risks tens of millions of dollars on a game hitting its target release date, or its target certification date, or whatever date. Bugs that involve fragile systems require a lot of time and a delicate hand to fix, and fixing the bug sometimes isn't possible without dismantling the system in question and rebuilding it. This is sometimes feasible if there is a lot of time to release, or if the features that depend on that system aren't complete yet. Later in the project, it may no longer be feasible.

Also, a given system may be a hub that holds many other systems or features together and messing with it may have a ripple effect that hits many other systems. Rather than risking a cascade of failing systems, a team may decide to leave well enough alone and accept that a bug exists. This is decided in bug triage (point #4, below).

3. Production: For much of the project, it's pretty easy to file a bug report and have developers working on that system to fix it. When deadlines are looming and developers have to prioritize their tasks, bugs can get lost in the shuffle. Bugs are given priority levels that are determined by how the end-user is affected. A serious bug, for example, may be given a lower priority if the reproduction steps are long and complicated (ie. occurs rarely). It may also be given a lower priority if there is a workaround that negates the bug or allows the end-user to continue progressing (e.g. saving and loading the game allows the player to progress, for example). By the same token, a miniscule bug (e.g. a cosmetic issue) may have an elevated priority if it is ubiquitous or the system affected is extremely important.

4. Triage: Usually, the time of greatest bug filing is near the end of a project, when most everything is in place and in more or less a finalized state. At this stage, the game needs to be stable and have no game-breakers, with the focus placed on passing certification. Project leads have daily meetings (some of which can last the enitre regular work day) where they review every new issue filed that day to determine whether to dedicate oh so precious manpower to fixing it. Remember that each developer only had a finite amount of time per day to deal with issues and can only be given a certain amount of work before they simply can't do any more. This is crunch time. Less important bugs frequently fall by the wayside during triage because developers will be assigned issues that are way more important (such as CTDs, game freezes, serious combat issues, save/load issues, plot progression issues, etc.).

Those are more or less the main reasons a bug does or does not make it from filing to fix. A developer's intent is not to have a zero-bug product, contrary to what players might want or expect, just as it's not a movie director's intent to release a zero-continuity-error film. The intent is, instead, to have a working product where most if not all the game-breaking issues are dealt with and any issues remaining in the product can be dealt with because they ultimately don't affect the product being enjoyed from start to finish.

But what about "Bug X" or "Bug Y", people will ask? Well, developers never enjoy hearing about bugs that players are experiencing post-release, but there are ways to deal with them. The BSN has Tech Support forums that are occasionally patrolled by developers, especially when a patch is in the offering. Developers will research issues, ask users for clarification and saved games and reproduction steps. Even if users don't know a patch is being offered, these are good resources. If you don't see your issue being discussed, you can always post about the issue yourself. Be sure to include your platform, reproduction steps that work every time, and a saved game from before the issue occurs, just in case.

Software is usually purchased as-is, so as much as you feel that "all game testers should be fired," please note that it is never your call as to who should be fired from a company whose products you buy, and that calling for someone's head is normally a knee-jerk reaction to disappoint and feelings of helplessness to control whether that issue is fixed. There are many, far more productive ways of calling attention to bugs than throwing a tantrum, and many of them involve mature, constructive discussion. Please use your words and perhaps learn to deal with disappointment in less destructive ways. It will make discussion in the forums, and discussion with developers, much easier. Thank you.

[Rustedness]

"Should be fired"? The bugs in this game were nowhere near as bad as New Vegas, and I didn't wish firing on them...

[SnakeEyes]

I have only ever encountered two bugs while playing through ME3 on PS3:
- The first is during the cutscene after you shoot Dr. Eva and Ashley/Kaiden get beaten up. When Shepard slings them over his shoulder the game freezes without fail. Once I reset my console and reload from the autosave it works fine.
- When you first talk to Liara and Glyph aboard the Normandy and Glyph is floating around, Shepard's head keeps trying to look at him and he doesn't go back to facing Liara when Glyph goes flying behind him.

Modifié par Kurt-Niisan2, 12 août 2012 - 12:03 .

[habitat 67]

Battlepope190 wrote...

Selene Moonsong wrote...

Raizo wrote...

My favourite bug is the first time you talk to Liara on the Normandy. I can't speak for everyone but my Shepard always turns his head 90 degrees to the right and it stays that way for the full duration of the whole entire conversation ( I think he/she is watching Glyph fly around the room and his/her head gets stuck in that position ). What's even funnier is that during that same conversation Liara turns her head 9T0 degrees to the left it stays that way during the whole conversation. This happens to me on the both the PS3 and 360 versions of the game. Now as far as bugs go this is very minor since it does not break the game in any way and yet it annoys me every time I see it since I can't imagine how anyone could have missed this since I have played through that scene on at least 4 different occasions and it happens every time without fail, surely I'm not the only one to experience this. How did the bug testers miss this or do they not give a damn.

This happens if you ask about Glyph. If you don't ask about glyph, the worst you get is the simple issue with Shepard turning to look towards glyph.

This is an issue with the VI having the focus instead of releasing the focus of attention back to Shep/Liara during their conversation. So, if you choose it as the first part of the conversation, they will otherwise attempt to look at Glyph instead of each other. This should be a relatively easy fix, which I hope BioWare will fix, but only because it is mildly annoying, rather than a game breaker. If you played the  ME 2 Shadow Broker DC, your really don't nee to even start that part of the conversation, or at least should save it until the last question so that it isn't as annoying.

How about you guys fix it instead of us having to skip it? Is that possible?

There are other times, like during the Udina section on the Citadel where the camera isn't even looking at anyone, just staring off in the background...

The head turning bug is hilarious and does not need fixing you grouchy Batarian...

[Pressedcat]

Thanks Ninja Stan: that made for some interesting reading.

[voteDC]

I'd rather fire those who bury the reports of the bugs rather than the testers who no doubt report them.

For myself I'm growing increasingly annoyed with how the Drone in the Escort mission in the multiplayer glitches under the map.

I'd say it happens around 3 times out of 10 of that objective type. I genuinely do not believe this could have been missed during testing and so the only way it was allowed to make release was because it was buried by the higher ups.

[RebelTitan428]

i only played the campaign once, as once was enough.
But in both SP and MP my character will disappear and the only thing visible is the weapon mods.
just a ghost running around

[TheRealJayDee]

Ninja Stan wrote...

-Skorpious- wrote...

Thank you replying Sylvf, but I have a question to ask if you don't mind - how did you guys not notice that importing face codes did not function properly? 
That is a pretty huge glitch to miss/ignore. 

ALL BUGS ARE NOT CREATED EQUAL.

Bugs that make it to release are not necessarily always missed by QA. Between in-house QA, publisher QA, and certification, there are few bugs that catch developers completely by surprise and only a small fraction of these are truly game-breakers with no workaround. But why do you still see bugs in the final release?

Videogames are made of hundreds of thousands of lines of code, compressed files, binary representations of art and animation, all wrapped around a game engine that, like the laws of physics, determines how things are supposed to react to input. This game engine is itself composed of tens of thousands of lines of code that a group of human beings created. All of this is subject to human error at one point or other. This is the reality of real life: stuff breaks, no matter how well-designed, well-built, or well-error-checked it may be.

Okay, now that the main thrust of this argument is done, let's get into the specifics. Human error accounts for how errors get into the code, but QA is supposed to find them all and report them so they can get fixed, right? Yes, that is the primary job of QA as most people know the term. But what some people may not know is that there are several steps between QA and final build, and as the deadline for release looms, these steps become increasingly important to the task list of developers.

1. QA: Yes, QA can miss things, believe it or not. They are human and subject to error. Even if QA is more or less perfect and report issues constantly over the course of the entire project, the error-checking ability of a couple hundred QA trying to check three platforms is still dwarfed by the number of players the game has. And once the game is more or less done, those QA move to different tasks. Meanwhile, the game gets released to players who play the game over and over again, allowing them more opportunity to find things QA may never have seen. Yes, some developers try to get QA on a project early to catch bugs before they're solidified in the code, but still, the numbers can work against them.

2. Stability: Because games are so complex these days, they are like a giant house of cards and some parts can be amazingly fragile. The complex interaction between multiple systems can sometimes require some rather impressive jury-rigging in order to make things work. in NWN, for example, there are some function calls that return FALSE that simply have to exist for the game to keep working. For some reason. Some systems have to be hacked together with the digital equivalent of duct tape, papier-mache, and prayer. Unsurprisingly, bugs can crop up among and around these systems. In a perfect world, all bugs and issues should be fixed, but videogames are a business that risks tens of millions of dollars on a game hitting its target release date, or its target certification date, or whatever date. Bugs that involve fragile systems require a lot of time and a delicate hand to fix, and fixing the bug sometimes isn't possible without dismantling the system in question and rebuilding it. This is sometimes feasible if there is a lot of time to release, or if the features that depend on that system aren't complete yet. Later in the project, it may no longer be feasible.

Also, a given system may be a hub that holds many other systems or features together and messing with it may have a ripple effect that hits many other systems. Rather than risking a cascade of failing systems, a team may decide to leave well enough alone and accept that a bug exists. This is decided in bug triage (point #4, below).

3. Production: For much of the project, it's pretty easy to file a bug report and have developers working on that system to fix it. When deadlines are looming and developers have to prioritize their tasks, bugs can get lost in the shuffle. Bugs are given priority levels that are determined by how the end-user is affected. A serious bug, for example, may be given a lower priority if the reproduction steps are long and complicated (ie. occurs rarely). It may also be given a lower priority if there is a workaround that negates the bug or allows the end-user to continue progressing (e.g. saving and loading the game allows the player to progress, for example). By the same token, a miniscule bug (e.g. a cosmetic issue) may have an elevated priority if it is ubiquitous or the system affected is extremely important.

4. Triage: Usually, the time of greatest bug filing is near the end of a project, when most everything is in place and in more or less a finalized state. At this stage, the game needs to be stable and have no game-breakers, with the focus placed on passing certification. Project leads have daily meetings (some of which can last the enitre regular work day) where they review every new issue filed that day to determine whether to dedicate oh so precious manpower to fixing it. Remember that each developer only had a finite amount of time per day to deal with issues and can only be given a certain amount of work before they simply can't do any more. This is crunch time. Less important bugs frequently fall by the wayside during triage because developers will be assigned issues that are way more important (such as CTDs, game freezes, serious combat issues, save/load issues, plot progression issues, etc.).

Those are more or less the main reasons a bug does or does not make it from filing to fix. A developer's intent is not to have a zero-bug product, contrary to what players might want or expect, just as it's not a movie director's intent to release a zero-continuity-error film. The intent is, instead, to have a working product where most if not all the game-breaking issues are dealt with and any issues remaining in the product can be dealt with because they ultimately don't affect the product being enjoyed from start to finish.

But what about "Bug X" or "Bug Y", people will ask? Well, developers never enjoy hearing about bugs that players are experiencing post-release, but there are ways to deal with them. The BSN has Tech Support forums that are occasionally patrolled by developers, especially when a patch is in the offering. Developers will research issues, ask users for clarification and saved games and reproduction steps. Even if users don't know a patch is being offered, these are good resources. If you don't see your issue being discussed, you can always post about the issue yourself. Be sure to include your platform, reproduction steps that work every time, and a saved game from before the issue occurs, just in case.

Software is usually purchased as-is, so as much as you feel that "all game testers should be fired," please note that it is never your call as to who should be fired from a company whose products you buy, and that calling for someone's head is normally a knee-jerk reaction to disappoint and feelings of helplessness to control whether that issue is fixed. There are many, far more productive ways of calling attention to bugs than throwing a tantrum, and many of them involve mature, constructive discussion. Please use your words and perhaps learn to deal with disappointment in less destructive ways. It will make discussion in the forums, and discussion with developers, much easier. Thank you.

Thanks for the interesting read. But still, really, please make me understand how you managed to miss the face import issue? It was right there in your face when you tried to import a character from a previous game. It was big. It was obvious. It affected one of the major features of the trilogy. How did you not notice it? How did not a single reviewer notice it? This is really just unbelievable. Not saying anyone should be fired, but something of this magnitude is not really a testament of good work. Because this did very much "affect the product being enjoyed from start to finish".

As for the part bolded by me: we had a thread politely pointing out the face import issue over a week before release - it was completely ignored until after release.  We struggled to get a statement on the fact that there weren't enough War Assets to get high enough EMS for the 'Breath scene' without playing multiplayer - we were ignored or told things that were factually wrong. Etc.

We are not the only ones who could and should've worked on their communication skills. It would have made discussion in the forums and discussion with some of your fans much easier.

[legion 21]

it gets glitchier with every playthrough

[Ninja Stan]

voteDC wrote...

I'd rather fire those who bury the reports of the bugs rather than the testers who no doubt report them.

Bug reports are never "buried" as you define the term. No bug is ever ignored, sight unseen. All bugs are seen by the QA lead on the project and the triage team at the very least. Whether the bug is a high enough priority bug, or whether there is available time and manpower to fix it, is a very different story altogether. And unfortunately, it's not one that you, the end-user, can dictate. Also, in case I didn't state it earlier, this is generally the process for every software product ever, yet people aren't screaming for all developers to be fired. Or haven't you noticed the software updates from Windows or the occasional updates in drivers, game patches, digital delivery systems, apps, browser games, etc.?

Users will likely continue to find bugs in software products, but the money spent to find, investigate, reproduce, and patch them is not infinite. At some point after release, it's not worth the time and effort it would take to patch the product and whatever benefit is gained is vastly outweighed by the next release, say, or the next latest and greatest product.

For myself I'm growing increasingly annoyed with how the Drone in the Escort mission in the multiplayer glitches under the map.

I'd say it happens around 3 times out of 10 of that objective type. I genuinely do not believe this could have been missed during testing and so the only way it was allowed to make release was because it was buried by the higher ups.

Read my long-winded post again. Your belief is largely immaterial when developers triage bugs. That's the way it happens much of the time, in my experience.

[Ninja Stan]

TheRealJayDee wrote...

Thanks for the interesting read. But still, really, please make me understand how you managed to miss the face import issue?

Maybe testers didn't check all the possible face combinations to ensure that a) they worked as is, and imported from ME2 correctly. Maybe they had other priorities elsewhere. Maybe the bug was filed and didn't get addressed. Maybe it wasn't seen as a big deal and was triaged to be dealt with later. There are many possibilities, but without the people who did or did not file the issue present, there's no real way to know for certain.

It was right there in your face when you tried to import a character from a previous game. It was big. It was obvious. It affected one of the major features of the trilogy. How did you not notice it? How did not a single reviewer notice it?

Maybe no one is as smart and perceptive as you are?

Sarcasm aside, that's not really an answerable question. Perhaps the issue was "big" and "obvious" to you because you experienced it. Perhaps no tester experienced it. From what I understand, the issue occurred only in certain faces but not others. It was either specific face components, or a combination of specific components, that were affected. If that is the case, it is possible that no tester or reviewer used those particular pieces or combination of pieces in their Shepard's appearance.

This is really just unbelievable. Not saying anyone should be fired, but something of this magnitude is not really a testament of good work. Because this did very much "affect the product being enjoyed from start to finish".

From what I understand, there was a workaround that allowed the player to continue playing the game, so no, a player's ability to play the game from start to finish was not affected. Sure, it wouldn't be the player's ideal face or preferred face or the face used for his Shepard from the beginning of the trilogy, but it didn't explode people's computers and didn't freeze the game and didn't remove Shepard's stats and didn't crash to desktop upon save/load.

As for the part bolded by me: we had a thread politely pointing out the face import issue over a week before release - it was completely ignored until after release.  We struggled to get a statement on the fact that there weren't enough War Assets to get high enough EMS for the 'Breath scene' without playing multiplayer - we were ignored or told things that were factually wrong. Etc.

A week before release, the game would have been finalized and already gone through and passed certification, and would have been sent in for manufacturing. The game-on-disc would not have been changed. The import issue, as far as I know, was already being looked at by or around that time.

The community brings up a lot of issues immediately post-release. Much of the time, that's a terrible time to bring up issues that you want immediate responses on, since developers will want to see how widespread an issue is before devoting time and effort (and therefore, money) on it. I don't know if you noticed, but the community tends to exaggerate things sometimes. Some people claim to speak for a majority of users, while others are certain that "most people" are experiencing certain issues. For the last few releases, BioWare had a "war room" set up to deal with issues that came up immediately after release, kind of a live team that dealt with bug reports that cropped up.

We are not the only ones who could and should've worked on their communication skills. It would have made discussion in the forums and discussion with some of your fans much easier.

Having been a Moderator of the BioWare online community for the last 10 years, I agree with you. But the community is the party looking for answers, discussion, and reassurances, and has no restrictions on how it goes about doing so. BioWare, as a company, has a lot of restrictions on how it can interact with the community and what it can say and how. When the community as a whole can acknowledge that, and devote more time and effort in creating mature, constructive discussions, that's when communication with fans will become much easier.

[TheRealJayDee]

Ninja Stan wrote...

TheRealJayDee wrote...

Thanks for the interesting read. But still, really, please make me understand how you managed to miss the face import issue?

Maybe testers didn't check all the possible face combinations to ensure that a) they worked as is, and imported from ME2 correctly. Maybe they had other priorities elsewhere. Maybe the bug was filed and didn't get addressed. Maybe it wasn't seen as a big deal and was triaged to be dealt with later. There are many possibilities, but without the people who did or did not file the issue present, there's no real way to know for certain.

It was right there in your face when you tried to import a character from a previous game. It was big. It was obvious. It affected one of the major features of the trilogy. How did you not notice it? How did not a single reviewer notice it?

Maybe no one is as smart and perceptive as you are?

Sarcasm aside, that's not really an answerable question. Perhaps the issue was "big" and "obvious" to you because you experienced it. Perhaps no tester experienced it. From what I understand, the issue occurred only in certain faces but not others. It was either specific face components, or a combination of specific components, that were affected. If that is the case, it is possible that no tester or reviewer used those particular pieces or combination of pieces in their Shepard's appearance.

This is really just unbelievable. Not saying anyone should be fired, but something of this magnitude is not really a testament of good work. Because this did very much "affect the product being enjoyed from start to finish".

From what I understand, there was a workaround that allowed the player to continue playing the game, so no, a player's ability to play the game from start to finish was not affected. Sure, it wouldn't be the player's ideal face or preferred face or the face used for his Shepard from the beginning of the trilogy, but it didn't explode people's computers and didn't freeze the game and didn't remove Shepard's stats and didn't crash to desktop upon save/load.

I guess I am smarter and more perceptive than your QA department then. But I'm not alone in this. Because, well, personally I didn't even experience the face import fail until almost two weeks after release, cause that's how long I waited to even open my game. And even then I had to rebuild my Shepard from scratch. Why did I wait in the first place? Because of the massive backlash about the face import issue. I wanted to play ME3 with my Shepard, and I knew I couldn't. Trying to import a custom character imported throughout ME->ME2->ME3 resulted in an error message. ME2->ME3 imports had problems as well. Players with default Shepard's were the lucky ones. And no, not every player with a custom Shep experienced this, but many. I could link you to the threads discussing the problems, if you like. One was about 350+ pages long before Chris Priestly locked it with reference to a patch that didn't fix all the problems. It was not an obscure bug that only few players stumbled upon, it was massive.

The whole singleplayer/EMS debacle was so ridiculous and embarassing (at least it should be for Bioware) I won't even say more about it.

As for the bolded sentence again...

Ninja Stan wrote...

BioWare, as a company, has a lot of restrictions on how it can interact with the community and what it can say and how. When the community as a whole can acknowledge that, and devote more time and effort in creating mature, constructive discussions, that's when communication with fans will become much easier.

...yeah, you know, ready when you are. 

[brian t]

I don't think the game testers should be fired that is kinda harsh man but I wish they would fix the freezing that happens every 2 to 3 hours sometimes you can play up to 5 hours before my PS3 completly freezes up and I have to do a hard restart which can be annoying and it haoppens at least once a day and I have PSN version so its not the disc since I don't have one.

[Ghost]

 Bug thread:

social.bioware.com/forum/1/topic/345/index/10707992/1

Modifié par Ghost1017, 12 août 2012 - 03:12 .

[Dup3r]

Stan, you rule. Great explanation (in a simplified way.)

The Unreal engine is pretty groovy, but it's not perfect. Also, a geth falling off a walk isn't really a "bug". Weird things happen from time to time and I've always chalked it up an engine quirk when collision starts clipping or whatever.

Seriously, if you think things are "easy" to fix, try setting up an animated sequence in UDK.

Watch this:
Then watch the HoverCraft vid. wow.

Modifié par Dup3r, 12 août 2012 - 03:45 .

[diggisaur]

Why is it so difficult to just restart the level? Insanity is a cakewalk on ME3. Hardest part on insanity was killing the Reaper on Rannoch (Kai Leng on TIM base was a close second).

[Terror_K]

Sylvf wrote...

I'm sorry that happened to you Acid Mars, but I'd like to say that our QA department worked incredibly hard and long on this project. None of them deserve to be fired. A game like ME3 is incredibly complicated to test. (Most of us in writing were testing ME3 by the end ourselves, just so we could have more people looking at it. I'm not trying to excuse any bugs, but making a game problem-free isn't as straightforward as we'd like)

The fact that the character import doesn't import faces properly not only when the game released, but to this day, is, IMO, reason enough alone to fire somebody. Considering the whole feature was one of the biggest selling-points of the game long before even ME1 came out, and you guys completely borked it in ME3, then had the gall to tell us it was since fixed in a patch when it wasn't, then even go on to lie outright about it being an issue that it wasn't to add insult to injury.

There's no excuse for that. Not when it was supposed to be a key feature of the game. Knowingly creating a character creator that not only fails to do the very thing it was designed to do, but isn't even capable of it through manual means due to facial options being missing entirely is, quite frankly, unforgivable. And the way it's been handled since makes it beyond unforgivable.

But hey... I suppose once you've got everybody's money already, it doesn't matter anymore.

Ninja Stan wrote...

Sarcasm aside, that's not really an answerable question. Perhaps the issue was "big" and "obvious" to you because you experienced it. Perhaps no tester experienced it. From what I understand, the issue occurred only in certain faces but not others. It was either specific face components, or a combination of specific components, that were affected. If that is the case, it is possible that no tester or reviewer used those particular pieces or combination of pieces in their Shepard's appearance.

It wasn't rare at all though. It affected (and still affects) pretty much everybody who has done an import through all three games. It also doesn't just affect certain faces, because it happens to every face that I've tried to import, with almost all male shepards being turned into the same looking face in the end no matter how diverse the original ones are. Missing this is practically impossible if an ME1 > ME2 > ME3 save is imported.

The Character Creator is just completely fail. It utterly lacks customisation options that were in the previous two games entirely, so not only is the import failing, but players can't even recreate the original faces because the options aren't present at all. Fans trying to fix the problem have had to jump through so many hoops to the point of having to completely remodel and remap the vertices of their character's faces just to get them to look even remotely close.

You guys got it right with the ME1 > ME2 import and ME2 character creator, with the only problem being that ME1 Shepards couldn't get facecodes. How the ME3 character creator came to fail so utterly is beyond me. It should simply never have been so poorly made and implemented in the first place.

Modifié par Terror_K, 12 août 2012 - 05:38 .