Things that went right

Some have dismissed Trespasser altogether because it was such a visible failure. Respected columnists and editors use it as a reason why physics is bad, or make it the butt of their jokes ("at least it wasn’t as bad as Trespasser!"). However, from a project perspective there were a number of successes. Before we get into the problems which ended up sinking the ship, let’s look at these successes.

1. Use of license

From my own perspective as a designer, licensed properties are the least fun games to work on. Even Star Wars, perhaps the only movie license just about any game maker might donate a limb to be allowed to use, brings with it a huge amount of restrictions which can make that initially attractive license turn into a lead weight over the course of development. From a game player’s perspective, the vast majority of games with movie licenses have been just plain awful. And finally, from a movie aesthete’s view, the Jurassic Park movies are among Spielberg’s (and original novelist Crichton’s) worst work, lacking in just about anything beyond pacing and special effects.

However, Trespasser’s Hammond diary actually contains lots of interesting tidbits about the early days of characters like Henry Wu (the scientist from the beginning of the first movie) and even Dennis Nedry (Wayne Knight’s character who basically caused the first disaster). The player can also check out locations on the island which imply back story which isn’t explicitly told, like Henry Wu’s house with its 80’s executive bachelor stylings, Nedry’s office with its poster for the fictional computer game series "Swords of Kandar," and Hammond’s lavish mansion. The settings and the diary itself serve to reveal much of Hammond’s motivation and personal reactions to the building of Jurassic Park, creating more of a character than exists in either the books or the movies (Crichton killed Hammond off in the first book, anyway).

The overall plot of our game is as simplistic as most others (Character finds way to escape death trap), but the details revealed about the Jurassic Park world extend it in a way which is faithful to the originals. Although it is quite likely that the next Jurassic Park movie to be released will make Trespasser non-canon, for now it stands as the only real extension of the series published. If there are such things as Jurassic Park fanatics and they were able to look past the gameplay flaws, they hopefully enjoyed our development of the world.

2. Art and music

On an individual basis the models created for Trespasser rank with the best-looking work done for computer games. We limited the largest texture size to 256x256 pixels, and at model import time textures were converted to 8-bit paletted images, but artists worked with their models using 24-bit art in 3D Studio Max, applying the textures using any mapping methods that Max supported. We had the standard limits on visible polygons, so most models were made with as few polygons as possible, with dinosaurs ranging from 300-500 and trees from 50-120 for example, but this still gave our artists more complexity than was standard at the time.

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. The number and resolution of textures we were able to support called for painting skills far beyond the average game-trained artist.

The music is one of Trespasser’s best accomplishments. Trespasser was not able to use the Jurassic Park license for free, despite Spielberg being a principal of our parent company, DreamWorks. A large chunk of our budget went just for that license, yet that money bought little more than the ability to use the name, locale and set designs from Lost World. Everything else that a reasonable person would assume would be part of a licensing deal, such as the amazing ILM dinosaur sound effects and the John Williams theme, would cost extra. Luckily, our sound effects were being done by professional effects company SounDelux, and they put us in touch with one of their stable of composers who specialized in "imitation" music. With very little prompting, he recorded about 30 minutes of music for us which in some parts far exceeds the rather forgettable work Williams himself did for the Jurassic Park movies.

Some reviews still accused us of having spotty or inappropriate music, but this was more an implementation problem than a problem with the music itself. The music was recorded as a couple dozen short sections which were scattered through the world on location-based triggers. Much like the voiceovers, more attention could have been paid to their placement so that they only played at appropriate and regular intervals. Even more desirable would have been a system with the ability to play tension or combat music loops and fade them in and out of the special-event songs to make it seem more like a continual musical score.

Trespasser screen shot [zoom]	Velociraptor read to pounce [zoom]

3. Innovative systems

Our artists were able to paint textures with near-total disregard to common memory-conservation practices thanks to the texture caching system which was created fairly late in the project by one of the last programmers to be hired.

Textures for our game were MIP-mapped by our helper application as part of the process of building level data (curved bump maps were also created at this time). A level could have a nearly-unlimited amount of textures, and once MIP levels were created, all textures and their MIPs were saved into a single swap file. The app automatically organized the swap files into pages based on texture size, with the lowest couple of MIP levels for all textures on a set of pages which were always committed.

As the player moved through the level and objects came into view, the appropriate pages from the swap file would be accessed. In any circumstances where an appropriate texture hadn’t been loaded in yet, the always-committed MIPs could be used until the higher-resolution texture had been loaded. In theory, this could result in a frame or two where an object was textured at a lower resolution than desired, but in practice it rarely happened, even on the most texture-intensive levels.

Another major system for Trespasser was its audio system, which we described as "real time Foley" because of its ability to generate collision and scraping effects between differing sound materials in real time. Although the system could have used more sound material data, even with what it had it resulted in some wonderfully immersive sound effects which most other games do not duplicate - things like scraping a board down a concrete surface or hitting an oil barrel with a metal bat sound just about perfect. Since the system doesn’t simply play two sound effects but actually chooses from a group of samples and sets volumes based on the underlying physics collision, it sounds much more natural than most other audio systems currently used.

Finally, our image caching system, which rendered groups of distant objects into single 2D bitmaps to speed rendering, while responsible for the most-disturbing visual anomalies in the game, was also by its own right an amazing piece of work. Image caching made it possible to render scenes with tens of thousands of polygons in near-real time, and it is the first technology which allowed outdoor scenes to have a reasonable fraction of the complexity of the real outdoors.

4. Outdoor level design

When we created our terrain geometry, we were deliberately trying to avoid the "marbles in rubber" look of a lot of bad fractally-generated outdoors terrain. To this end, we decided that we needed to base our island on real-world terrain rather than build it from scratch. Luckily, we had a real-world model to go from: Costa Rica’s Isla Sorna, the same island Crichton used as his inspiration for Site B. Unfortunately, no relief maps of sufficient detail existed for Isla Sorna, so we ended up having our lead artist sculpt a large model of the island, had it laser scanned, and did all our work on it in 3D Studio Max.

Outdoor levels are a hall mark of Trespasser [zoom]

The hope was that the scanned model would provide enough fine detail of the island that we could approach it as if we were InGen’s engineers and simply "bulldoze" a few roads and building sites into it. As it turned out the scanned model was only useful to set the rough contours for each area, and gameplay-relevant detail such as sight- and movement-blocking hills was largely hand-built. However, having an idea of where all the ridges in the island lay gave clear direction in the level-design sessions for how the gameplay would flow and what would happen in each area. The scanned model also provided continuously rolling terrain rather than a flat base with mountains sticking out of it (as hand-built outdoors areas tend to resemble). The number of slopes did increase difficulty of modeling the gameplay areas, but it was a worthwhile tradeoff for a natural feel.

Modeling was only the first step on a level: after the terrain was mostly established, there was a significant time investment in populating the levels with objects. A typical level consisted of 10 - 15,000 trees, shrubs and rocks, and a few thousand man-made objects as well. Every object could be placed individually, but for time-saving reasons we generally used groups of objects for areas off the game path and only spent a lot of time hand-placing items in places we knew the player wouldfrequent.. The rolling terrain and a random-delete tool we often ran for optimization generally kept the repetition from seeming obvious.

In the end, though our levels didn’t quite fulfill our personal expectations, they usually look more like real environments than previous games. Starting from real terrain seemed to be the most useful tactic for this, and creating a natural algorithmfor vegetation placement is the next obvious step for outdoor games.

5. Realistic physics in first person

The first discovery we made as our physics simulation was slowly implemented was that it was an engrossing toy. When we finally got support for compound object physics (so that a bench could consist of a top and two legs instead of a single block, for instance), it was possible to spend an hour just dropping the bench onto things to see how it would catch on edges and flip and slide around. Toys do not make games, however, and trying to establish a gameplay which would work with the simulation was our major challenge.

Due to the vagaries of our particular physics simulation and interface, we eventually arrived on gameplay that primarily involved knocking things over rather than stacking things up. Knocking over will probably be the first application of realistic physics to see wide-spread use, as it will work even with a less-than perfect physics model such as Trespasser’s. It is also a behavior which easily shows off the difference between realistic physics and what we usually referred to as "fake" physics - compare pushing a box off a ledge or hill in any game which actually lets you move boxes to the same action in Trespasser.

Since our gameplay was supposed to revolve around the physics, however, we needed to apply that knocking-over behavior in slightly more sophisticated ways than just using it as eye candy. The best uses that we found in the small amount of time we had involved knocking stacks of boxes down to fill holes, or unbalancing something resting on a high ledge in order to get it or use it as a step. It also quickly became apparent that building even a simple-seeming knocking-down puzzle required a much more highly refined sense of physical laws than is common, and many designers ended up with a collection of blocks and small boxes to aid in brainstorming puzzles.

We had originally intended to have much more interesting physical challenges for the player consisting of making stacks and bridges to cross gaps or reach high players. Due to the problems with the physics engine, we ended up cutting nearly every puzzle which depended on this behavior, as it was too difficult and unreliable to actually make stacks. However, as it seems like such an obvious thing to do (and was so central to the design at one point), many players still try to make stacks, and come away from the game extremely frustrated. In different circumstances this constructive gameplay should be even more interesting than the purely destructive gameplay of knocking things over, and making it work ought to be one of the foremost goals of post-Trespasser physics engines.