Know Your History: Trespasser

by Darius Kazemi on January 7, 2007

in know_your_history,management

I was reading a post today on Tales of the Rampant Coyote which happened to link to a review of Trespasser–one of the most interesting case studies in game development of the last ten years.

Never heard of the game? Well, Gamasutra has a great postmortem of the game, which is a fantastic review of what not to do with your ambitious project.

A few thoughts occur on reading the postmortem for the second time (I read it for the first time about 4 years ago in the excellent Postmortems From Game Developer book, coincidentally edited by Austin Grossman, who is credited as the lead designer on Trespasser).

“[T]hough we would only have a few different types of dinosaurs, the dinosaur AI system would allow them to react to each other and the player in a large variety of ways, choosing appropriate responses depending on their emotional state. Sophisticated, fully-interruptable scenes would occur spontaneously rather than requiring large amounts of scripting, and observing the food chain in action would be as absorbing as playing the game itself.”

Hmmm… sounds exactly like what Bioshock is planning to do. Except, having seen the gameplay videos, I’m pretty sure Bioshock will pull it off. Of course, this is with all the lessons from previous attempts like Trespasser as well as a ton of technology that we did not have in 1998.

“Many of Trespasser’s artists had never worked on games or done 3D modeling before, and some had never even used computers at all. This was a fairly deliberate decision, in an attempt to achieve a much higher standard of art than we were used to seeing on previous products.”

Anyone care to explain this statement to me? I’m guessing that they assumed “traditional” artists would do better art than career games artists? Maybe this was more true back in the mid 1990s, I don’t know, but it certainly isn’t true now.

“The biggest indication that Trespasser had game design problems was the fact that it never had a proper design spec. For a long time, the only documents which described the gameplay were a prose-based walkthrough [...] and a short design proposal [...] These documents were created before any playable technology existed and were based on promises of how that technology was supposed to work.”

Ahhh. See, this project was developer using the waterfall method. If waterfall is going to work, you need detailed specs. The lack of specs wouldn’t have been a problem had it been a highly iterative, prototype-based project, but alas, this was not the case!

“The largest problem with the AI system was that its progress was blocked by a lack of dinosaurs with which to test it. The first time a dinosaur made the transition from a separate test app into the game was in early 1998 [...]“

What?! Let me catch my breath here.

Okay. The game shipped in late 1998. Which means that they didn’t have a single dinosaur in their dinosaur game until mere months before shipping. Wow. Just wow. And, surprise surprise, when they put the dinos in, they realized that the AI system they had designed for the dinos wasn’t going to work.

One again, this is why it’s important to have your game playable (with draft versions of all systems in place) as early as possible in the production process.


solipsistnation January 7, 2007 at 10:10 pm

Yeah, I think they wanted to have “real artists” working on the art assets rather than artists who got art jobs through game design and who were often primarily programmers. I think you’re right that while this was a good idea in 1997 or 1998, it’s no longer the case now.

kentquirk January 11, 2007 at 4:10 pm

You say “If waterfall is going to work, you need detailed specs.” I’d argue that for any project requiring multiple developers, it’s impossible to write down specs in advance that are detailed enough for waterfall to work. The entire presumption of the waterfall method is that you’re smart enough to write everything down in advance and know how long it will take. But software is a creative process, with even small projects requiring thousands of micro-decisions along the way. All of those decisions interact and cause uncertainty.

Using waterfall for writing software is about as sensible as using it for writing a novel.

Comments on this entry are closed.

Previous post:

Next post: