But my question is why didn't they just use the same tool they used for Dragon Age? I understand that they changed it but it doesn't really say why. The one they used for that game was fine, or at least the final product they made using that tool was.
Changing tools isn't as simple as it sounds (time to put on my Software Developer hat!)
Although the article doesn't explicitly say it, my guess is that DA:I and ME:A were run by completely different teams and therefore could not easily share work or toolsets. Also, when the 3rd party tools were selected, they were staffed accordingly, so DA:I hired people for their tool and ME:A hired people for theirs. They probably weren't using the same technology, so to implement the DA:I tool into ME:A would have a cost of either retraining the staff or possibly hiring new ones, which would cause significant delays. There's also the high probability that the tools were not compatible, so then you'd have days/weeks/months of work completely lost. In addition, even though both games were built on Frostbyte you have to remember that they used various additional tools/engines as well, and there's a good chance that ME:A and DA:I didn't use all the same ones. So it wasn't as simple as putting pieces into a puzzle. With so many interconnecting parts and code written to comply with each one's specifications, code was likely not easily transferable, and implementation of one's 3rd party engine into another could break numerous things.
I HIGHLY recommend you check out this video by Extra Credits that explains the issues that can pop up during software development that cause unfinished games to be shipped out.
And it's not just technology issues either, but decisions made by upper management. As is shown in this article, the management aspect of ME:A was very hurtful. There were constant scope changes and disagreements with other teams as well as numerous people leaving. Staff turnover can be DEVASTATING in software development, especially if you don't have a proper documentation system in place. It should also be mentioned that this was by far the greatest project that this studio had ever embarked on, so they weren't prepared for such an undertaking. This was compounded even more by the difficulty in programming in the Frostbyte engine.
Finally, if we are to believe the stories that the main development was crammed into 18 months, then regardless of the engines used and staff sized, this was not going to turn out well. When you're still doing active development close to a deadline, it rarely turns out looking the way that the developers wanted. I'm in a similar situation myself right now. I have a project that had a deadline of 6/16 originally (well not ORIGINALLY, but most recently.) Then on 6/2 I discovered that about 3/4th of the code I had written was no good anymore because the data access component had to be COMPLETELY rewritten because of an unforeseen issue with a 3rd party tool we were using. So all the effort I had put into that was now completely blown and I had to quickly re-write stuff just to get it done. With the new data access component came new issues with trying to get it to work with my existing code base, and then late yesterday I was told that the due date had been moved up to EOD 6/8 because the business screwed up or something. So now I have more sh*t to do and less time than anticipated to do it in. Normally when I am near a deadline I plan to have my code completely written a few days in advance so I can do lots of bug testing as well as do as much code cleanup and optimizing as possible. But now that I need to work my ass off to get this deadline, it's not going to be properly tested and QAed so it is going to be more prone to errors. However, this crap isn't because I was a bad developer, but because management made stupid decisions that I am stuck with and the business people (Read: NOT DEVELOPERS) have set high expectations while constantly changing requirements for the work that needs to be done, coupled along with the various bugs and crap you discover during the course of regular development. This crap happens ALL THE TIME in the world of software development, and what I work on isn't even half as complex as what these game developers deal with. I can't even begin to fathom the levels of complexity associated with AAA game development.
Hope that gives a bit of better understanding as to why there were such differences in the final results of ME:A versus DA:I
