     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
“It was becoming painfully clear that the choice of using RenderWare as a foundational part of Spark’s production process was going to present significant challenges to finishing the project. The architecture of the software was not scaling to handle the complex demands of the game,” Allen wrote. “The results were instability, lost work, slow production pipelines and a ‘just live with it’ attitude.” According to a Spark programmer quoted in the postmortem, “The tool chain implemented at Spark is the greatest factor in the slowness of development. I have often seen cases where getting an asset change in the game takes up to a week. Part of the reason revolves around the use of RenderWare Studio, but part of it was created at Spark.” The programmer went on to say, “When something goes wrong in the game, we don’t know if it’s an error in Maya, the export tool, the update latest tool, the import, or a bug in the code base, and it takes often days to figure that out.” Allen described it as, “One of the most painful and absurd production systems ever used to create a game.” Spark’s disorganized management only exacerbated the problem as Allen frankly admitted. “The executive management team at Spark shoulders a great deal of responsibility for not insisting on more effective results,” he wrote. “We suffered because of poor scheduling, prioritization, and an imperfect definition of the work to be done.” Allen described a management team crippled by a “general predilection for debate over top-down decision making.”
According to Allen, the root of the problem was embedded in Spark’s origins at EA. “For some of us, Spark was a new company.” he wrote. “For others, Spark was a continuation of Electronic Arts Los Angeles and DreamWorks Interactive. Same people, same content, same issues, new building, new business card - but production as usual.” As well, Allen observed a “significant chasm between how the Spark team was used to working under the Electronic Arts methodology, and what Activision expected.” A constant source of friction was Activision’s desire to see a fully functioning game early in the development process. “At Electronic Arts”, he wrote, “the level vision was able to be constructed without the constraints of frame rate, or memory to get the body of the game in and working,” a process which left polish until the end of the development cycle. “However, under the more risk-averse Activision system, polish happens through the entirety of the process and there is a consistent desire to have the game playable on disc and running at 30 fps.” By January of 2004, Spark could demonstrate only one working level of a game that was intended to have fifteen and it seemed unlikely that Call of Duty: Finest Hour would meet its scheduled ship date of June. Allen wrote, “There was a general lack of documentation or organization around who had done what to the code base. It became clear that there was going to be a lot more work needed to be done to stabilize the system than anyone had expected.” |
|||||||||||||||
Previous
|
|
|