Interview: Programming with Andrew Grant

Found articles relating to Trespasser

Moderators: TresCom Support Team, TresCom Webteam, TresCom Board Managers, TresCom Developers

Post Reply
User avatar
-=TresCom Website Manager=-
-=TresCom Website Manager=-
Posts: 5148
Joined: Fri Jun 24, 2005 9:40 pm
Antispam: No
Location: Sweden

Interview: Programming with Andrew Grant

Post by tatu »

Please see ... vs_003.htm for images

Programming with Andrew Grant

1. Did you work on any of the development tools for Trespasser? If you did, which ones did you work on?

Yes. There was an unreleased AI test app that I put together. I did a little on GUIApp, but not a whole lot; just AI info dialogs. I wrote a fair bit of loading code, parsing text properties from Max into meaningful game logic (this built on the text property GROFF exporter).

2. We've known for a long time that the player mesh has bones for all the parts of a human body, even though only the torso and right arm are really there. In-game, the left arm bones disappear and the rest simply don't move around. Of course, this was probably for a scrapped third-person view. At what point was the full-body mesh scrapped, and why? Was a detailed full-body mesh actually made?

If there were plans for a full-body mesh, they were before I joined the project. I don’t think we ever really expected a full body mesh. However, we probably planned to have the arms and legs visible, just because we wanted everything to be as realistic as possible.
Playtest revealed the Anne’s arm had to be two meters long, or the testers got really annoyed at how limited her reach was. (We didn’t want to write code for a biped physics model that could lean over.) This is the same kind of problem all the FPS games have- my marine had better run faster than 30mph, or I think it looks too slow. That’s the problem with a 90 degree FOV.
We also discarded the biped physics model for Anne’s feet in the end. While it is physically “accurate” to require the player to time their steps and stride before they jump, it isn’t fun. So Anne’s “feet” are a rolling cube, which causes a slightly bumpy ride and interesting timing for stepping sounds. You can jump any time the cube is close enough to a surface. (The cube was a hack, obviously, but it worked well enough that we never readdressed the problem.)
At a guess, since there is no physics skeleton for Anne’s feet, we couldn’t show her legs moving “correctly.” Therefore, we don’t render them. To some extent, her bust hides her missing feet.
And, of course, we stripped out all extraneous polygons for framerate.

3. Do you remember anything about the way dinosaur models were rigged to bone systems?

A little. In 3dsMax, a dinosaur had a bunch of placeholder objects that we called bones. These were little cubes. (They worked a lot like the joints people use for skeletal animations today.) In the text property field of each cube, we listed the vertexes that that bone connected to. I don’t recall how/if we had vertexes that attached to more than one bone.
Kyle McKisic wrote some MaxScript tools that helped him assign vertexes to bones, IIRC.

4. Trespasser has several vocal cubes for each dinosaur, including vocals for pain and roaring. The only ones used by the released engine are Stalk, Attack, Bite, and the eating/drinking vocals. Some herbivores like Parasaurolophus end up making virtually no vocalization whatsoever in the game. Some vocals appear to have been removed by the AI-act being taken out, and sometimes the act is still present but it does not make the vocal. Do you remember why so many vocals were left out?

I really don’t remember. At a guess, when things came down to the wire near ship, and no one had time to really play with the AI emotional states, we punted everything that wasn’t exciting. Some of the files got removed, some didn’t.

5. Trespasser has an amazingly beautiful and realistic water system that is rarely matched even in modern gaming. What is it that makes it so good by comparison, and why don't we see it more often?

We were very proud of our water, and I agree that even modern games rarely match it. I have no idea why. With modern shaders, you should see it everywhere. There were a few tricks involved to make the water faster, but that programmers could skip most of that optimization these days.
Conceptually, we split the water patch into a 2d array of information (I’m guessing water level, terrain level below the water, derivative of water level). It’s a fairly simple fluid physics simulation to get nice ripples out of that.
That turned into a bump map, which we applied as a specular highlight.

6. We understand that a heightmap for Cocos Island was insufficient to generate the terrain for your island, so some kind of clay model was sculpted and then scanned into a computer. What processes took place between this and the creation of the final WTD terrain files? The format has been somewhat difficult to replicate properly for us - do you remember anything about how it worked?

I can imagine it’s been hard to replicate it. It was hugely hard to make the first time. :-)
I had little involvement in the terrain. The most I did was use the API and serve as a sounding board from time to time. But I remember some things and can deduce others.
We didn’t remain true to the reference island for gameplay reasons. The terrain has to force Anne along a path with bottlenecks for puzzles.
We took the height field and loaded it into 3dsMax. That gave us a gigantic mesh. The artists and designers then modified vertices in that mesh until they got it the way they wanted it. I believe that they could vary the resolution of that mesh; areas the player never went were just giant polygons.
Then we exported the mesh data, and processed it in a custom tool using wavelet compression. That’s more common these days, but at the time, we had a very smart programmer bashing his head into the problem for a long time. The tool would often run over night, crunching numbers.
In the end, though, we had terrain data and an access function that could query the height anywhere. Also, it would triangulate the terrain into polygons; small ones near the player, big ones farther away.
We had hoped to put all the terrain data in one file. That turned out to be impractical. Mainly, 3dsMax could not handle the high resolution of the terrain for a several kilometer island.
Instead, we created a low resolution mesh for the entire island. For a given level, we made the gameplay area much higher rez. Then we compressed the result. If you looked at the terrain in Max, it was very obvious where the gameplay area was- it had vastly more polys in the mesh.
Today, I think there are several commercial terrain systems that could handle this kind of load. But I doubt they could handle it on Trespasser-era computers.
Active project: Trespasser: Isla Sorna
BE-PH1: Released
PH2-IT: Pre-released
PL-SUM: In production

"...there used to be more benches, but InGen's workers removed them during the evacuation in the name of framerate."
Post Reply