Things that went wrong

It might seem like Trespasser deserves more entries in its "what went wrong" section than the usual project postmortem. However, Trespasser’s failings are actually numerically few. Unfortunately, the failings that we did have were serious enough to more than outweigh the successes we made.

1. Software-oriented renderer

Trespasser was begun before the 3dfx Voodoo 1 started the wave of 3D hardware popularity. As such, the Trespasser engineers set about to create an engine in the old-school manner: they picked some previously-unseen rendering technologies and implemented them, ignoring any issues of compatibility with hardware cards. Our engine’s two most incompatible features were its bump mapping, a true geometrical algorithm which could take surface curvature into account, and its image caching. Image caching was intended to allow real-time rendering of huge numbers of meshes, but it was also the system almost solely responsible for the graphical anomalies of popping, snapping trees. The other primary visual artifact of the game was the frequent sorting errors, but this was a result of poorly-constructed levels which continually handed our depth sort algorithm more polygons than its limit, and not a direct result of image caching itself.

The image cache system worked by rendering distant objects into 2D bitmaps on the fly, updating them when the angle or distance changed enough that the 2D representation was no longer sufficiently accurate. This may sound familiar to those who remember Microsoft’s Talisman architecture, and there was a hope at one time that our game would be a killer app for Talisman accelerators, but resistance from key figures in the industry and 3dfx’s sudden popularity pretty much put the end to Talisman.

Trespasser ended up slipping by more than a year, as did many games of its time. Our hardware programmer put in a valiant effort in the last half year of the project, and managed to get much more use out of 3D hardware than we initially thought possible. We ended up with a fairly unique mixed-mode renderer which drew any bump-mapped objects in software and the rest of the scene with hardware. Unfortunately, the large number of bump-mapped objects present in any scene of our game, such as all the dinosaurs and nearly every crate, meant that the fill rate advantages of accelerators were often negated.

Even in hardware-only scenes, PCI cards like the popular Voodoo2 became easily bogged down by the sheer amount of textures Trespasser uploaded as image caches were updated and the texture cache system loaded in higher mip-levels. This was simply too much, and acceptable hardware performance was often only possible by using textures that were less-detailed than in the software version, a unique situation but not surprising given the software origins of the engine.

Trespasser's software-oriented renderer allowed for detailed models [zoom]

In addition to being a costly software-only rendering method, our bump mapping was never very evident: we could have used multiple, moving light sources and better use of the bump maps by the art staff. Many of the bump maps were created by simply converting the original texture to grayscale, an artist’s hack that works for rendered images and animations but not in real-time 3D. Image caching was an even bigger problem than bump mapping, because though it was a key technology to allow the scene complexity we were attempting it was also the source of most people’s visual complaints about the game. It seems clear in retrospect that we needed to make a tradeoff somewhere along the line and either drop the physics technology and physics gameplay in favor of the rendering technology, or more likely drop the rendering technology and ability to do complex scenes in favor of the physics technology.

2. Game design problems

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 of what the main character would do as she went through the game, and a short design proposal listing the keys which would be used and some rough ideas of what gameplay might actually be. These documents were created before any playable technology existed and were based on promises of how that technology was supposed to work.

When the game had a complete team and had essentially entered production, the prose walkthrough was used to create level maps and more-complete puzzle descriptions. However, by this point in the project artists had been building assets for nearly a year and programmers had been implementing code for even longer, and the gameplay was being crafted as a primarily engineering-driven rather than design-driven process. Engineering-driven software design can work fine when the gameplay needs of the final product are extremely light and flexible, but in the case of Trespasser, where we were trying to achieve a specific and complex gameplay, it ended up being the source of many of our problems.

It is true that a design specification for a 3D game is rarely as complete and accurate a description of the final product as a spec for a 2D adventure or similar well-understood type of project. Nonetheless, our experiences on Trespasser made it clear that it is worse to not have a design spec at all than to have one which becomes out of date and is frequently rewritten. Design should really set the direction for all other development of a game, as no amount of programming or art can suffice for a lack of gameplay, but Trespasser started and finished weak in the game design, and this affected every other part of the project.

When it became clear that the technology was not going to exist to support the initial high-concept design, it would have been best to throw out all our existing notions and reinvent the game. Unfortunately, our license made it all but impossible to throw out the original Trespasser concepts. The only major deviations from the original concept were the change from constructive, stacking-based physics puzzles to destructive, knocking-over puzzles, and an attempt to make combat more prevalent in order to shore up the weakness of the destructive physics puzzles. Since no part of the Trespasser code was written to be good at doing first-person shooter gameplay, this attempt to make shooting a more important feature only ended up flaunting some of the weaker points in the game like the lack of an inventory system and the slow frame rate.

3. Tools Problems

Trespasser was built entirely in 3D Studio Max. There was no level editor, only the generically-titled GUIApp, which was the game with a debugging shell and not really a tool at all. Our level creation procedure consisted of arranging 20,000 - 25,000 meshes in Max. We used dummy meshes to represent gameplay objects like triggers and defined game behavior of all objects by typing code into their object properties buffers.

There were two unexpected but incredibly severe drawbacks that we discovered only after it was far too late to change our method: the first was that Max is basically unfit to work with more than about 5,000 objects at a time. The Max files for a Trespasser level averaged 40mb in size, and could take a couple minutes to load even on the 256mb PII-266s the designers used. When all objects in a level were visible, it could take 30-60 seconds to respond after clicking on an object to select it, making fast work difficult to say the least.

The second problem with the Max method was the use of the object properties text buffer. The buffer seems to be one of those features which no one ever used before, because we discovered that if more than 512 characters were typed into an object’s properties buffer, Max could become unstable. If Max didn’t crash outright and a file was saved with one of these bad objects, it would become unloadable. Trespasser’s technical artist wrote many MaxScripts which served as design tools and warning scripts to guard against problems with the properties buffer, but as they could only work passively and not actively, they made designing in Max tolerable but not enjoyable.

There was an additional wrinkle to the process of using Max to create levels, and this was the exporter step. A Max plug-in converted data into the game format, but our particular exporter caused a lot of problems. It was developed by a programmer who worked from home, an hour away from the office, and used a separate code base with unique classes and a different version of the compiler. This was also his first project in 3D, and it became the second-most delayed part of the project after physics. Until the last year of the game, there were significant bugs in the exporter which required time consuming work-arounds Important functionality such as object property exporting also was not delivered until very late in development, preventing designers from implementing gameplay. In the end the exporter was assigned to another programmer and rapidly brought up to usability, but it had already delayed level building significantly.

It has become clear since shipping Trespasser that programs like Max are going to serve an increasingly important function in level building in order to create more complex geometry than the current wave of fairly simple custom editors can produce. The mistake Trespasser made was assuming that a modeling program like Max could replace all the functions of a custom game editor. A much more pleasant solution for Trespasser would have been to use Max only to create world and object geometry, and to assemble it all and implement triggers and enemies within a much-expanded GUIApp. As it was, the extreme difficulty in constructing Trespasser levels largely thwarted our final-hour attempts to find the fun gameplay in the systems we had been given.

4. AI problems

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, and there was significant missing functionality which prevented the completion of visually-important AI behaviors like howling and glaring for much longer. The first quadruped went in around the early summer of 1998, about four months from the then-intended ship date (as it turned out we slipped by about another month).

Trespasser's team didn't have enough time to implement dinosaur emotions. [zoom]

The dinosaur AI was a state-based system where, based on an emotional state, but it became apparent once dinosaurs were working well enough to put into levels that the differences between the activity states were not discrete enough. Dinosaurs were governed by a set of emotions which theoretically would prompt them to pick appropriate responses at any time. However, in practice they would end up oscillating rapidly between many activities, sometimes even literally standing still and twitching as they tried to decide what to do. Making a usable dinosaur required disabling all but one or two of their activities. This allowed aggressive dinosaurs to really be aggressive, but it also meant that the most dinosaurs were as single-minded as the traditional video game monsters we were trying to one-up.

The AI system suffered from the lack of a clear game design. There are two scenes in the Jurassic Park movies which demonstrate quintessential dinosaur gameplay: the scene in JP where the kids hide from raptors in a kitchen, and the one in Lost World where Jeff Goldblum deals with several cautious raptors in the ruins of the town. Both of these scenes rely on dinosaurs which can be fooled by ducking behind objects and which can home in on or be distracted by localized noises. Neither of these two fundamental abilities are actually present in the Trespasser dinosaur AI -- the dinosaurs instead have a simpler and more industry-standard detection radius which doubles as sight and hearing and is not blocked by objects in any way. Without a design spec calling for the movie-like behaviors, though, the AI development went in directions which ended up being largely unsuitable for gameplay. This unsuitability wasn’t even discovered until a few months before ship, when there was only time to work around it rather than rewrite it.

In addition to more sophisticated senses, the dinosaurs were really lacking an ability to emote. So much of an animal’s behavior consists of its various postures and reactions to stimulus that it seems surprising that all Trespasser dinosaurs can do is put their heads back to howl, turn to look at their target, bite at an enemy, bend to pick at a carcass, or walk with a weird limp. There was a circling behavior which was cut because the animals became too intent on circling, but there was little else. Given that none of our dinosaur behaviors were pre-animated and therefore didn’t require large amount of art time to implement, it should have been simple to add in many expressive behaviors which are typically never seen in games. These, unfortunately, are the kinds of features which either have to be in the specification from day one or which can only be added if there is time remaining after technology is completed and stable.

5. Physics problems

The box model was Trespasser’s most significant physics innovation: it was intended to be a complete simulation of any arbitrarily-sized box interacting with a number of other boxes. The approach used in Trespasser was what is known as the penalty force method. In incredibly simple terms, when boxes collide, they are allowed to intersect with each other (mathematically), and then they push each other apart until they are no longer intersecting. The penalty force model is generally believed to be an unworkable one by the few other people in the industry attempting real time solids models. Trespasser’s physics problems seem to indicate that the rest of the industry was right.

There were several notable flaws with Trespasser’s solids model as shipped: it ended up only working well when used with roughly cube-shaped boxes with dimensions between 0.5 and 1 meter, it did not model friction well, it was extremely slow, and it was not free of interpenetration even within the size constraints.

We were aware that physics would be slow, and that ten boxes at once would represent the practical upper limit, but we had not expected so much of that physics overhead to be eaten up by the dinosaur body physics, which used five boxes in the worst cases - head, body, tail, and two feet. Although the dinosaurs physics boxes were supposed to be faster to execute because they did not interact with each other, in practice a common situation of two raptors and the player consumed the entire physics time budget with no room left over to process a tumbling stack of boxes.

The speed was an issue, but the other problems were much more severe. The game design depended on boxes of sizes other than small cubes, and we ended up including many objects outside that safe range anyway. Unfortunately, all objects outside the safe size range, even large cubes, were more prone to reveal the least shippable problem with the physics system: interpenetration.

At best, these interpenetration bugs completely blow the consistency of simulation we were trying to set up, and at worst they make the game unplayable. If it was not clear before shipping Trespasser, it is clear now: no amount of interpenetration is shippable, and preventing it absolutely should be the number one concern of any physics coder.

The size constraints were a major problem for game design. We had been warned from the start that there might be a problem with very small boxes, and thus we avoided specifying too many objects which would need to be small. But we had expected to at least be able to handle somewhat small objects the size of guns and long, thin objects like planks. The last couple weeks of Trespasser design bug fixing consisted of frantically removing or making immobile just about every object which did not conform to the very specific object sizes that had proved to be fairly safe.

The friction problem was the main reason we gave up on stacking puzzles - a box on top of another box would more often than not start to vibrate until it had slid off one side or another, and multiple-box stacks were nearly impossible to keep together. It is this very friction problem which has steered many other physics coders away from the penalty force method. Even in an interpenetration-free physics model, the effects of static and dynamic friction are so important to realistic behavior that their absence will compromise the simulation.

Trespasser’s dinosaurs and the arm itself were inverse-kinematic (IK) systems controlled by physical models. Although the dinosaurs were originally supposed to be full physically-modeled bipeds whose actual physical model knew how to stand, walk, run, and jump, they ended up being almost identical to the Terra Nova biped model. The dinosaurs were moved through the world using a simplistic physical model which can be thought of as a marble, and the IK system animated the in response to the model’s movement. Just like in Terra Nova, the dinosaur legs frequently stretched, bent, and popped as the IK system struggled to handle impossible movements. These movements were incurred by the model itself, which had few realistic bounds to prevent the dinosaur from moving or changing directions in ways that would not be physically possible for a real animal.

The dinosaurs often looked bizarre because of this lack of realistic bounds, but in the case of the arm, the lack of bounds actually contributed to the game’s unplayability. The joints of the arm never had realistic limitations put on their rotation or even the distances between joints. A system written by a different programmer sat on top of the underlying arm system and tried to continually make sure it had not moved into an impossible position, but as a separate system it could only be partially successful at best. The arm as shipped would often go almost out of control for a few frames, stretching or spinning in physically unattainable ways. During this time the fragile feeling of connection between the player and their character would be shattered.

However, a properly bounded arm would only have been the first step. The rest of the arm problems were actually a result of bad system design. The arm was intended to be wholly context-insensitive. The fact that there is some context sensitivty causing guns to be held fairly stiffly and away from the body was only a result of some key members of the test staff adding their voices to the cries which had been coming from within the team to fix shooting so that it was remotely possible to hit an intended target. It should have been obvious from the fact that a 2D interface was being used to move in 3D space that a large amount of context-sensitivity was needed. If a truly successful virtual arm is ever to be implemented, simple mouse movements will have to be translated into complicated arm movements based on what is in or near the hand, or it will be as impossible to use as Trespasser’s. That there was a conscious decision to avoid context sensitivity is indicative of the larger problems with physics on our project. The physics code was largely written in a vacuum and tested in separate applications and non-representational levels and not enough of an attempt was made to step back and analyze it from a player’s perspective and make it into a system which was designed to support gameplay in every way.