While creating games is clearly a team effort that can rarely be attributed to any single person, the sad truth is that the average consumer is hardly aware of the developer--even as a company--much less any individual programmer or artist. The publisher is given nearly 100% credit for everything, while they are often responsible for little more than setting deadlines and putting the product on the shelves. If you asked an average consumer about "Microsoft's" games, how many people would be aware that Midtown Madness was actually written not by Microsoft but by Angel Studios (who also programmed Resident Evil 2 on the N64 for Capcom), that Motocross Madness was by Rainbow Studios (who programmed Tiger Woods PGA Tour Golf 2000 for EA Sports), and that Monster Truck Madness was by Terminal Reality (who also programmed Terminal Velocity for Apogee/3D Realms).

If the movie industry were run the same way as the game industry, this would be akin to saying Schindler's List was by Universal Pictures alone ...and giving Steven Spielberg little or no mention. As a result, this would bring with it the consumer expectation that Darkman II, also published by Universal Pictures, must be an excellent film of the same caliber. If games were books, Herman Melville's Moby Dick could be attributed to Signet Classics, Shakespear's MacBeth to Reissue Publishing, and F. Scott Fitzgerald's The Great Gatsby to Dimension. If games were music, the charts would be topped by Atlantic Records and Virgin Music, not by Kid Rock or Metallica. This is obviously absurd.

   Consumers use the names of movie producers, actors, book authors and musicians as their first cue as to whether or not they may be interested in a product. By obscuring this information, game publishers are blinding the consumers in an already confusing marketplace. Publishers justify this practice with the excuse that it protects them from individual developers asking for higher salaries because of "star talent". Or even the fear of having a hot property turn next to worthless overnight when the key staff move on to another project or company. It doesn't take a rocket scientist, however, to see how this practice favors publishers far more at the software store checkout counter than anywhere in the development process. How many gamers have ever felt angry and disappointed after shelling out big bucks for an inferior title they purchased only because other titles published by the same company were considered good? Or conversely, how many great titles by a fledgling developer have been overlooked because of a publisher's bad track record?

   Let's look at the example of what happened between 989 Studios and the development house SingleTrac. When SingleTrac parted ways with 989, new developers had to be found to update the existing code base on a number of games such as the Twisted Metal series. When these new games were released, some fans wrote them off specifically because they were not programmed by SingleTrac. Video game companies do not like this situation, and I have heard many a time, stories of companies who would like to strike all development credits from games. Fortunately this hasn't happened yet, but it is always a risk.

   Making the trail of accountability even more complicated are the situations were developers outsource programming from a smaller contractor, or even license technology outright from someone else entirely. Normally in these situations no reference is given in any way to the programmer who wrote that original piece of code.

   Then again, how about games that have multiple versions. For instance games that are reissued every year with new features--or in the case of many sports games, new stats. Even though a current release of a game may still have 70% of the code that appeared in the original release several years ago on a different platform. Now, ten versions later (and five or more development teams later), those authors no longer appear in the credits. Who really wrote the game? Sure the current developer may be listed, but sometimes they are only just contracted and sent last years code base with instructions on what they are supposed to add, and when it has to be done by. Can you imagine, a PlayStation 2 or Dreamcast game where most of the core program is actually code written to work on a 3DO or a Sega CD? Sadly, it's far more common than you would think or even suspect. Most of the EA Sports and 989 Studios sports games jump instantly to mind here. These days we are even seeing extremely old code from the PC world being migrated to the consoles, and visa-versa. Just think, single tasking X86 based program code being ported to a multi-processor, multi-tasking console architecture.

   This whole convoluted situation is reinforced and in fact rewarded by inadequate planning and/or development deadlines established by the publishers who contract these games. Developers frequently agree to insane deadlines from publishers, or even offer them when the deadline is the sinker in getting a contract. They don't do this just to because they need to get a paycheck. No, the reality is that frequently, if they don't take the work someone else will--even if that someone else can't finish the game by the requested deadline either. This isn't a problem specific to game development. In fact this is a problem that is common throughout the entire programming industry. Of course there are the exceptions of companies who always seem to meet there deadlines, but don't get confused, the exception is not the norm. Frequently, when deadlines are met, it is due to programmers working overly long hours, risking health and sanity to meet an arbitrary milestone just to keep their job or position.

   Some PC game publishers have even begun to accommodate the frequent arbitrary deadline problems by actually planning regular patch releases to fix bugs or add major features that didn't make it into the product by production time. There are numerous PC games that have three, five, or in some extreme cases, upwards of more than a dozen patches issued over their shelf-life.

   In cases where new features are added, this can provide added value to a title near the end of its life. But in the case of critical bug fixes, it commonly boils down to a situation where the company failed to properly test their product and has now relied on consumers to perform the final testing. Don't laugh, if you think this is bad just wait until we have regular internet connectivity for consoles. Publishers want to move eventually to a "pay per play" formula for their games. Not just to boost revenue, but to "help eliminate" the need for high-profile bug fixes and reduce testing costs. This can also allow them to physically retire a title from publication at any time, never to been seen again if they so wish. Or for that matter, instantly strike objectionable "easter eggs" from a game. Can you imagine never being able to go back and play a favorite game... especially one that wasn't a mainstream hit or had censored/questionable content? With the coming advent of broadband internet access, this day will be here sooner than you think.

   The fact is, the current model for deadlines frequently reduces the amount of creative time available to many developers. No, I'm not saying that developers need to be given carte blanche time to get a game done. But situations like this do tend to cause the management at a development house to stipulate their developers use pre-licensed/pre-existing code when the programmer(s) may have been better off writing something from scratch. The programmer listed is then frequently only the person who re-purposed the code to its new life and not the person or persons who coded the original program.

   An amusing real-life reference to this common situation of reusing existing code is a quote from an article by Joe Sislow entitled "Hollywood Logic: Sequels and Licenses"(3), where he states that:

"First off, it's plain unfair to merely release a game with the exact same engine. New graphics, new level maps, and new sounds do not constitute a sequel. Such a change should be labeled an expansion pack. If you think I'm lying about trying to do this, I'd like to relate a quote I heard at E3 a few years ago, "We used to call it, 'slapping new make-up on the whore and sending her back out.'" Due to the nature of the quote, I hope you'll understand why I can't reveal the source. However, I used the quote to illustrate how large software publishers perceived sequels. I'd like to fight this philosophy to my dying breath."

   Unfortunately that article was written in August of 1998, and Mr. Sislow appears to be fighting a loosing battle these days. Just take a look at many of the "big-name" games from the Christmas 1999 market for the PlayStation and PC. The only hope for the future currently stands with Sony's recently announced efforts to prod third-party PlayStation 2 developers into taking more creative risks with their forth-coming titles. How this will pan out remains to be seen though.

   Now this isn't to say that many people within the industry aren't aware of these problems. The fact is that there are many who know about it but "preach to the converted" about fixing the problem. Publications such as Game Developer, or it's sister online publication of Gamasutra present countless articles where these problems are discussed and lamented to great extremes (see Game Developer, "Soapbox: It's Ready When it Ships"(4) for one of many examples).