55 réponses à ce sujet

[fantasypisces]

If anything I bet this.



The pirated version got out and BW went "ooh no, we can't have that, let's add more stuff to punish the people that stole" (when all they are adding is said cutscene from my post above). But ultimately what happens is that whole 2 minutes of new content breaks the rest of the DLC forcing even more delays.

[ZeroR3D]

ohupthis wrote...

the simple explanation, hmm where to begin, the first "layer" is finished alpha-testing/goes to beta(or open beta), out there, there is more different configurations of hardware, thusly you can uncover a few more anomolies, after yout "team" has successfully ironed out that phase, you send it out as a "playable" config(assuming it's a game), this software gets out into the wild(us plain folk), and suddenly there's a flurry of biblical proportions(regarding minor issues,but blown out of proportion), said issues are correced(mostly), as you can't please them all(sadly),

A hardware-specific issue isn't a game-breaking bug.  Of course, I don't know what the nature of the defect that retarded RtO from its "holiday season 09" release was.  Could've been Alistair's pants disappearing for all I know (some of you may regard that as a feature, not a defect...) but the official "explanation" was that it was something serious enough to warrant going back to ensure "quality" was delivered to the end user.

Second phase, DLC or an add-on has to be scrutinized even more vigorously, as it often "frags" the original portion of the software(not always but most of the time)
this is where us plain folk lose our tempers on the writers/publishers, because y'all haven't CLUE 1 about how everything added on,can inevitably frag the whole thing!!!

My point is that no one in their right mind creates DLC that would "frag" the original game.  Like if you create a system for talents, adding a new talent or two (like with warden's keep), should not create issues big enough to break the game.  By the same token, afaik RtO adds a bit of new questing, a new set of armor, all things that should be testable using the testing process designed to test the original game. 

Like the first time a dev added a new quest module, they had to test it some way.  Adding a new quest module, test it in more or less the same process.  Unless you make fundamental changes in the way quest modules work, you should be "ok" reusing the same testing *framework* and the likelihood of high-severity/priority bugs passing a bunch of testing (dev unit testing, QA stability testing, fix high-priority defects, rinse, repeat) and showing up at the last minute is practically inconceivable.  Let alone twice or more!

Modifié par ZeroR3D, 14 janvier 2010 - 07:48 .

[OH-UP-THIS!]

you just don't get it do you!!!???

everybody does create software that frags the original, that's why it's imperitive to test as many ways as possible, the fact MICROSHAFT jumped the gun, was the primary reason Bioware couldn't get it out fast enough

As for your opinion/...........go take a software engineering course and report back!!!

[ZeroR3D]

haha wow, no need it to take it personally.

For the record, I'm a certified PMP who's worked in IT/Software development for the past few years. Someone who knows me IRL may attest to this.

Modifié par ZeroR3D, 14 janvier 2010 - 08:11 .

[Lohe]

I dont know a company named Microshaft. Do you mean Microsoft? Well, Im pretty sure they have a release schedule on their marketplace. If Bioware has announced an update/dlc for 13th January, MS will fire it off if the content was checked and is on their servers. Thats how I got it so far. Possibly wrong. Just my 2 cents.

[thegreateski]

I imagine the OP will get a response like this:



"**** happens"

[AlaskanHusky]

A wise man said once



One time late cause of traffic say sorry. Twice late cause of traffic say sorry. Thrice late cause of traffic say goodbye.

[Mordaedil]

ZeroR3D wrote...

So, you are Bioware/EA. You've developed this awesome game called Dragon Age: Origins. This typically means that by the time the game's gone gold, there are literally no game-breaking bugs in the release. There obviously can be low-severity, low-priority defects and issues being worked on for 0-day or post-release patch. But having gone through the necessary QA process to remove any high-severity, high-priority defects, you would have established test cases/scenarios that cover (more or less) every aspect of the game, from graphics, text/voice dialogue, to the stats system, interactions, etc. We'll call this the general "framework" of the game.

Actually, by the time the game is gold, only MOST of the game-breaking bugs are fixed. There are several games since the 80's that have never been fixed and have game-breaking bugs since day one, some even going as far as formatting your PC when you attempt to uninstall it.

All of these games also went through extensive game testing, but players have a tendency to sometimes do things the testers and designers didn't think about, or in the case of PC game development, had a setup that was different enough to cause problems with the software they developed.

ZeroR3D wrote...

So, this is where I get confused. If you don't add anything to the framework of the game, like by creating a piece of DLC such as RtO, and you have an established methodology to test that framework, how can it be possible for game-breaking high-severity, high-priority defects to pop up at the last minute?

Probably the cause of human error. A lot of the time in game design, you hope that scripts work as intended, but sometimes, to produce something that works, you have to cheat a little. This means in GM terms, add in modifiers where they are required to get the game to run smoothly.

When you then introduce an additional piece that was made by someone not familiar with your little modifiers, suddenly they roll all the wrong saves. Scripts don't work because they only worked in certain situations that were needed only in the main campaign or that little something is missing from your newly made content and now it floats and doesn't flow. Or it could be as simple as a missing comma.

ZeroR3D wrote...
To provide an example, are there specializations in RtO that are new to the game? If not, why would RtO affect specializations unlock status at all?

DAO uses event based scripting. This means when dealing with specializations, it might be going off to get all integers dealing with specializations from a single function. But in the course of bringing up these integers, a simple error such as misplaced comma or a missing semi-colon could have disastrous effects: Suddenly you are no longer calling a check to see what specializations the character has, but instead you've added a non-existing one.

If you ask a computer what is 2+2 and it return the answer 4, you know it works. But what if that is all you test and then someone else asks it what is 2+3 and it returns the answer b.

Now something is wrong and it's probably a very easy mistake to fix. Unless you find out the error lies somewhere in 5000 lines of code across 50 files that need to be retrofitted so they work properly with eachother.

ZeroR3D wrote...
I understand that I'm not privvy to the managment of code nor how the code is written for DA:O and I'm probably wayy oversimplifying it, but really? Last minute defects, three or more times? In my experience, that would be the result of poor project management, poor source control, poor change management, poor QA, poorly written code, BS'ing the end users, or all of the above. That may come off a bit harsh and I really don't expect an official response from Bioware/EA, but I am VERY curious to know how this type of development can be explained. So if anyone works in SD, or has some interesting ideas, please don't hesitate to speak up.

Or a simple oversight in 99 places where someone mistook GetSpecilization with SetSpecilization.

Titius.Vibius wrote...

Zero can you say something about this screenshot of a manual download of RTO for PC that came from the ea.com website. The date of the file is January 5, 2010.

Wait, what? PRC_CP isn't RtO as far as I know. That should be the Stone Prisoner.

[Mirolsen]

CP_1 is for sure RTO, so why stone prisoner is CP_2? because those DLC were part of vanilla game

Modifié par Mirolsen, 14 janvier 2010 - 08:58 .

[MOTpoetryION]

IMO It just seems like they don't really spend that much time QAing these days. More and more i feel they rush it out, And we are the ones that pay them to beta test their games for them. And sadly the community are the ones that come up with most of the fixes/workarounds as well.

I'm mean how long the game been out little over 2 months . And boiware just made a thread to find out why loading times get longer and longer . If i was a tester i would of spotted 90 % of the problems they had with this game . before release , But probably would not have my job for long (Dev's would really hate me quick and conspire to get me fired) for making more work for them .Your rep is important too guys , Its a trend after a really good/popular game , the next one is sloppy

But i always try and do it right the first time because i still live by the rule put pride in your work and do it the best you can. Seems like the QA guys are scared to mention problems or something .Either that or they need to hire people with better eyesight.

I have watched /been a part of the industry from the very start E.g i played pong when it first came out . My first handheld was nothing but red LED lights.i have just been seeing some disturbing trends of late . And believe it of not most are the direct results of one game .WOW.thats where this DLC originated from the fact that all you WOW players paying month after month for a game. Others seen all that money and they wanted it too. I have a policy i will Never Pay 2 Play. And i Want my game On a CD.

I've been waiting for years for diablo3 to come out ,but if they made it P2P i would pass it up .(thank god they are not ) Just like this game i actually broke down a bought the DLC It was my present to myself. YA i guess i was a bad boy last year . But there were so many problems involved with it, it set me straight again ,They are just lucky i put to much money into points ,And just waiting to use them up .

In essence guys they sold us a game for about 70 + $ . that was not polished in the least, Just remember gamers" For every action =...

But its been touched on above that EA is involved that says it all right there .And sorry to break it to you guys but it looks like EA has tainted yet another game company. . ALL they do these days is suck up the good companies,(but some going under) finance the finishing of games in progress and slap the EA logo on it . And then spend way to much on advertisement , report loses then lay people off. And try and recoup their money from us. EA is a parasite to this industry and doing nothing but hurting it.

And don't bother flaming me i wont respond i have said what i needed to say period. .i just want you all to remember when you are paying to play or buying DLC it costs more then you think .

" thats the way i feel anyway take it for what it is " : )

Modifié par MOTpoetryION, 14 janvier 2010 - 09:29 .

[fluffyamoeba]

RTO was probably planned before The Stone Prisoner. Shale wasn't going to be put in at all, it was only the delay in the release date that meant The Stone Prisoner happened. Don't forget, the original DLC/expansion release schedule was assuming a march 09 release for DA. Also it's perfectly possible to say have 2 people creating outlines of various DLCs and not getting the full team to start work on it till several months later. For instance, RTO could have been started then, once the release date was pushed back, people got transferred from working on RTO to working on The Stone Prisoner (and/or the OC). Once that and the other day 1 DLC was finished and released, they went back to working on RTO (and/or the expansion).



Projects get named in the toolset as soon as you create them, not the day you decide they're finished

[ZeroR3D]

Mordaedil wrote...

Actually, by the time the game is gold, only MOST of the game-breaking bugs are fixed. There are several games since the 80's that have never been fixed and have game-breaking bugs since day one, some even going as far as formatting your PC when you attempt to uninstall it.

I did say *typically*.  And that's a bit of a skewed perspective - besides Bungie's bungle, how many games tend to mess up your system that bad?  In recent memory, none.  How many mainstream PC games from major studios have you played that have not worked at all on release day?

All of these games also went through extensive game testing, but players have a tendency to sometimes do things the testers and designers didn't think about, or in the case of PC game development, had a setup that was different enough to cause problems with the software they developed.

And this applies to RtO how?  It wasn't released to players.  Again, hardware-specific issues are not what we're talking about here.  They don't count as game-breaking defects unless it's something like the game doesn't render on Nvidia cards (which I expect would get picked up during QA).

Probably the cause of human error. A lot of the time in game design, you hope that scripts work as intended, but sometimes, to produce something that works, you have to cheat a little. This means in GM terms, add in modifiers where they are required to get the game to run smoothly.

When you then introduce an additional piece that was made by someone not familiar with your little modifiers, suddenly they roll all the wrong saves. Scripts don't work because they only worked in certain situations that were needed only in the main campaign or that little something is missing from your newly made content and now it floats and doesn't flow. Or it could be as simple as a missing comma.

Kludging the code is a big no-no on a collaborative project.  I'm not saying it doesn't happen (I've seen it happen far too often in my own experience).  But any pro shop knows that the effects of kludging is wasted time down the road. 

In any event, even if you kludge the code, there's only so far you can go until your stuff as a single dev stops working altogether with the rest of everyone else's work.  This typically gets picked up right away by other devs doing their own unit testing, and again wouldn't likely make it past QA round 1.

So unless bioware devs don't test their work, check in their code all at the same time, and QA only does one pass of testing, it would be extremely difficult for some kludge to break the game immediately before release.  What's more likely is that they develop and test/fix/retest all the way up to release deadline.  This often leads to missed deadlines.

DAO uses event based scripting. This means when dealing with specializations, it might be going off to get all integers dealing with specializations from a single function. But in the course of bringing up these integers, a simple error such as misplaced comma or a missing semi-colon could have disastrous effects: Suddenly you are no longer calling a check to see what specializations the character has, but instead you've added a non-existing one.

If you ask a computer what is 2+2 and it return the answer 4, you know it works. But what if that is all you test and then someone else asks it what is 2+3 and it returns the answer b.

Again, I fail to see how this would make it past QA round 1.  Now to be clear, when I say QA I mean the typical cycle:  Round 1 identifies a majority of game-breaking defects (high-severity/priority).  Then there's a period of defect resolution.  Round 2 retests and checks solutions for high-priority defects from R1 and identifies other high-severity defects.  Your target (and I know this is an ideal situation) is to sharply decrease the amount of high-severity/priority defects during QA such that, by the end of it, you are in a stable enough state to be ready for release.  Stable enough means NO game-breaking issues.

So like I said, unless they test until the last minute and didn't give themselves a buffer to release date, I have a hard time believing all these issues popping up last minute.

Now something is wrong and it's probably a very easy mistake to fix. Unless you find out the error lies somewhere in 5000 lines of code across 50 files that need to be retrofitted so they work properly with eachother.

Even with products I've worked with involving millions of lines of poorly documented spaghetti code, most things were still fairly compartmentalized.  Problems involving multiple modules weren't impossible to fix and turnaround was within days.  From the missed release date in Dec, they've had about 2 weeks to work out those problem.  Evidence suggests that they have actually resolved them on the PC side, so I dunno what to say about the ongoing delays.

Or a simple oversight in 99 places where someone mistook GetSpecilization with SetSpecilization.

Sorry, that's something that would get picked up in the dev's own unit testing.  Would never get past one round of QA, and definitely should not be popping up last minute.  But I get what you're saying.

Wait, what? PRC_CP isn't RtO as far as I know. That should be the Stone Prisoner.

http://dragonage.wikia.com/wiki/DLC

Stone Prisoner is CP2.

[Some Dude On The Internet]

Can't speak for game developers, but a lot of times in business apps, our programmers would make a perfectly functional version of the program and send it to QA / Testing only to have the tester say something like, "Hey, it zaps the data if you highlight an odd-numbered row and hit [CTRL-F12]!"



The programmers of course would not have planned for this, since they saw no reason for a user to perform that particular operation (no corresponding hotkey / menu option exists)... but the testers take more of a "what happens if I try some random stuff" approach, which sadly mirrors real life where people look for Easter eggs or cheats and do things that they would have no reason to do under "normal" circumstances...



Of course, once word gets out that a certain action "breaks" the software, then the floodgates open - hey, if [CTRL-F12] works, maybe [ALT-SHIFT-BKSP] will too - let's try all those unlikely things!



Bottom line, people are going to be exceptionally creative at coming up with ways to break software and even the best developers can't anticipate them all.



On the other hand, if the bug or bugs are something easily replicable under normal playing conditions on plain vanilla environments, then the QA / Test guys need some remedial work...

[SheffSteel]

My understanding of the delay in RtO was that they found a bug in the achievement code that was released in the recent Title Update. They only detected this at the last minute because the Title Update is essentially new code, and the two separate projects - the 360 Update and the RtO DLC - weren't cross-tested until release of one or the other (or both?)

My experience has been that 360 achievement code is something which (1) Microsoft take very seriously (i.e. they will kick your submissions for getting it wrong) and (2) there are plenty of hidden gotchas and ways of doing things that look right but ultimately are not right in all circumstances.

Take this with a pinch of salt. In general I know what I'm talking about when it comes to game development (it's put food on my table since 1992) but in this particular case it's more of an educated guess than anything.

Modifié par SheffSteel, 14 janvier 2010 - 04:45 .

[DoctorPringles]

There are several hundred things that could go wrong and explanations for why a certain bug doesn't get caught until last minute. In this case, I believe the bug has something to do with a combination of inputs that ultimately lead to one really bad output. For instance, like an above post stated, maybe someone from QA decided to highlight an odd-numbered row and press ctrl+2, which proceeded to fry their entire system. It is most likely something obscure like that.

[herwin1]

The problems with the Mac version suggest to me that the game engine makes use of a collection of low-level utilities that are platform-dependent, very finicky and don't scale well. Remember you can play most PC games on a Mac in a Parallels virtual environment and get acceptable performance, so those of us with Parallels can compare the Mac and PC versions directly. So they discovered that one of their hardware and operating system platforms had serious problems that the DLC made obvious. Oopsie.



Alternatively, a beta tester came up with a game-breaker. (Matrix ran into this for WitP AE this last weekend, when a couple of aggressive players discovered the coast defence artillery model was seriously broken.) Perhaps someone found a way of getting infinite experience or gold far too easily. (There is already a way of getting infinite gold, but it uses infinite time.)



This experienced software engineering manager suspects marketing has been driving the release schedule, and development is none too happy. Wait on it a bit.

[Super_Cat]

ZeroR3D wrote...

 that would be the result of poor project management, poor source control, poor change management,

Hehehe, do you have a PMP or something?

[ShadowKhan]

As a Software Quality Assurance Manager, I can assure you there are always late breaking issues. Some are bigger than others. Every effort is taken by software design teams to minimize the risk or exposure of an issue.

But there are times when we are sitting in a meeting reviewing the risks, one of the engineers will popup with something like "You know what would be cool or If we could add this..." I will always follow with what kind of risk is there?

We also have limited hardware and OS choices...there is just no effective way to test every potential combination of hardware and software. So we shoot for a middle of the road system, OS and patch level. We always know on release there will be bugs. We try to stop the real show stoppers.

It is always a game of risk, every time we release anything. All we and others can do is the best we can with the information we have available at the time we commit. Aside from that, it's patch time. Personally I want the fewest bugs possible, but my professional side know if you keep holding it up you will never make any money and therefore be out of a job if you don't release something.

It's not possible to get all the bugs with complex code. This is why we have beta tests, so we can expose the code to a much wider variety of conditions and depending on the feedback depends on where the release date gets set.

There are times when we gamble with new code up to with a week of the release, because we think that would be what a customer wants and the risk is low for any regression bug to sneak in. Other times the We've probably over-committed to what we could do and end up pushing the release which upsets customers. It is really a balancing act and I really wish many of you could understand how unbelievably hard it is doing this. No I don't work for Bioware but I fully understand what they are going through. It is a pain at times and it is not just your $50.00 on the line either...

Modifié par ShadowKhan, 14 janvier 2010 - 06:23 .

[Bibdy]

Development and testing goes in interations and you RARELY have enough time to test EVERYTHING between each iteration without an assload of expensive automation.

When changes are made, you generally do focus testing on whatever you think was affected by the change. You only do full-blown regression testing on UURRRVVVrything at various stages, one of which will be right at the end, which may end up discovering bugs which only cropped up during the very last development iteration and then you ****** your pants and have to block the release until you get it fixed AND fully tested AGAIN.

If you're imagining a software development world where development and testing are 2 separate processes and stages in a product's lifecycle, you're sorely mistaken. Both go hand-in-hand from the moment the very first line of code is written and its simply not possible to check absolutely everything, every time a change is made.

Modifié par Bibdy, 14 janvier 2010 - 06:27 .

[4bs.zer0]

I'd speculate that the task of developing DLCs was given to different (less experienced) development team, while the original team went to work on the expansion.

[herwin1]

4bs.zer0 wrote...

I'd speculate that the task of developing DLCs was given to different (less experienced) development team, while the original team went to work on the expansion.

80-90% of the effort is in maintenance, so I doubt there's a great experience gap. I do suspect they reorganised.

[ZeroR3D]

Bibdy wrote...

Development and testing goes in interations and you RARELY have enough time to test EVERYTHING between each iteration without an assload of expensive automation.

When changes are made, you generally do focus testing on whatever you think was affected by the change. You only do full-blown regression testing on UURRRVVVrything at various stages, one of which will be right at the end, which may end up discovering bugs which only cropped up during the very last development iteration and then you ****** your pants and have to block the release until you get it fixed AND fully tested AGAIN.

If you're imagining a software development world where development and testing are 2 separate processes and stages in a product's lifecycle, you're sorely mistaken. Both go hand-in-hand from the moment the very first line of code is written and its simply not possible to check absolutely everything, every time a change is made.

I know what you're saying.  I just have a hard time believing a simple DLC would be such high-risk and high-impact that it would cause the timeline to be blown three times.

From a development standpoint, it must be very difficult for Bioware/EA to project the next 2 years worth of DLC development then.  Unless it's 2 years of waiting

Modifié par ZeroR3D, 14 janvier 2010 - 07:47 .

[Bibdy]

**** happens. They were probably breathing a sigh of relief after the first problem was fixed, got relaxed, and all of a sudden the lights turn red and alarms start going off again because some jackass QA engineer found a way to get the player to fall through the entire game world when you walk on a certain spot off to the side.

And that's why software project managers get paid good money They're the ones responsible when **** hits the fan, and the **** most certainly hits the fan one way or the other.

Modifié par Bibdy, 14 janvier 2010 - 07:56 .

[ArathWoeeye]

Well, I'm not sure about what exactly is going on but if the final, legit release of RtO messess up specs for everyone directly, then it's QA department being amateur.

[Bibdy]

ArathWoeeye wrote...

Well, I'm not sure about what exactly is going on but if the final, legit release of RtO messess up specs for everyone directly, then it's QA department being amateur.

That something like that was only found at the last minute leads me to believe its ONLY a problem that occurred when you downloaded from XBox Live servers and do authentication and such with them. There's really no way to test that scenario, until you physically upload it to their servers and watch the result.

I find it very difficult to believe nobody noticed missing specialisations at all, during basic QA. Almost all of their testing would have been done in-house, where installing the DLC is just a matter of copying some files across the network. Microsoft aren't likely to let them upload beta builds to the real XBox Live servers for testing. You simply have to build the package and pray you didn't mess up.

Modifié par Bibdy, 14 janvier 2010 - 08:05 .