Slashdot Mirror
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.'"
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.
That's just getting the studio off the ground. At this juncture, I feel bad for Spark and angry with EA ('course, who needs much reason these days to be angry @EA). Also, Activision is acting cool (or protecting their investment) and helping bail them out of trouble.
Ok
WTF is wrong with these guys? I can't stand most publishers (EA or Activision), but this little dev studio that could who was plagued by drama (and got bailed out, pretty clean to boot) decides to bite the hand that fed em? I say let em' burn (unless this isn't the WHOLE story)
Way back in the day (when I was a game developer, before I 'burnt out') I used to argue that it would make more sense to build a rough prototype of every level in the game (using assets that wouldn't even look good for a Playstation game) and then to work in short iterations to improve the overall quality of the game. I argued that, although early versions of the game would not be useful for public consumption, the overall quality of the game should be better in the end ...
I don't know if I was correct, but I have been hearing that the basic principles of my idea are being used by more and more development houses because it allows for far more parallel development (meaning you can have a larger team rather than a longer development cycle).
Thats the way I used to develop and write software - identify and solve the hardest problems first, then go to town on the rest of the project. For game programming this would mean getting the AI to work first with placeholder graphics, then work on improving the visual effects and gameplay.
Unfortunately, this philosophy has the risk of being abused by management who try and pigeonhole you into solving hard problems all the time ('we thought you were happy') and giving the interesting work to their mates. Since everyone is also thinking about what they are going to be doing on the next project, this usually means the visual effects get done first and the gameplay/AI is left to the last minute.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
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.
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.