Train Wrecks!

Team principals from three of history’s biggest game disasters brush off the dust and live to tell the tale

Benjamin E. Sones


This article originally appeared in Computer Games Magazine #150

You always remember your favorite games. You remember the music, the menu screens, and perhaps even the loading graphics. You probably have stories you could tell about one game session or another, if only you could find someone willing to listen. When it comes to bad games, however, the only thing that you tend to remember is how quickly you deleted them off your hard drive.

For the average person, bad games are easy to forget. For the people that poured years of sweat and personal effort into creating these games, the experience is slightly tougher to shrug off. Nobody wants to make a bad game, just as nobody wants to drive a train off the edge of a cliff. But sometimes even the most promising games depart the rails, and every time it happens, a team of hapless developers goes along for the ride. Sometimes they even survive the experience.

This is not an exposé or an investigative report on the gaming industry. The games contained herein are relics. The reviews are in, the public has reacted, the fat lady has sung. This is merely a new perspective, a glimpse of what the scenery might look like from inside the train. This is a story about what developers do when they realize that the engineer is dead, the brakes have failed, and the bridge around the next bend lies in shambles in the river below.

Lost in Space
If you have never heard of Battlecruiser 3000 AD or Derek Smart, you are probably new to gaming. The latter is the designer of the former, an intricate space simulation released in a practically non-functional state in 1996 after seven years of development. It holds the dubious honor of sparking one of the longest running flame wars in Usenet history. It was as wildly ambitious as it was broken, offering a complex simulation of military space combat on multiple levels—from capital ship warfare to fighter combat to planetary battles—in a fully dynamic universe. The product that publisher Take 2 shipped also came with a few unadvertised goodies: an inadequate pamphlet-sized manual, terrible AI, missing features, broken controls, and alarmingly numerous crash bugs.

For most of its development, it was a one-man show. “I started thinking about how great it would be to roll up all the features of the games I liked into one game,” says Smart. He had no training in game design, but started working on his idea anyway, just for fun. “I decided to go commercial when I realized that people were actually being paid, I mean, like with real money and stuff, to do this.”
The process was not that simple, however, as Smart soon discovered. Notoriously outspoken, he’s frank about his project’s failings. “I had a lack of direction, ignorance, inexperience, far too much control, and a blatant disregard for how games were actually made,” he admits. He had only vague plans for how his game would work, and no design document. The fact that Smart was working alone—and learning several new disciplines on the job—did not help. “I ran into a lot of problems—primarily because I couldn’t code my way out of a paper bag, let alone a function call,” he says. “The fact that I had zero 3D knowledge was also a hindrance. I had to learn all that as I literally plodded along.”

He learned the skills that he needed with the help of some friends from various technical backgrounds, but by then he was having trouble with another aspect of commercial game development. Smart moved from publisher to publisher, trying to find a good fit for his project, but personality clashes and conflicting goals created friction wherever he went. Smart cared about little beyond the design of his game. He had made significant personal sacrifices for the sake of his project, which displaced a lucrative consulting contract, a regular paycheck, and ultimately his marriage (which ended in divorce). With so much invested, he was unwilling to share the reigns.

“I insisted on working from my rented apartment and barely went to the office, except for meetings and the like,” he says. “I wasn’t up there to make friends. I was up there to get my game done and released. I figured that it was still my game and like me or not they had no choice but to do things my way.”

His publishers were more concerned with matters of business. Production schedules are not one of the fun aspects of game design, but they are an unavoidable reality of the industry, and designers disregard them at their own peril.

Smart had spent seven years working on the game, and eventually his final publisher, Take 2, ran out of patience. It decided to ship the product and let the chips fall where they may. Smart was furious. “When publishers put their minds to doing something as foolish as shipping a game in beta—which they still do—they’re just going to do it.” With a few years to reflect on the matter and better understand the industry he works in, however, he has also come to understand the other side of the picture. “By the same token, if a publisher has targeted a specific period to release a game and that game is not ready, it is up to them to do what they want to do,” he says.

Smart survived the experience, and continues to develop new games based on the Battlecruiser concept. He works differently today, however, with more respect for careful planning and attainable design goals. “When I was designing Battlecruiser Millennium, I had a clear goal and was focused on that,” he says. “I had no intentions of jamming everything in that title. Instead, I decided to bite off what I knew I could chew, and in twenty months I had a title out on the shelf.” He has also come to understand the value of working as a part of a team. “Listen to people who have experience and know what they’re doing and talking about,” he says. “Too many of us in this field think that we have all the answers. We don’t.”

Descent into Hell
Steve Perrin was one of four designers on Interplay’s ill-fated first-person role-playing game Descent to Undermountain. “Or perhaps three and a half would be more accurate,” he amends. “Scott Bennie was working on some other projects at the time. I designed levels, wrote dialogue, and helped come up with the more intricate master plot based on other people’s original ideas.” Perrin came late to the project in July of 1995. The initial artwork was complete and the team was starting to build the levels, which employed sci-fi shooter Descent’s vertigo-inducing 3D engine. “The original concept was something that would be done by December of 1995,” Perrin says, “because after all, the engine was already there. We just had to make the characters walk.”

However, making the characters walk was a task that the team would not accomplish in 1995… or in 1996, or in 1997. In fact, when the game finally arrived in stores early in 1998, characters still had an alarming tendency to ignore the laws of gravity and hover in space. This, unfortunately, was the least of the game’s problems.

“The key pitfall was trying to turn a flying shooter into a walking shooter without planning on a lot of new code,” explains Perrin, “or perhaps even starting all over.” The main problem was a lack of gravity, something that was not an issue for Descent, which featured gravity-free environments with six degrees of freedom. Perrin believes Descent to Undermountain should have used a more conventional licensed engine, or completely new technology. “Making critters and characters stick to the floor, and making sure it was the same floor for everyone, was one of the big, big problems of the game,” says Perrin. “It screwed us up for months.”

Exacerbating the situation was an ill-conceived team that did not include a Producer (“that didn’t work,” says Perrin) and that gave the title of Lead Programmer to an inexperienced coder with little interest in fantasy. “Once we got some decent programming in, all of a sudden it was possible to do everything he said was impossible,” says Perrin. “But we blew about ten months first trying to deal with that programmer, then unraveling his code into something usable.” Even Perrin felt out of place. “I was really a mismatch for the game,” he admits. “I am not a big fan of that kind of shooter. In theory, I was brought in as a trap guy, but I hate traps and suck at them.”

It may seem odd to say that a project running three years overdue was released too soon, but all the technical problems, design changes, and a revolving door of talent resulted in a game that was still very much unfinished when released in 1998. The final game was rife with crash bugs, broken scripts, and featured an aging engine that still was unsuited to the task. “It could probably have used more time,” says Perrin. “At the same time, this means that a game that was planned and budgeted to be done in less than a year took three-plus years to finish. Hardly a record for the computer game industry—and especially Interplay—but situations like that are why Interplay is in the position it is in now.”

Perrin himself passed through the revolving door before the completion of the project, and in August of 1997, he left Interplay altogether. “I haven’t even seen the finished game,” he says. But according to Perrin, the game was past saving. “I think the basic concept was flawed,” he says, “and needed a firm direction, which it didn’t get until entirely too late.”

“Now if there is a silver lining to the whole thing, it is that the team was eventually able to fix most of people’s issues with the product except for the graphics, and Interplay learned a good lesson,” says current Black Isle Studios President Feargus Urquhart. “It taught us that even if a product is 99.9% done, or rather 99.9% shippable—‘done’ and ‘shippable’ are two different things—that we should not hesitate to kill it if is not a good product.”

What did Perrin get out of the experience? “I still have dreams about constructing levels….”

Riding the Hype Machine
“Time is not on your side.” That was the tagline for Daikatana, the flagship title at breakaway company ION Storm, founded in 1996 by id alumni John Romero and Tom Hall. As with many disastrous game projects, time was not on the development team’s side, either. Originally scheduled to ship by the end of 1997, the project languished through a variety of setbacks until publisher Eidos finally ushered it out the door in June of 2000… complete with a quote on the box declaring it the “Best Game of 1999” (the boxes had apparently been printed in anticipation of an earlier release). Unlike many train wrecks, Daikatana mostly functioned as intended. But the design lacked focus and direction, and boasted a dizzying array of annoying mechanics and poor choices. Coming from a developer that had adopted the cocky slogan “Design is Law” and a loud public attitude to match, it was an ironic anti-climax.

Shawn Green joined the team in 1997, working at first to add features to the game’s rendering tool, and later graduating to the role of Lead Engineer. He came to the project with plenty of optimism. “Having worked with John Romero in the past and seeing what was planned for Daikatana, I was convinced that it would be a great title,” he says.

As the project continued, Green started to see thunderclouds on the horizon. “It was more of a collection of problems,” he explains, who felt that the team could have used more industry veterans. “Out of the numerous people that worked on Daikatana, very few of those people had actually ever worked in their field professionally… some had never even had a job before.” To make matters worse, team members (Green included) made little effort to coordinate their work with the rest of the team. “The most important asset any project can have is good communication between its team members,” he explains. “If there was only one thing I could have done differently while working on Daikatana, it would have been to improve my communication skills, and encourage those around me to do the same.”

While the project was meandering aimlessly, the company executives and PR representatives were busy telling the public to expect the Next Coming of the True Messiah. “John Romero is going to make you his bitch,” proclaimed one particularly memorable advertisement that ran in 1997. Trash talk is a two-edged sword, however. It builds anticipation, but it also builds expectations. “If you give the public the impression that you’re going to create the next best thing,” says Green, “you create an immense amount of pressure to deliver exactly that.”

A storm had been building at Storm’s Dallas offices, however, and in November of 1998 it erupted. Personality clashes, management issues, and general unhappiness among team members led to a mass defection. Over three-quarters of the core team, according to Green, walked off the project and out of ION Storm. The remaining people faced the unenviable task of rebuilding the team and salvaging the project. “In addition to our daily tasks, we now had to find new members for the team and get them ramped up,” says Green, who was quickly promoted to Lead Programmer. “The first task I assigned myself was to evaluate the current state of the game from a coding perspective and find out what shape we were in. At that point, most of the work that had already been done was either completely broken or unusable. That did wonders for my optimism.”

The next year and a half was a difficult time for Green, who had lost much of his enthusiasm for the project. “I was totally burnt out,” he says. “The two things that kept me there were the fact that I always finish what I start and the fact that, more than my boss, John Romero was my friend, and I felt Daikatana deserved a chance to see the light of day.”

After the game’s release, ION Storm’s Dallas branch was living on borrowed time. Green eventually moved on to join Gearbox software, where he was the Lead Engine Programmer on Tony Hawk’s Pro Skater 3. He has not forgotten his time at ION Storm, however, and in spite of all the grief that it inspired, he does not hate Daikatana. “I don’t think it deserved a bad rap,” he says. “I’ve played much worse games.”

He is right, of course—the other games in this article, for example. So why was John Romero’s game so passionately vilified? Green does not hesitate. “It was an easier target for criticism because of the hype.”

Out of the Wreckage
When you discover that you have just spent your hard-earned money on a terrible game, it is easy to pin the blame on all the faceless developers listed in the back of the manual. Certainly, that is where at least part of the blame belongs, and few of them will deny it. As you sit and watch the uninstall progress bar crawl across your screen, however, just remember that it could be worse. You lost $50 to that game. Somewhere in the world, someone else lost years of his or her life to it.

When games go bad, everyone loses.

Counting the Casualties
Battlecruiser, Descent to Undermountain, and Daikatana are certainly not even close to alone when it comes to listing the bad games that have made it to store shelves despite their unfortunate circumstances. Here are a few more.

Some call this the most notorious train wreck of all time, and the most disappointing game that the PC has ever seen. Outpost promised us the world, a promise backed by the solid reputation of its publisher, Sierra, and hyped by mainstream publications such as Popular Science and Omni. That world was a dismal, empty place, however, full of terrible game mechanics and broken or missing features.

Ultima Online
The first of the mainstream online role-playing games, Ultima Online was a disaster at launch. Wildly unbalanced game mechanics, lag, crashes, and other various bugs helped make it one of the most disappointing launches of 1997. Years of post-release patching eventually helped it live up to its potential, however, although its sequel died in the water.

Ultima IX: Ascension
This game from the now-defunct Origin boasted a strong design and insurmountable technical problems. Memory leaks, bugs, and a framerate that hovered below 10 frames per second on any non-3dfx video card spelled doom for this otherwise enjoyable game… and ultimately for the entire Ultima series.

World War II Online: Blitzkrieg
Promising to dynamically to recreate the expanse of World War II in Europe, this online game suffered from poor design choices and at launch, it was a serious case of “everything’s broken.”. Still active as of this writing, the developer (Cornered Rat Software) has been slowly chipping away at the problems for over a year.

This article originally appeared in Computer Games Magazine #150