Call of Duty - The Lawsuit

Gamasutra is running a follow-up to their annotated contract piece from last month. As you may recall, the contract became public knowledge because of a court case between Spark unlimited and Activision regarding the title Call of Duty : Finest Hour. The article also covers a legal dispute between Spark/Activision and EA during the formation of the troubled development house. Now, the site is running an in-depth look at their legal dispute. The article explores some of the problems that can face any developer/publisher relationship, and how the legal case has affected that already strained situation. "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.'"

In regards to the quote in the summary...

[Wilson_6500]

EA's method causes the game to get released without the polish, period. If any shows up, it comes in patches later on, most of which we will probably have to buy in the future.

Activision's method causes stress on the designers, and perhaps contributes to an "anything for 30" mentality--consoles don't have adjustable system parameters, so those who're designing for a console must sacrifice everything and anything to get the magic FPS number. This is only a problem if the game is developed _for_ consoles to be ported to PC, or developed concurrently with the PC version--because then the PC version will be hamstrung for the sake of the console version. If you're going to release to the PC crowd, do it right: these people have computing power and can generally get more if they need it--or can turn down some options if they don't want it.

Re:Agile Game Development

[mypalmike]

Back before I 'burnt out', the good games I worked on usually followed the pattern you describe. The bad ones usually did not. Depending primarily on budget, game levels were either cranked out and quickly QA-ed (to make sure the level could be completed without crashing) before shipping, or several iterations of real playtesting were used to hone the levels from rough prototypes to finely detailed crafts. In most cases, only a couple of major iterations were needed, with many smaller ones.

I recall one game that almost ended up a total failure. About two weeks before we went gold, 75% of the levels were just plain bad. QA had been so focused on tracking down bugs that little time was put to deciding what was "fun". The lead programmer put his foot down and made everyone on the team (programmers, artists, etc.) just play the game for a couple days to provide gameplay feedback. Within a week, the level design changes from that feedback helped the game become something we could be proud of, and it ended up being fairly successful. In game development, it is sometimes possible to polish a turd.